경영진 앞 빈 슬라이드를 채운 3갈래 리서치

8월 30, 2026 · 노이반
현장의 기록: AI Engineer / Forward Deployed Engineer — 19편
한 줄 요약

본질적으로 3차원인 질문에 범용 단일 패스 리서치를 맡기면 세 방향 모두 살짝 언급할 뿐 어느 것도 확답하지 못한다 — 진짜 독립적이고 좁은 트랙으로 먼저 쪼갠 뒤에 종합해야 반박에 버티는 결과물이 나온다.

세 개의 병렬 리서치 트랙이 하나의 종합 단계로 수렴하는 워크플로우
세 개의 병렬 리서치 트랙이 하나의 종합 단계로 수렴하는 워크플로우

배경

이번엔 사용자가 버그를 만난 엔지니어가 아니라, 경영진 리뷰를 앞두고 빈 슬라이드를 마주한 사업부였다. 경영전략 조직이 여러 핵심 테마 × 다수의 추진 테마 × 수십 개 방향성으로 구성된 대규모 전략 프레임워크를 만들었고, 각 사업부는 자기 몫으로 배정된 영역을 구체적인 액션플랜과 예상효과로 채워 다음 달 경영진 리뷰에 제출해야 했다.

배경에는 시장 압박이 있었다. 업계가 지켜보던 저가 경쟁자가 같은 시장에서 빠르게 점유율을 늘리고 있다는 것 — 여기서 등장하는 모든 수치는 순수 예시일 뿐, 실제 퍼센트나 물량은 이 글 어디에도 없다. 제약은 명확했다: 입력(방향성)은 모호한데 출력(액션플랜)은 구체적이어야 했고, 경영진 리뷰 일정은 고정돼 있었으며, 방향성 하나만 놓고 봐도 경쟁 역학·기술 옵션·조직 변화가 동시에 얽혀 있었다. 그 스프레드시트에 들어가는 내용은 경영진이 직접 읽을 것이었다.

첫 번째 접근이 실패하는 방식

직관적으로 먼저 떠오르는 방식 — 방향성 전체를 하나의 포괄적 프롬프트로 한 번의 리서치에 맡기는 것 — 은 정직하게 짚을 가치가 있다. 완전히 실패하진 않는다, 뭔가는 돌아온다. 하지만 경쟁사 행태, 기술 옵션, 내부 프로세스 함의를 한 스레드가 동시에 훑어야 하기 때문에 어느 하나도 깊이 파고들지 못한다. 결과물은 그럴듯하게 읽히지만, 경영진 리뷰에서 실제로 반박이 나올 지점 — "경쟁사가 실제로 이걸 한다는 근거가 뭐냐", "구체적 기술 옵션과 도입 비용이 뭐냐" — 에서 정확히 얇아진다.

조사 — 세 개의 진짜 독립적인 트랙으로 쪼개기

실질적인 작업은 추출에서 시작됐다. 슬라이드 덱과 스프레드시트 양식을 구조화된 작업용 텍스트로 먼저 뽑아냈다 — 프레임워크의 테마/방향성 계층구조 한쪽, 스프레드시트의 고정 컬럼과 열린 컬럼 한쪽. 리서치를 시작하기 전에 최종 산출물의 형태를 명확히 해두기 위해서였다.

핵심 설계 결정은 "이 방향성의 액션플랜을 만든다"를 하나의 질문으로 다루길 멈추고, 서로 다른 종류의 조사에 맞는 세 개의 독립적인 하위질문으로 나누는 것이었다.

  • 트랙 A — 경쟁사 벤치마킹. 경쟁사가 이 영역에서 실제로 운영상 무엇을 하는가 — 시장 위치 서사가 아니라 구체적인 운영 관행.
  • 트랙 B — 기술/솔루션 옵션. 경쟁사와 무관하게, 이 전략 테마와 관련해 업계에 무엇이 존재하고 무엇이 도입 가능한 성숙도인가.
  • 트랙 C — 조직/프로세스 변화. 위의 것들을 실행 가능하게 하려면 조직 내부에서 실제로 무엇이 바뀌어야 하는가.

각 트랙은 독립된 리서치 에이전트가 병렬로 수행해 각자 인용 출처를 갖춘 완결형 문서를 냈다. 이게 중요했던 이유는 두 가지다: 독립된 트랙은 서로의 초기 가정에 편향되지 않고, 동시 실행은 전체 소요시간을 세 트랙의 합이 아니라 가장 느린 트랙 하나의 시간으로 만든다 — 고정된 마감 앞에서 의미 있는 차이였다.

세 트랙이 끝난 뒤, 종합 단계는 단순히 이어붙이지 않았다. 방향성 항목마다 트랙 A는 "왜 지금 이게 중요한가", 트랙 B는 "실제로 뭘 할 수 있는가", 트랙 C는 "실행하려면 뭐가 필요한가"를 각각 맡아 하나의 서사로 엮였다.

첫 패스만큼 중요했던 건 두 번째 패스의 규율이었다. 일부 초기 발견을 원래 출처 맥락으로 재대조하니, 처음 인용됐을 때만큼 깔끔하게 옮겨붙지 않는 경우가 나왔다 — 한 조건에서 측정된 벤치마크가 다른 맥락에 자동으로 적용되진 않았다. 재확인으로 유지된다는 확신이 안 서면, 매력적인 수치를 검증 없이 그대로 살려두는 대신 신뢰도 라벨을 정직하게 낮췄다.

솔루션 / 아키텍처

구조는 의도적으로 단순하다: 모호한 질문 하나를 세 개의 독립적이고 좁은 범위의 트랙으로 분해하고, 동시에 실행한 뒤, 실제 산출물을 만드는 단일 종합 단계로 수렴시킨다. 가치는 개별 트랙이 영리해서가 아니라 분해 자체가 올바르다는 데서 나온다 — 각 트랙은 진짜로 독립적이고, 진짜로 좁고, 끝에서 진짜로 조합 가능하다.

Before / After

Before — 단일 포괄 요청: 경쟁사를 언급하고 몇 가지 기술 트렌드를 얼버무리며 "조직적 정렬이 필요할 것"이라 덧붙이는 일반적인 서베이. 그럴듯하지만 실행하기 어렵고, 근거 추적이 없어 검증된 주장과 추측이 같은 확신도로 읽힌다.

After — 세 트랙 + 종합: 트랙 A(출처 명시된 운영 관행) → 트랙 B(도입 가능한 솔루션 목록과 성숙도) → 트랙 C(내부에서 뭐가 바뀌어야 하는지) → 종합이 이 셋을 방향성별 하나의 서사로 결합하고 각 주장에 신뢰도 라벨을 붙여, 슬라이드와 스프레드시트 양쪽에 바로 채워넣을 수 있게 만든다.

검증

  • 세 트랙 각각 실제 인용 출처를 갖춘 독립 문서를 산출했고, 모든 주장에 확립된 사실/추론/가정 중 하나의 신뢰도 라벨이 붙었다.
  • 이후 감사 단계가 판돈 큰 주장 일부를 원래 맥락과 재대조해, 동일 조건 비교인지 확인했다. 유지되지 않는 주장은 라벨을 낮췄고, 이 수정은 숨기지 않고 문서화했다.
  • 최종 산출물을 스프레드시트 양식의 고정 구조에 맞춰 확인했다 — 고정 컬럼은 건드리지 않고 지정된 열린 컬럼만 채웠다.
얻은 교훈

모호하고 다차원적인 요청을 독립적이고 병렬화 가능한 트랙으로 분해한 뒤 결과를 단순히 이어붙이지 않고 의도적으로 재종합하는 사고방식은 엔지니어링 문제에 국한되지 않는다. 비즈니스 이해관계자의 모호한 상위 요청을 구조화된 실행 계획으로 번역하는 건 forward-deployed 엔지니어링의 핵심 역량 중 하나다. 그 역량의 나머지 절반은 무엇을 노출하지 않을지에 대한 판단이다 — 경영진 수준 리서치는 실질적인 민감성을 가지며, 출처 세부사항과 내부 수치를 적절히 통제하면서 방법론과 구조는 공유하는 것 자체가 극복해야 할 한계가 아니라 성숙도의 한 대목이다.

Advertisement

첫 댓글을 남겨보세요