분석 과제 발굴과 프로젝트 관리

앞 노트가 방향과 절차를 정하는 일이었다면 이 노트는 실제로 할 과제를 찾아내고 그것을 프로젝트로 굴리는 일입니다. 분석 기획에서 가장 많이 묻는 자리이고, 문제를 위에서 아래로 좁혀 오는 길과 데이터에서 위로 올라가는 길 둘을 가르는 것이 출발점입니다. 둘의 차이는 앞 노트의 네 유형과 그대로 이어집니다 — 대상을 아는 쪽이 하향식, 모르는 쪽이 상향식으로 갑니다.

하향식 접근법

네 단계

하향식 접근법은 문제가 주어졌다고 보고 그것을 차례로 좁혀 해결책에 이르는 방식입니다. 네 단계를 밟습니다.

1. 문제 탐색 — 어디에 분석할 거리가 있는지 빠짐없이 훑는다
2. 문제 정의 — 업무의 문제를 데이터 분석의 문제로 바꿔 적는다
3. 해결방안 탐색 — 그 문제를 어떤 역량과 시스템으로 풀지 고른다
4. 타당성 검토 — 해 볼 만한지 따져 과제로 확정한다

문제 탐색과 문제 정의를 가르는 선이 시험의 단골입니다. 탐색은 무엇이 문제인지 넓게 찾는 단계라 세부 구현을 생각하지 않고 목록을 벌리는 데 집중하고, 정의는 그 문제를 「이탈 확률을 예측한다」처럼 분석이 다룰 수 있는 형태로 옮겨 적는 단계입니다.

문제 탐색

빠짐없이 훑기 위해 틀을 씁니다. 가장 많이 나오는 것이 비즈니스 모델 캔버스를 다섯 영역으로 줄여 쓰는 방식입니다.

조직 안만 훑으면 놓치는 것이 있어 밖으로 넓히는 관점 넷을 함께 씁니다. 사회·기술·경제·환경·정치를 보는 거시적 관점, 대체재와 신규 진입자를 보는 경쟁자 확대 관점, 고객과 채널의 요구를 보는 시장의 니즈 탐색, 그리고 내부 역량과 파트너를 다시 보는 역량의 재해석입니다. 같은 업종의 앞선 사례를 가져다 쓰는 외부 참조 모델 기반 탐색도 이 단계의 방법이고, 이렇게 찾아낸 후보를 「무엇을 어떻게 분석해 어디에 쓴다」로 적어 둔 것이 분석 유즈 케이스입니다.

해결방안 탐색과 타당성 검토

문제가 정의되면 무엇으로 풀지를 고릅니다. 가진 역량과 가진 시스템을 각각 기존·신규로 가르면 네 칸이 나옵니다.

마지막 단계인 타당성 검토는 두 갈래로 봅니다. 비용 대비 편익을 따지는 경제적 타당성과, 데이터가 실제로 있는지·분석 환경과 역량이 되는지를 보는 데이터 및 기술적 타당성입니다. 아무리 가치 있는 주제여도 데이터가 없으면 과제가 되지 않으므로 뒤쪽에서 걸러지는 후보가 많습니다.

상향식 접근법

디자인 씽킹

문제가 무엇인지조차 뚜렷하지 않을 때는 순서를 뒤집습니다. 상향식 접근법은 데이터를 먼저 보면서 의미 있는 패턴을 찾아내고 거기서 문제를 끌어내는 방식이고, 앞 노트의 통찰·발견 유형이 이 길로 갑니다. 정답을 모르는 상태에서 쓰므로 정답이 붙어 있지 않은 데이터를 다루는 비지도학습과 성격이 맞습니다.

이 길에 절차를 준 것이 디자인 씽킹입니다. 다섯 단계입니다.

1. 공감 — 쓰는 사람을 관찰하고 이해한다
2. 문제 정의 — 관찰한 것에서 진짜 문제를 뽑아낸다
3. 아이디어 도출 — 해결 방법을 넓게 벌린다
4. 프로토타입 — 빠르게 만들어 본다
5. 테스트 — 써 보게 하고 반응을 받아 되돌아간다

발산과 수렴

상향식은 넓게 벌리는 발산과 좁혀 가는 수렴을 번갈아 돌립니다. 공감과 아이디어 도출이 벌리는 자리이고, 문제 정의와 테스트가 좁히는 자리입니다. 하향식이 처음부터 좁혀 오기만 하는 것과 대비됩니다.

실무에서는 둘을 섞습니다. 상향식으로 데이터를 훑어 후보를 얻고, 그 후보를 하향식의 타당성 검토에 걸어 과제로 확정하는 식입니다. 어느 한쪽만 쓰는 조직은 드물다는 점이 지문으로 나옵니다.

분석 과제 정의서

담는 것

과제로 확정되면 분석 과제 정의서를 씁니다. 발굴 단계의 결과를 한 장으로 못 박아 이후 프로젝트의 기준이 되게 하는 문서이고, 다음을 담습니다.

• 소스 데이터와 그 입수 방법
• 데이터 입수 난이도와 분석 난이도
• 쓸 분석 방법과 상세 분석 과정
• 분석 수행 주기
• 결과에 대한 상세 검증 방안과 오너십

이해관계자가 이 문서 하나로 같은 그림을 보게 하는 것이 목적입니다. 그래서 「무엇을 분석한다」만 적지 않고 누가 결과를 검증하고 책임지는가까지 적습니다. 오너십이 비어 있으면 결과가 나와도 쓸 사람이 없습니다.

프로토타이핑

데이터가 있는지, 그 데이터로 될지가 불확실할 때는 정의서를 완벽하게 적기 전에 작게 만들어 봅니다. 앞 노트의 프로토타이핑 모델을 과제 발굴에 쓰는 것이고, 시행착오를 허용하는 대신 불확실성을 빨리 줄입니다. 빅데이터 분석 환경에서 이 방식이 특히 어울리는 이유는 데이터의 존재 여부와 품질을 미리 알기 어렵기 때문입니다.

과제 관리 다섯 속성

다섯 축

분석 과제를 관리할 때 눈여겨볼 것이 다섯입니다.

Speed는 만드는 시간이 아니라 쓰는 시점의 속도를 뜻합니다. 실시간 이상거래 탐지라면 모델이 아무리 좋아도 응답이 늦으면 못 쓰고, 월 단위 리포트라면 하루가 걸려도 괜찮습니다. 이 요구가 앞 노트의 분석 방법과 시스템 구현 방식을 거꾸로 결정합니다.

정확도와 정밀도

정확도는 모델의 결과가 실제 값에 얼마나 가까운가이고, 정밀도는 같은 입력으로 반복했을 때 결과가 얼마나 일관되게 나오는가입니다. 둘은 함께 높이기 어려워 균형을 잡아야 하는 관계입니다.

어느 쪽을 우선할지는 쓰임새가 정합니다. 결과를 업무에 바로 쓰는 활용 측면에서는 정확도가, 모델을 오래 돌려야 하는 안정성 측면에서는 정밀도가 중요합니다. 지문이 「매번 다른 값이 나와 현업이 신뢰하지 않는다」로 나오면 정밀도 쪽 문제입니다.

프로젝트 관리

PMBOK 열 영역

분석 프로젝트도 프로젝트이므로 일반 관리 지식 체계를 따릅니다. PMBOK이 드는 관리 영역은 열입니다.

분석 프로젝트의 특성

일반 시스템 구축 사업과 갈리는 지점이 있습니다. 요구사항이 처음부터 고정되지 않고 분석을 하면서 바뀐다는 점, 데이터가 실제로 쓸 만한지가 시작해 봐야 드러난다는 점, 그리고 결과가 목표 성능에 못 미쳐 앞 단계로 되돌아가는 일이 흔하다는 점입니다.

그래서 범위·일정·리스크 셋이 다른 영역보다 자주 흔들립니다. 성능 기준을 착수 전에 합의해 품질 영역으로 못 박아 두고, 되돌아가는 회차를 일정에 미리 넣어 두는 것이 대응입니다. 지문은 상황을 주고 어느 관리 영역의 문제인지를 고르게 하는 형태로 나옵니다.

연습 문제

1. 하향식 접근법의 단계 순서로 옳은 것은?
   ① 문제 정의 → 문제 탐색 → 해결방안 탐색 → 타당성 검토
   ② 문제 탐색 → 문제 정의 → 해결방안 탐색 → 타당성 검토
   ③ 문제 탐색 → 해결방안 탐색 → 문제 정의 → 타당성 검토
   ④ 문제 정의 → 해결방안 탐색 → 타당성 검토 → 문제 탐색

   ②. 넓게 훑어 후보를 벌리는 탐색이 먼저이고, 그중 하나를 분석이 다룰 수 있는 형태로 옮겨 적는 것이 정의입니다. 그다음 무엇으로 풀지를 고르고 마지막에 해 볼 만한지를 따집니다.
2. 분석 과제의 구축비가 1억 2,000만 원, 연간 운영비가 2,000만 원, 연간 편익이 7,000만 원이다. 3년을 기준으로 한 순편익과 누적 수지가 흑자로 돌아서는 해는? (화폐의 시간 가치는 고려하지 않는다)
   ① 순편익 1,000만 원, 2년 차
   ② 순편익 3,000만 원, 2년 차
   ③ 순편익 3,000만 원, 3년 차
   ④ 순편익 9,000만 원, 3년 차

   ③. 3년 편익은 $7{,}000 \times 3 = 21{,}000$ 만 원이고 비용은 $12{,}000 + 2{,}000 \times 3 = 18{,}000$ 만 원이라 순편익은 3,000만 원입니다. 연간 순현금은 $7{,}000 - 2{,}000 = 5{,}000$ 만 원이고 첫해에 구축비 1억 2,000만 원이 나가므로 누적은 1년 차 −7,000만 원, 2년 차 −2,000만 원, 3년 차 +3,000만 원이 되어 3년 차에 흑자로 돌아섭니다. 이 계산이 타당성 검토의 경제적 타당성에 해당합니다.
3. 분석 역량은 조직에 없고 쓰려는 분석 시스템도 새로 들여야 하는 과제에 대한 해결방안으로 가장 알맞은 것은?
   ① 기존 시스템을 개선해 쓴다
   ② 시스템을 고도화한다
   ③ 교육과 채용으로 역량을 확보한다
   ④ 전문 업체에 맡긴다

   ④. 역량과 시스템을 기존·신규로 가른 네 칸에서 둘 다 신규인 자리입니다. ①은 둘 다 기존, ②는 역량은 있고 시스템만 새로운 경우, ③은 시스템은 있고 역량만 없는 경우입니다.
4. 상향식 접근법에 대한 설명으로 옳지 않은 것은?
   ① 문제가 뚜렷하지 않을 때 데이터에서 출발해 문제를 끌어낸다
   ② 디자인 씽킹은 공감에서 시작해 테스트로 이어진다
   ③ 발산과 수렴을 번갈아 돌린다
   ④ 정답이 붙은 데이터를 전제로 하므로 지도학습과 성격이 맞는다

   ④. 무엇을 찾을지 모르는 상태에서 쓰는 방식이라 정답이 붙어 있지 않은 데이터를 다루는 비지도학습과 성격이 맞습니다. 정답이 정해져 있다면 애초에 대상이 정의된 것이므로 하향식으로 가는 편이 빠릅니다.
5. 다음 상황에서 문제가 되는 과제 관리 속성은?
   「같은 데이터로 모델을 다시 돌릴 때마다 결과가 달라져 현업이 수치를 믿지 않는다.」
   ① Data Size
   ② Speed
   ③ Accuracy
   ④ Precision

   ④. 반복했을 때 결과가 일관되게 나오는 정도가 정밀도입니다. 정확도는 결과가 실제 값에 얼마나 가까운가라 이 상황과 다릅니다. 활용 측면에서는 정확도를, 오래 돌려야 하는 안정성 측면에서는 정밀도를 우선한다는 대비가 짝으로 나옵니다.
6. 서술형 연습입니다. 착수 두 달 만에 「예측 정확도가 목표에 못 미치니 변수를 더 넣고 대상 기간을 3년으로 늘리자」는 요구가 들어와 일정이 밀리고 있습니다. PMBOK의 관리 영역 가운데 어디가 흔들린 것인지 짚고, 착수 전에 무엇을 해 두었어야 했는지 5줄 이내로 쓰시오.

   채점 기준은 셋입니다. (1) 흔들린 영역을 정확히 짚었는가 — 요구가 늘어 작업이 불어난 것이므로 범위가 1차이고, 그에 딸려 일정과 원가가 함께 흔들립니다. 성능 기준이 합의되지 않아 「목표에 못 미친다」는 판단이 뒤늦게 나온 것이므로 품질도 함께 들어야 하며, 현업과 분석팀의 기대 수준이 어긋난 점에서 이해관계자를 들어도 인정합니다. (2) 분석 프로젝트의 특성과 이어 설명했는가 — 요구사항이 처음부터 고정되지 않고 분석을 하면서 바뀌며, 결과가 목표에 못 미쳐 앞 단계로 되돌아가는 일이 흔하다는 점이 원인입니다. 일반 시스템 구축 사업과 갈리는 지점이 바로 여기입니다. (3) 사전 조치를 구체적으로 적었는가 — 착수 전에 모델 성능 기준과 판정 방법을 합의해 품질 영역으로 못 박고, 그 기준에 못 미쳤을 때 되돌아가는 회차를 일정에 미리 넣어 둡니다. 분석 과제 정의서에 소스 데이터와 분석 범위, 결과 검증 방안과 오너십을 적어 두고 그 문서를 기준으로 변경을 통제하는 것도 답입니다. 데이터 미확보와 품질 불량을 리스크로 등록해 두는 것을 더하면 가점입니다. 영역만 들고 사전 조치를 적지 않으면 배점의 3분의 1만 붙습니다.