시나리오 설정
넥스트웨이브 컨설팅은 전략, 데이터·AI, 클라우드 전환, 프로세스 혁신, IT 아키텍처를 하는 가상의 컨설팅사입니다. 파트너 2명, EM(엔게이지먼트 매니저, 프로젝트 책임자) 5명, 시니어 4명, 컨설턴트 2명, 애널리스트 3명이 일하고, 가상 고객사 프로젝트 28건을 수행했다고 설정했습니다.
이런 회사는 새 제안을 쓸 때마다 같은 질문을 합니다. "비슷한 프로젝트를 해 본 적이 있나?", "그때 누가 맡았고 무엇이 문제였나?" 답은 이메일과 Slack, 주간보고 속에 흩어져 있어 찾기 어렵습니다. 이 데모는 그 기록을 지식그래프로 묶었을 때 무엇이 달라지는지 보여 줍니다.
이 회사가 가진 고민은 네 가지로 설정했습니다.
- 제안서마다 처음부터비슷한 프로젝트를 해 봤어도 그 기록을 찾지 못해 제안서를 매번 새로 씀
- 같은 문제를 또 겪음지난 프로젝트에서 일정을 늦춘 원인이 주간보고에만 남아 있어 다음 계획에 반영되지 않음
- 사람에게 기대는 경험누가 어떤 기술과 고객을 아는지가 머릿속에만 있어, 사람이 바뀌면 함께 사라짐
- 끊긴 고객 이력같은 고객사·같은 그룹 계열사와 해 온 일을 한자리에서 볼 수 없음
데이터 구성
문서는 모두 AI로 만든 가상 문서이며, 기간은 2023년 5월부터 2026년 5월까지 3년으로 설정했습니다. 실제 도입에서는 오른쪽 칸의 저장소에서 같은 종류의 문서를 가져옵니다.
| 문서 유형 | 건수 | 담긴 내용 | 실제 도입 때 가져오는 곳(예) |
|---|---|---|---|
| 주간보고 | 586 | 진행 상황, 이슈, 일정 지연 원인 | 문서 저장소·그룹웨어 |
| 이메일 | 364 | 고객 요청, 의사결정, 승인 | 메일함 |
| 슬랙 스레드 | 290 | 팀 내부 논의, 장애 대응 | 사내 메신저 |
| 산출물 | 134 | 설계서, 분석 결과, 매뉴얼 | 문서 저장소 |
| 계약서 | 32 | 범위, 기간, 투입 인력 | 계약·영업 문서함 |
| 킥오프 회의록 | 31 | 목표, 역할, 초기 위험 | 문서 저장소 |
| 제안서 | 28 | 고객 과제, 접근 방법 | 계약·영업 문서함 |
| 최종 보고서 | 28 | 성과, 남은 과제 | 문서 저장소 |
| 합계 | 1,493 |
1,493건 가운데 136건은 다른 프로젝트로 잘못 분류됐거나 내용이 서로 어긋나는 문서를 일부러 섞은 것입니다. 실제 회사 문서에도 이런 것이 섞여 있기 때문에, 추출은 이 문서까지 포함해 하고 걸러 내는 일은 검증 단계가 맡게 했습니다. 문서 목록 화면에는 이 136건을 보이지 않습니다. 문서에서 추출한 개체는 3,180개(기술 1,159·문제 유형 808·산출물 유형 452·조직 383·인물 358·산업 20)입니다. 관계는 Claude가 5,447건을 뽑았고, OpenAI가 근거 문서와 대조해 통과시킨 3,204건(59%)만 그래프에 반영했습니다. 나머지 41%는 "근거 문서 본문에 그런 내용이 없다"처럼 이유를 남기고 뺐습니다.
그래프에서 나온 것
문서를 하나씩 읽어서는 보이지 않던 것들입니다. 숫자는 섞어 넣은 검증용 문서 136건을 뺀 기준이며, 모두 가상 문서에서 나온 결과입니다. 실제 회사에 적용하면 이런 종류의 답이 나온다는 예시로 봐 주세요.
가장 자주 푼 문제: 레거시 노후화
"레거시 시스템 노후화"가 28건 중 17건, 7개 산업의 문서에 나옵니다. 이 회사가 맡은 프로젝트의 절반 이상이 낡은 시스템 교체에서 시작했습니다. 영업 메시지와 표준 제안 패키지를 어디에 집중할지 정하는 근거가 됩니다.
되풀이된 일정 위험: 방화벽 승인
"방화벽 정책 승인 지연"이 제조(대성정밀)·에너지(동서파워)·물류(코리아로지스틱스) 세 프로젝트의 주간보고에 나옵니다. 고객사 보안 승인 절차가 업종과 상관없이 일정을 늦췄다는 신호입니다. 다음 제안서 일정에 승인 기간을 미리 넣을 수 있습니다.
끝까지 따라다닌 문제: 데이터 정합성
"데이터 정합성 오류"는 7개 프로젝트에 나오고, 그 가운데 5개는 최종 보고서에 기록돼 있습니다. 프로젝트 마지막까지 남은 문제라는 뜻이고, 데이터 검증 단계를 초반 일정으로 당길 근거가 됩니다.
회사의 기술 지도
AWS(12건), Power BI·Kafka(각 10건), Oracle 11g(9건), Grafana·Terraform(각 8건) 순으로 많이 쓰였습니다. Oracle 11g처럼 오래된 기술이 상위에 있는 것은 레거시 전환 프로젝트가 많기 때문입니다. 강점 기술 소개와 교육 우선순위를 정하는 데 씁니다.
한 사람에게 몰린 경험
시니어 컨설턴트 조은비가 28건 중 12건에, 파트너 오수민이 11건에 투입됐습니다. 이 두 사람이 빠지면 많은 프로젝트의 맥락을 아는 사람이 사라집니다. 그래서 경험을 문서와 그래프로 남겨 두어야 하고, 인력 배치도 고르게 해야 합니다.
고객 이력과 그룹 계열사
그린마트와는 재고 최적화 파일럿(2023년)에서 다이나믹 프라이싱, 옴니채널 운영 혁신(2024년)으로 3건을 이어 왔습니다. 한빛카드·한빛생명보험·한빛캐피탈은 한 그룹 계열로 4건입니다. 다음 제안 때 "이 고객과 무엇을 해 왔나"를 한 번에 보여 줄 수 있습니다.
할 수 있는 일
같은 그래프를 역할마다 다른 질문으로 씁니다.
| 누가 | 묻는 것 | 얻는 것 |
|---|---|---|
| 제안을 쓰는 EM | "이 고객사와 비슷한 프로젝트, 그때 겪은 문제는?" | 유사 사례와 담당자, 되풀이된 위험(방화벽 승인 등)을 근거 문서와 함께. 기획서 초안까지 |
| 파트너·영업 | "한빛 계열과 해 온 일은?" | 계열사별 프로젝트 이력과 성과, 다음 제안의 출발점 |
| 인력 배치 담당 | "Kafka를 써 본 사람은? 지금 여러 프로젝트에 걸친 사람은?" | 기술별 경험 인력과 투입 이력, 한 사람에게 몰린 경험 |
| 경영진 | "회사가 가장 많이 푼 문제와 쓴 기술은?" | 문제 유형·기술 지도로 본 회사의 강점, 상품화·교육 우선순위 |
| 새로 온 직원 | "그린마트 프로젝트들에 대해 알려 줘" | 3년 치 맥락을 한자리에서, 원문으로 확인하며 |
데모 흐름
데모 화면은 아래 순서로 봅니다. 화면 캡처는 같은 시나리오의 소규모 데이터셋(프로젝트 10건, 분석 대상 문서 122건)으로 찍은 것이라, 화면 속 숫자는 위 표와 다릅니다.
예시 질문
- "AWS 기반 MSA 전환 경험이 있어?": 과거 프로젝트와 담당 EM을 각주와 함께 답합니다
- "그린마트 프로젝트들에 대해 알려 줘": 같은 고객사의 프로젝트 3건을 묶어 설명합니다
- "재고 리스크를 줄인 사례 있어?": 문제 유형으로 연결된 프로젝트를 찾습니다
- "여러 프로젝트에 동시에 투입된 사람은?": 인력과 프로젝트의 관계를 따라갑니다
측정하지 않은 것
- 정확도: 추출 정확도, 재현율, 답변 정확도는 측정하지 않았습니다
- 검증의 뜻: "검증된 관계"는 다른 회사 AI가 한 번 더 판정했다는 뜻이며, 사람이 정답과 대조한 것이 아닙니다
- 화면 속 성과 수치: 캡처에 보이는 처리 시간 단축률 같은 숫자는 가상 문서 안의 내용입니다
- 그래프에서 나온 것: 위 인사이트는 가상 문서에서 나온 결과이며, 실제 회사의 사실이 아닙니다. 제안서 작성 시간이 얼마나 줄었는지 같은 효과도 측정하지 않았습니다
실제 고객 기록에 같은 기술을 적용한 결과는 지식그래프·온톨로지 페이지의 구축 사례와 뉴스룸 지식그래프 사례를 보세요.