프롬프팅만으로는 부족합니다: AI 에이전트를 위한 코드 강제형 연구 워크플로우

대부분의 AI 워크플로우 실패는 프롬프트(Prompt)가 너무 짧아서 발생하는 것이 아닙니다.

프롬프트가 프로세스를 유지하는 유일한 수단이기 때문에 발생합니다.

긴 연구 작업, 특히 비즈니스 연구(Business research)의 경우, 모델은 시작은 잘하더라도 나중에 경로를 이탈할 수 있습니다:

검증하기 전에 요약부터 합니다.
취약한 출처를 마치 1차 증거인 것처럼 취급합니다.
결론은 업데이트하지만, 그 뒤에 있는 차트나 표를 업데이트하는 것은 잊어버립니다.
다른 출처를 인용하는 출처를 인용하고, 그 2차 정보를 마치 독창적인 주장인 것처럼 제시합니다.
증거가 부족할 때 과도하게 자신감을 가집니다.
컨텍스트(Context)가 길어지면 지루한 품질 관리(Quality-control) 단계를 건너뜁니다.

이것이 제가 Alpha Insights를 거대한 프롬프트 템플릿 대신 하네스 강제형(Harness-enforced) 연구 워크플로우로 구축한 이유입니다.

Alpha Insights는 Claude Code 및 Codex Desktop을 위한 오픈 소스 비즈니스 연구 기술입니다. 이는 컨설팅 스타일의 연구를 프레임워크(Frameworks), 증거 등급 산정(Evidence grading), 검증기(Validators), 보고서 생성(Report generation)이 포함된 단계별 워크플로우로 패키징합니다.

더 흥미로운 부분은 프레임워크의 목록이 아닙니다. 바로 실행 모델(Execution model)입니다.

핵심 문제

프롬프팅(Prompting)은 확률적(Probabilistic)입니다.

모델에게 출처를 확인하고, 숫자를 조정하며, 가설을 레드팀(Red-team)하고, 차트의 일관성을 유지하라고 요청할 수 있습니다. 때로는 그렇게 할 것입니다. 하지만 때로는, 특히 작업이 길어지고 복잡해지면 조용히 해당 단계를 건너뛰기도 합니다.

가벼운 작업이라면 괜찮을 수도 있습니다.

하지만 연구에서는 괜찮지 않습니다. 보고서는 깔끔해 보일 수 있지만, 그 이면에는 취약한 증거, 오래된 수치, 맞지 않는 차트 또는 근거 없는 결론이 숨겨져 있을 수 있습니다.

따라서 설계 질문이 바뀌어야 합니다:

"어떻게 하면 더 나은 프롬프트를 작성할 수 있을까?"라고 묻는 대신,

다음과 같이 질문하십시오:

워크플로우가 진행되기 전에 반드시 존재해야 하는 산출물(Artifact)은 무엇인가?
어떤 주장들에 출처 신뢰도(Source confidence)가 필요한가?
어떤 확인 절차들이 결정론적(Deterministic)이어야 하는가?
어떤 실패 모드(Failure modes)가 다음 단계를 차단해야 하는가?
컨텍스트 드리프트(Context drift) 상황에서도 워크플로우가 생존할 수 있도록 디스크에 무엇을 기록해야 하는가?

이것이 프롬프트와 하네스(Harness)의 차이입니다.

Alpha Insights가 강제하는 것들

Alpha Insights는 추론(Reasoning), 합성(Synthesis), 판단(Judgment)을 위해 모델을 사용합니다. 하지만 반복 가능한 제어 로직(Control logic)을 프롬프트에서 분리하여 주변 시스템으로 옮기려고 시도합니다.

워크플로우에는 다음이 포함됩니다:

19가지 비즈니스 프레임워크 (Business frameworks): Porter's Five Forces, BCG Matrix, PESTEL, TAM/SAM/SOM, JTBD, flywheel, business model canvas, value chain 등.
9가지 사고 방식 (Thinking methods): issue trees, MECE, 가설 기반 연구 (Hypothesis-driven research), 피라미드 원칙 (Pyramid principle), 삼각측량 (Triangulation), 제1원리 (First principles), ACH, 사전 부검 (Pre-mortem), 전문가 인터뷰 로직.
증거 등급 산정 (Evidence grading): 모든 인용을 동일하게 취급하는 대신, 주장(Claims)에 소스 신뢰도(Source confidence) 태그를 지정합니다.
단계별 게이트 (Stage gates): 필수 산출물(Artifacts)이나 확인 사항이 누락된 경우, 검증기(Validators)와 훅(Hooks)이 진행을 차단합니다.
HTML 보고서: 최종 출력물은 ECharts 시각화가 포함된 의사결정 준비 완료 보고서입니다.

중요한 변화는 "좋은 연구를 수행하라"는 명령이 명시적인 중간 산출물(Intermediate artifacts)의 집합이 된다는 점입니다.

예를 들어:

증거 수집 전에 반드시 연구 계획(Research plan)이 존재해야 합니다.
증거에는 익명의 인용 채우기(Citation stuffing) 대신 소스 신뢰도(Source confidence)가 필요합니다.
주장(Claims)은 이를 뒷받침하는 증거와 연결되어야 합니다.
보고서 헤드라인은 차트 데이터에서 벗어나서는 안 됩니다.
약한 증거가 경고 없이 강력한 전략적 권고 사항을 뒷받침해서는 안 됩니다.

이러한 확인 사항 중 일부는 여전히 판단(Judgment)을 필요로 합니다. 하지만 많은 실패 모드(Failure modes)는 코드로 잡아낼 수 있을 만큼 기계적입니다.

프롬프트가 아닌 코드가 되어야 하는 것들

워크플로우를 구축하고 반복한 결과, 저는 몇 가지 AI 에이전트의 실패 모드를 엔지니어링 문제로 다루어야 한다고 생각합니다:

오래된 수치 (Stale numbers)

보고서의 한 부분에서 숫자가 변경되면, 하위 테이블, 차트 및 경영진 요약(Executive summaries)이 이전 값을 조용히 유지해서는 안 됩니다.

소스 세탁 (Source laundering)

소스 A가 소스 B를 인용하는 경우, 시스템은 A가 일차적 소스인 것처럼 가장해서는 안 됩니다. 주장은 증거 체인(Evidence chain)을 보존해야 합니다.

차트/보고서 불일치 (Chart/report mismatch)

차트에서 42%라고 명시되어 있는데 본문 문단에서 47%라고 말한다면, 이는 문체(writing style)의 문제가 아니라 검증(validation)의 문제입니다.

누락된 산출물 (Skipped artifacts)

워크플로우에서 계획(plan), 증거 원장(evidence ledger), 레드팀 검토(red-team pass) 또는 보고서 품질 체크(report-quality check)를 요구한다면, 시스템은 다음 단계로 넘어가기 전에 해당 산출물(artifact)이 존재하는지 확인해야 합니다.

취약한 증거로 인한 과잉 확신 (Overconfidence from weak evidence)

만약 어떤 주장이 신뢰도가 낮은 출처에 의해서만 뒷받침된다면, 명시적인 경고 없이 단정적인 언어를 사용해서는 안 됩니다.

이러한 요소들이 바로 프롬프트(prompt)가 긴 세션 동안 강제하기 어려워하는 것들입니다.

하네스 엔지니어링 (Harness Engineering)

제가 탐구하고 있는 패턴은 제가 '하네스 엔지니어링(harness engineering)'이라고 부르는 것입니다.

의도를 설명하는 데에는 프롬프트를 사용합니다.

워크플로우를 강제하기 위해서는 코드(code), 상태 머신(state machines), 훅(hooks), 검증기(validators) 및 명시적인 파일(explicit files)을 사용합니다.

모델은 여전히 어려운 사고 과정을 수행합니다. 하지만 그 주변의 시스템이 작업이 다음 단계로 진행할 만큼 충분히 완료되었는지를 결정합니다.

그 경계가 중요합니다.

모든 것이 프롬프트 안에만 존재한다면, 모델은 작업자(worker)인 동시에 검사관(inspector)이 됩니다. 긴 워크플로우에서 이는 취약합니다.

하네스(harness)가 프로세스를 소유한다면, 시스템이 구조, 증거 및 완료 여부를 확인하는 동안 모델은 추론(reasoning)에 집중할 수 있습니다.

이것이 중요한 이유

AI 에이전트(AI agents)는 그럴듯한 결과물을 만들어내는 능력이 점점 좋아지고 있습니다.

이는 검증(verification)의 중요성을 낮추는 것이 아니라, 오히려 더 높입니다.

비즈니스 조사(business research)의 목표는 더 긴 보고서를 만드는 것이 아닙니다. 목표는 추론 체인(reasoning chain)이 가시적이고, 증거 품질이 명시적이며, 워크플로우가 지루한 부분을 조용히 건너뛸 수 없는 보고서를 만드는 것입니다.

Alpha Insights는 그 아이디어를 구현한 사례 중 하나입니다.

GitHub: https://github.com/Ericyoung-183/alpha-insights

데모 보고서: https://ericyoung-183.github.io/alpha-insights/assets/demo-report.html

MIT 라이선스입니다. 특히 모델의 판단(model judgment)과 결정론적 강제(deterministic enforcement) 사이의 경계가 여전히 불분명한 에이전트 워크플로우를 구축하고 계신 분들의 피드백을 적극 환영합니다.