day 014 KPMG Future Academy

sottuggung·2024년 12월 6일

KPMG-future-academy

목록 보기

14/41

KPMG Future Academy AI 활용 데이터 분석가 3기 14일차 수업을 2024년 12월 5일에 참석했다. 오전에는 프로젝트 관리 중에서 어제 진행한 WBS를 활용한 범위 계획에 이어 비용 및 일정의 계획에 대한 수업이 진행되었다.

프로젝트 관리
1.1. 일정
1.2. 예산
1.3. 실행 및 통제
1.3.1. 의사소통 관리
인공지능 실습
2.1. Stable Diffusion

1. 프로젝트 관리

1.1. 일정

의존 관계 설정. 작업 간 선후 관계를 명확히 설정
선행 종료 -> 후속 시작 (Finish-to-Start, FS)
선행 시작 -> 후속 시작 (Start-to-Start, SS)
선행 종료 -> 후속 종료 (Finish-to-Finish, FF)
선행 시작 -> 후속 종료 (Start-to-Finish, SF)

작성 소요 시간 산정
유사 산정 : 과거 유사 프로젝트 데이터를 기반으로 시간 산정
전문가 판단
3점 추정 : 낙관치(O), 현실치(M), 비관치(P)
예상 시간 = (O + 4M +P)/6

마일스톤
진척 상황 확인, 의사소통 도구, 위험 식별

의사 결정 Go/No-Go, Go-left/Go-right
중간 완료 예정일 Target Date
데드라인 Do-or-Die Date
배송일 Deliveries
이벤트 Ceremonies
프로젝트 종료일 Project End Date

Task, Time, Bar, Dependency

1.2. 예산

유사 추정 (analogous estimation) : 유사 프로젝트로 추정. 개괄적. 기존 제품 업그레이드 등에 활용.
상향식 추정 (Bottom-up estimation) : 작업 단위의 세부 비용을 추정하여 합산. 신규 프로젝트 및 복잡한 프로젝트에 활용. 예산 산정이 오래 걸림.
하향식 추정 (Top-down estimation) : 전체 예산을 기준으로 세부 작업의 비용을 배분. 빠르게 산정 가능. 현실과의 괴리가 발생할 수 있음. 전체 예산 상에서 비율로 산정.

예산 산정시 고려해야할 요소
고정비 : 프로젝트 범위와 관계없이 일정한 비용 (예 - 장비 구입비)
변동비 : 작업량에 따라 변동하는 비용 (예 - 인건비)
리스크와 예비비
통화와 환율
시간 소요

1.3. 실행 및 통제

1.3.1. 의사 소통 관리

프로젝트에서 가장 중요한 요소 중 하나는 의사소통
개인과 조직에게 필요한 정보를 효과적으로 제공하는 것
리스닝 베이스의 의사소통 : 상대방이 무엇을 알고 무엇을 모르는지 왜 그런지를 이해하고 접근.
누구에게 언제 어느 정도의 정보를 제공할 것인가를 고려

일관성 있고 적절한 정보가 전달, 수신, 이해, 피드백되는 과정을 관리하는 활동
신뢰 관리

의사소통 계획 수립

정보 요구사항 분석 : 누가, 무엇을, 언제, 어떻게 정보를 필요로 하는지 정의
의사소통 채널 결정 : 이메일, 미팅, 보고서 등

정보 배포

프로젝트 상태 보고 및 업데이트
이해관계자별 맞춤화된 정보 제공

성과 보고

업무 수행과 관련한 정보를 수집 및 배포하는 프로세스
프로젝트 진척 상황, 리스크, 품질 문제 등을 명확히 전달
현황 보고(Progress Measurement) 및 예측(Forecasting)등이 포함

피드백과 확인

이해관계자들의 요구사항을 만족시키고 이슈를 해결하기 위해 의사소통을 관리하는 프로세스
정보가 이해되었는지 확인하고, 추가 질의나 피드백 수집

정보 : 보안성과 접근성을 상호 고려

의사 소통 관리 계획
1. 어떤 정보가 언제 수집되어야 하는가?
2. 누가 이 정보를 받을 것인가?
3. 수집된 정보의 취합과 저장에는 어떤 방법을 쓸 것인가?
4. 누가 누구에게 보고할 것인가?
5. 보고 체계를 어떻게 정의할 것인가?
6. 각 보고 단계별 정보의 배포 주기는 어떻게 할 것인가?

의사소통 매트릭스를 형성 및 관리

의사소통의 예

회의 : 회의 중에 다루어지는 정보 중 일부만 필요한 사람에겐는 시간의 낭비를 불러올 수 있다.
메모 : 간단히 작성된 문서. 특정 정보 전달에 효과적.
보고 : 프로젝트 진척, 성과, 리스크, 예산 등을 체계적으로 문서화하여 전달
발표 : 공식적인 장소에서 프로젝트 상태, 성과, 중요 변경 사항 등을 전달. 일방적.
인터넷/인트라넷 : 정보 공유 및 팀 협업을 위한 온라인 플랫폼 활용
비공식적 접촉 : 전화, 부서방문 등 공식적인 채널 외의 자유로운 의사소통
Kick-off Meeting : 프로젝트 시작 시 팀, 이해관계자, 고객 간의 첫 번째 공식 모임.

PM의 역할

신뢰를 바탕으로 쌍방향 의사소통 진행
의사소통 촉진자로서, 의사소통 장애를 제거해야한다.

장애요인 :
정보 과부하 <- 메시지 단순화
불분명한 메시지 <- 시작 자료 활용
기술적 장애 <- 기술 및 문화적 감수성 고려
문화적 차이 <- 피드백 루프 활성화

[실습]
Slack, Microsoft Teams 등 협업 도구 사용
탈출 프로젝트 - 커뮤니케이션 에디션
시나리오 : 한 팀 당 6명
배경 : 여러분은 중요한 이커머스 플랫폼 개발 프로젝트의 팀입니다. 고객에게 플랫폼을 납품하기까지 12시간 밖에 남지 않은 상황에서, 테스트 과정 중 심각한 결제 시스템 오류가 발견되었습니다. 플랫폼은 고객이 제공한 다중 결제 옵션을 지원해야 하지만, 특정 옵션에서 결제가 처리되지 않는 무제가 발생했습니다. 고객은 이 문제를 즉시 해결하길 원합니다. 각 팀원은 문제 해결에 필요한 핵심 정보를 포함한 단서를 하나씩 가지고 있으며, 이를 협력적으로 조합해 해결책을 찾아야 합니다.
해결해야하는 문제를 정의하고, 고객에게 납득할 만한 문제 해결 계획을 발표하시오.

팀 : KDY, HDH, KKE, KJY, me, SHG

역할
팀리더 : HDH
개발자 : SHG
데이터 분석가 : me
테스터 : KKE
시스템 관리자 : KDY
고객 담당자 : KJY

[사고 대응 시뮬레이션]
피해 시점 : 납품 전 12시간 테스트 과정 중.
피해 규모 : 결제 실패된 건수 및 금액 파악.
피해 구체화 : 실패 환경 분석, 특정 브랜드 카드사와의 호환성 별도 점검.
피해 조기 홀드 방법 : 누락된 타임아웃, 오류메시지 띄우기.

1차 해결까지 남은 시간 : 만 하루.
피해 원인 규명 : IP 등 로그 분석. 정확한 트래픽 과부하 원인 파악. 재현 가능성 타진.

1차 키맨 대상 신속 보고 : 예상 사고 종식 시간 및 피해 보상안 포함.

추가 원인 파악
1차 해결안 도출 : 필요시 전문 로그 감사 시행.

1차 해결안 적용 및 예방책 마련.
2차 내부 임원 및 고객사 보고.

문제 상황 재현.
재발 방지책 구성, 피해 사용자 대상 보상 공지 등 의무 이행.

팀 내에서는 1차로 타임아웃, 오류메시지 등을 긴급 패치한 후 응답시간 초과 거래에 대해 서버를 일부 증설하기, 그리고 아래와 같이 실험을 셋팅하기로 잠정결론내렸다.

이에 대한 추가 대책도 필요하였다. 즉, 해당 실험으로는 응답시간이 지연된 거래 건이 특정 카드 브랜드 결제 건 실패와 상관관계가 있는지까지만 확인이 가능할 듯하다. (이후 상관관계가 없다면 별도의 원인 분석이 필요하다) 그래서 별도로 알아본 결과 이상거래 건들은 우회를 시켜서 추가 피해를 방지하고 또한 별도 수집을 즉시 하도록 조치하는 것이 권장됨을 알게 되었다.

장애나 사고가 발생했을 때 예비 인프라가 없거나 실시간 장애 파악이 안 되는 경우 문제가 급속도로 커질 수 있음을 체감하였다.

회고
백업 서버, 예비 인프라 준비 여부가 중요할 듯하다.
특정 요청(문제 요청건)만 따로 우회하는 개발은 1차 대응 직후에 가급적 바로 해야할 듯 하다.
실습 후 캐싱 매커니즘 등 선제적으로 마련해야할 사고 방지 프로그램에 대한 관심이 더 높아졌다.
긴급한 상황속에서 특정 카드사 결제 건이 오류를 일으키는지, 응답 속도 500ms 거래 건이 해당 건인지 등 사실정보가 분산되어 발견됨에 따라, 사실 확인에 부차적인 과정이 복잡하게 필요하였고 이에 대한 내부의 인식차이나 산재된 정보가 집단적으로 혼란을 가중시킴을 경험하였다.

사고 발생 실습과정에서 알게된 사실
기술적 장애 : 실시간 파악이 안 됨. 혹은 파악되었더라도 해결방안에 대한 의견이나 이해관계가 갈림
실 문제 파악 : 1차 대응까지는 머리를 맞대어 대응책이 나오긴 했지만, 이후 실제 문제 파악 및 해결은 어떻게 할 것인가?

조언
업데이트 전으로 롤백하여 다시 시작.
긴급 패치로 호환성 회복 등.

질의를 통해 사고상황시 내부통제에 대해 일반적인 방향을 들었다.
1. 초기 신고체계가 전방위로 활성화되어 있어야 추후 누락이나 왜곡이 덜 하다. (편견 등에 의한 편파 신고 수취를 주의해야함)
2. 집체 교육 등 평상시에 재난상황을 집단으로 대응하는 훈련 등이 활용되고 있다.

[IT 사고 대응 매뉴얼]
출처 : Claude 3
IT 회사의 일반적인 사고 대응 매뉴얼은 다음과 같은 주요 단계로 구성:

사고 탐지 및 초기 평가

이상 징후 모니터링
사고 심각도 초기 평가
관련 팀 즉시 소집
사고 로그 및 증거 보존

사고 분류 및 대응 레벨 결정

보안 사고 유형 분류 (네트워크, 데이터, 시스템 등)
사고 심각도 레벨 선정
대응 우선순위 결정
초기 대응 범위 설정

격리 및 위협 차단

영향받은 시스템 즉시 격리
추가 피해 확산 방지
네트워크 접근 제한
취약점 패치 및 봉쇄

상세 조사 및 분석

사고 발생 경로 추적
취약점 및 침투 지점 확인
피해 범위 정밀 분석
forensic 증거 수집

복구 및 정상화

시스템 복원
백업 데이터 활용
대체 시스템으로 전환
기능적 무결성 검증

보고 및 커뮤니케이션

내부 경영진 보고
관련 부서 통보
필요시 고객/이해관계자 통보
법적/규제 대응 준비

사후 대응 및 개선

사고 종합 보고서 작성
근본 원인 분석
재발 방지 대책 수립
보안 프로세스 개선

법적/규제 대응

법무팀 개입
규제 기관 대응
증거 보관
필요시 법적 대응 준비

심리적 대응

직원 대상 심리 상담
조직 내 불안감 관리
팀 사기 진작 활동

지속적 모니터링

재발 위험 모니터링
보안 시스템 강화
주기적 취약성 평가
보안 교육 강화

[IT 사고 인식차이로 인한 2차 위험 내부통제]

명확한 사고 심각도 분류 체계 수립

정량적/정성적 기준 명문화
사고 레벨별 명확한 대응 프로토콜 정의
각 레벨에 따른 보고 및 대응 체계 구축

표준화된 커뮤니케이션 프로세스

사고 보고 양식 표준화
공식 소통 채널 지정
정보 전달 시 객관성과 중립성 강조
핵심 정보의 누락 방지

다층적 검증 시스템

단일 판단이 아닌 다중 검증 체계
교차 검증을 통한 편향성 제거
객관적 평가 메커니즘 도입

정기적 교육 및 워크숍

사고 대응 인식 교육
시뮬레이션 기반 훈련
심각도 평가 능력 향상
조직 전반의 리스크 인식 개선

명확한 권한과 책임 규정

사고 대응 조직도 작성
각 역할별 명확한 의사결정 권한 부여
책임 범위와 한계 명시

객관적 평가 지표 개발

사고 심각성 측정 KPI 개발
정량적 평가 기준 마련
데이터 기반 의사결정 지원

외부 전문가 자문 메커니즘

제3자 객관적 평가 채널 확보
내부 편향성 차단
전문적 관점 확보

보고 단계별 상호검증 프로세스

수직/수평적 보고 검증
다중 관점 확보
정보 왜곡 방지

심리적 안전성 확보

개방적 소통 문화 조성
실수에 대한 징계 최소화
건설적 피드백 문화

디지털 기록 및 모니터링

모든 의사결정 과정 기록
투명성 확보
추후 분석 및 개선 자료로 활용

신뢰 형성 관련 인지 모델 연구
다중 에이전트 시스템
multi-agent system, MAS, "자체 구성 시스템", self-organized system
: 많은 지능적 Agent 들이 서로 작용하도록 하는 시스템
그 Agent 들은 소프트웨어 프로그램이나 로봇 (Robot) 처럼 자율적인 개체 (autonomous entities) 인것으로 간주됨.

특징
(출처 : http://www.aistudy.co.kr/robot/agent/multi-agent_system.htm)
1. 각 에이전트가 문제해결 (Problem Solving) 을 하기에는 불완전한 정보와 능력만이 있어서 제한된 시야 (view point) 를 갖는다.
2. 시스템 전체를 제어할수 없다.
3. 데이타가 분산 (decentalized) 되어있다.
4. 계산 (computation) 이 비동기적 (asynchronous) 이다.

지능에는 체계적, 기능적, 절차적 접근 방식, 알고리즘 검색 또는 강화 학습이 포함될 수 있다.
상당한 중복에도 불구하고 다중 에이전트 시스템은 행위자 기반 모델(ABM, Agent Based Modeling)과 항상 동일하지는 않다. ABM의 목표는 특정 실제적 또는 공학적 문제를 해결하는 것이 아니라 일반적으로 자연 시스템에서 간단한 규칙을 준수하는 에이전트(반드시 "지능적"일 필요는 없음)의 집단적 행동에 대한 설명적인 통찰력을 검색하는 것이다. (출처 : https://ko.wikipedia.org/wiki/%EB%8B%A4%EC%A4%91_%EC%97%90%EC%9D%B4%EC%A0%84%ED%8A%B8_%EC%8B%9C%EC%8A%A4%ED%85%9C)