LLM의 「특성」을 총 10회에 걸쳐 해설해 온 본 연재의 번외편입니다.

• 포쵴킨 이해 (Potchomkin Understanding) (제1회)
• Lost in the Middle (제2회)
• Context Rot (제3회)
• Sycophancy (영합) (제4회)
• Context Handoff (제5회)
• Prompt Distillation (제6회)
• 프로젝트화의 함정 (제7회)
• GPT화의 함정 (제8회)
• Instruction Drift (제9회)
• AI 성과물의 품질 보증 (제10회)

본편은 LLM의 실패 모드를 하나씩 해부하는 구성이었지만, 이번에는 반대 방향입니다. 「해결하고 싶은 과제가 있다. AI 프로젝트를 백지 상태에서 어떻게 시작하고, 어떻게 키워나가며, 최고의 성과물까지 가져갈 것인가」 —— 0부터 100까지를 관통하며 나아갑니다.

왜 이 글을 쓰는가. 필자 자신이 어떤 AI 프로젝트를 시작했을 때, 몇 바퀴를 돌았는지 모를 정도로 시행착오를 겪으며 성과가 나지 않아 솔직히 괴로웠기 때문입니다. 좋은 것이 만들어졌다고 생각해도 그것은 「우연」이었고 재현되지 않았습니다. 포맷을 고정하려고 프롬프트(Prompt)를 길게 했더니, 이번에는 중간 내용을 건너뛰어 버립니다 (제2회). 화가 날 정도로 잘 풀리지 않는 기간이 계속되었습니다.

이 글의 목적은 단 하나입니다. 당신의 「몇 바퀴를 돌았는지 모를 시행착오」를 「N회 만에 끝나는, 전망이 보이는 반복」으로 바꾸는 것입니다.

본 기사에서는 필자가 실제로 경험한 안건을 (일반화된 형태로) 세로실로 삼습니다.

상황: Java와 COBOL이 혼재된 시스템. 로컬에 검증 환경을 구축하는 것이 극도로 어려움 -
막연한 바람: 「어떤 형태로든 AI를 사용하여 테스트를 할 수 없을까」 -
우여곡절: AI가 무엇을 할 수 있는지 알아보고, 테스트 케이스 작성·샌드박스(Sandbox)에서의 테스트 DB 생성·화면 입력·해석·재검토가 가능하다는 것을 알고 조직 AI (Project)를 구축. 하지만 사내 보안으로 인해 샌드박스가 외부 접속 불가였고, 라이브러리 부족으로 인해 일부가 좌절 -
도착: 최종적으로 "화이트박스형 결합 시험으로서, Java/COBOL을 포함한 전 분기 망라 시험을 AI가 실시하게 한다"라는, 당초에는 생각지도 못했던 구체적인 목표에 도달

주목해 주었으면 하는 점은, 처음의 막연한 바람과 최종적인 성과물이 완전히 별개라는 것입니다. 이 「목표 자체가 탐색 과정에서 다듬어져 가는」 현상이 본 기사의 설계 사상의 토대가 됩니다.

갑자기 결론의 전체 지도부터 말씀드리겠습니다. AI 프로젝트의 0→100은 성질이 다른 두 가지 기간으로 나뉩니다.

전반 (0→50) = 애자일(Agile) 측정기: 목적은 움직이는 것을 만드는 것이 아니라, 측정하는 것. 무엇이 가능하고, 무엇이 제약이며, 어떤 지시가 효과적인지 —— 「실측 사양서」를 작성하는 기간

후반 (50→100) = 워터폴(Waterfall) 고정기: 실측 사양서를 바탕으로 페이즈(Phase)·성과물·품질 게이트(Quality Gate)를 확정하고, 대화를 최소화한 대본적 파이프라인으로서 실행·운용하는 기간

워터폴의 전제는 「요건과 제약을 사전에 확정할 수 있다」는 것입니다. 하지만 제9회에서 확립했듯이, 모델의 사양서는 존재하지 않습니다. 사용하는 측이 실측하여 쓰는 것입니다. 필자의 안건에서도 「샌드박스가 외부 접속 불가이며 라이브러리가 부족하다」는 결정적인 제약은, 테스트해 보기 전까지는 아무도 알 수 없었습니다. 존재하지 않는 사양서를 전제로 워터폴을 짤 수는 없습니다. 그렇기에 초기 시행착오는 낭비가 아니라, 원리적으로 생략 불가능한 측정 공정입니다. 여기서 자신을 자책할 필요는 전혀 없습니다. 자책해야 할 것은 「측정 없는 시행착오」뿐입니다 (후술).

흥미롭게도, LLM의 실패 물리 법칙 그 자체가 워터폴형 실행을 우대하고 있습니다. 본 연재에서 보아온 열화는 거의 모두 「긴 대화적 상호작용」에서 발생했습니다.

• Context Rot (제3회): 대화가 계속될수록 부패함
• Instruction Drift (제9회): 대화의 상호작용 그 자체가 드리프트(Drift)의 엔진. 대본 대화라면 드리프트가 제로였을 것이라는 대조 실험을 떠올려 보십시오.
• Sycophancy (제4회): 주고받는 대화가 늘어날수록 영합의 연료가 진해짐

「대화하며 계속 키워나가는」 운용은 LLM에게 독이 발생하는 구조와 같습니다. 반면 워터폴은 각 페이즈가 「확정된 입력 → 짧고 깨끗한 세션 → 확정된 성과물」로 완결됩니다. 이는 제3회의 페이즈 분할, 제5회의 Handoff 스키마, 제7회의 척추 구조 그 자체입니다. 워터폴은 AI의 실패 물리학에 대한 구조적인 방어인 것입니다.

머신러닝 (Machine Learning) 실무에는 "연구용 노트북 (Research Notebook)에서 탐색하고, 프로덕션 파이프라인 (Production Pipeline)에 고정한다"라는 정석이 있는데, 이와 같은 구조입니다. 애자일 (Agile)로 만들고, 워터폴 (Waterfall)로 돌린다.

백지 상태에서 가장 먼저 해야 할 일은 정밀한 목표 설정이 아닙니다. 무엇을 할 수 있는지 모르는 상태에서는 정밀한 목표를 세울 수 없기 때문입니다. 처음에 해야 할 일은 두 방향에서의 탐색입니다.

방향 ①: 능력 재고 (AI 관점 · 바텀업 (Bottom-up)) —— "당신이 무엇을 할 수 있는가"

배경: {곤란한 점·제약 사항을 그대로 작성. 예: Java와 COBOL이 혼재된
시스템이라 로컬 검증 환경 구축이 어려움}
목적: {대략적인 것이라도 좋으니 희망 사항. 예: 어떤 형태로든 테스트를 실시하고 싶음}
...

핵심은 "전제 조건을 명시하게 한다"라는 문구입니다. 필자는 이를 하지 않고 구상을 넓혔다가, 나중에 외부 접속 불가라는 벽에 부딪혔습니다. 전제 조건을 처음에 나열하게 해두면, "외부 접속 필요 여부"라는 확인 항목이 구축 전 체크리스트로서 확보됩니다.

방향 ②: 복수 방법 제시 (요건 관점 · 탑다운 (Top-down)) —— "이 요건을 충족하는 길은 몇 갈래인가"

달성하고 싶은 요건: {요건을 가능한 한 구체적으로}
이 요건을 충족하는 방법을, 발상이 다른 복수의 접근 방식으로 제시해
주세요. 하나의 방법을 심층적으로 파고드는 것이 아니라, 우선 폭을 넓히는 것을
...

왜 "복수"를 강제하는가? AI는 하나의 질문에 대해 하나의 가장 전형적인 답변(제5회·제6회에서 본 "분포의 중심")을 내놓습니다. 한 번만 물어본다면 돌아오는 것은 "당신의 상황에 최적화된 제안"이 아니라 "세상에서 전형적인 제안"입니다. 복수로 나열하게 해야 비로소 비교·선택이라는 공정이 생겨나며, 전형적인 것이 아닌 최적의 방향으로 끌어올 수 있습니다.

필자의 최종 착지점인 "전 분기망 망라 시험"도 처음부터 존재했던 단일 방법이 아니라, 도출해낸 개별 요소(테스트 케이스 작성 · DB 생성 · 타건 · 해석 · 재검토)의 **교차점에서 탄생한 하이브리드 (Hybrid)**였습니다. ①과 ②를 왕복하십시오. ①만 하면 "할 수 있는 것들의 짜깁기"가 되고(제7회에서 진단한 채우기 실패의 입구입니다), ②만 하면 탁상공론이 됩니다.

방법의 후보가 나왔다면, 다음에 할 일은 설계를 넓히는 것이 아니라 최소 구성으로 벽에 부딪히러 가는 것입니다. 필자의 실패는 7개 태스크 분량의 구상을 조직 AI로서 구축한 뒤에야 샌드박스 (Sandbox)의 접속 제약을 깨달았다는 점이었습니다. 순서가 반대입니다.

후보 접근 방식 중에서 "전제 조건이 환경 의존적"이라고 표시된 것(외부 접속, 파일 형식, 실행 권한, 모델의 기능 제한 등)을 1태스크 · 1파일 · 1회의 최소 실험으로 먼저 검증합니다. 여기서 투자한 1시간이 후반부의 수차례 반복될 재작업 (Rework)을 없애줍니다.

벽에 부딪혔을 때, "할 수 없었다"에서 멈추면 길이 사라집니다. 필자의 실례가 바로 교재인데, "샌드박스가 외부 접속을 할 수 없어 라이브러리 부족으로 할 수 없었다"라고 이유를 분해하여 언어화한 순간, "라이브러리를 수동으로 제공하면 회피할 수 있지 않을까"라는 길이 보였습니다. "외부 접속 불가"는 움직일 수 없는 1차 제약이지만, "라이브러리 부족"은 거기서 파생된 2차 증상에 불과하며, 1차 제약을 우회하지 않고도 직접 해결할 가능성이 있다 —— 분해하면 이것이 보입니다.

다음과 같은 이유로 잘 되지 않았습니다.
"{구체적인 실패 이유. 가능한 한 분해하여 자세히}"
이 실패 이유를 구성 요소로 분해해 주세요. 각 요소에 대해,
...

우연한 영감에 의존하지 않고, 막힐 때마다 이 형식을 돌립니다. 그것만으로도 "막힘(詰み)"의 상당 부분이 "우회로 있음"으로 바뀝니다.

출력의 질을 안정시키는 데 있어 비용 대비 효과가 가장 높은 한 수는 "읽는 이를 고정하는 것"입니다. "알기 쉽게 써줘"의 "알기 쉬움"은 AI 내부의 전형(중심)으로 뭉뚱그려집니다. 하지만 읽는 이를 한 사람의 해상도로 고정하면, 문체 · 상세도 · 전문 용어 사용 가능 여부 · 생략해도 되는 전제 지식이 도미노처럼 한꺼번에 결정됩니다. 하나의 변수로 출력의 무수한 파라미터 (Parameter)에 동시에 작용하는 레버입니다.

이 작업을 의뢰함에 있어, 우선 읽는 이·사용자를 고정합니다.
상정 독자: {직책·경력 연수·전제 지식을 구체적으로.
예: 입사 2년 차. Java 경험은 있으나 COBOL은 미경험.
...

전반전의 심장부입니다. 필자를 가장 괴롭혔던 것은 "좋은 것이 만들어져도 우연인 경우가 많다"는 점이었습니다. 이 정체를 밝혀내겠습니다.

LLM의 출력은 확률 분포로부터의 **샘플링 (Sampling)**입니다. "좋은 출력이 한 번 나왔다"는 것은 "분포에서 좋은 샘플을 한 번 뽑았다"는 것에 불과하며, 프롬프트가 좋다는 증거가 아닙니다. 주사위를 한 번 던져서 6이 나왔다고 해서 "6이 잘 나오는 주사위"라고 말할 수 없는 것과 같습니다.

좋은 프롬프트란, 출력 분포의 무게 중심이 "좋음" 위에 놓여 있는 프롬프트를 말합니다.

단 한 번의 출력에 일희일비하며 조정하는 것——필자의 반복 작업(Iteration)이 배움을 낳지 못했던 가장 큰 이유는, 샘플을 쫓기만 했을 뿐 분포를 측정하지 않았기 때문이었습니다.

동일한 프롬프트로 3~5회 생성하여, 출력군을 다음 세 가지 패턴으로 분류합니다.

패턴 A: 전부 거의 비슷하며, 전부 좋다 → 분포가 "좋음" 위에 뾰족하게 솟아 있다. 완성.

패턴 B: 전부 거의 비슷하며, 전부 나쁘다 → 뾰족하지만 위치가 나쁘다. 어긋나는 방식이 일관적이므로 수정 대상이 명확하다. 부족한 지시 사항을 추가하면 고쳐진다. 사실 가장 고치기 쉽다.

패턴 C: 회차마다 제각각이다 → "어쩌다 운 좋게 좋은 것이 나온다"의 정체. 분포가 넓으며, 프롬프트의 어딘가가 모호하여 모델이 매번 다른 해석을 하고 있다는 증거.

중요한 주의 사항: 1회차와 2회차의 "차이 그 자체"에서 원인을 찾아서는 안 됩니다. 개별 차이의 원인은 샘플링의 난수이며, 이를 탐색하는 것은 무의미합니다. 원인 분석을 해도 되는 것은 패턴 C의 "분산(Variability)"에 대해서뿐이며, 그마저도 살펴보아야 할 것은 "어떤 축으로 분산되는가"입니다. 포맷인가, 상세도인가, 결론 그 자체인가——분산되는 축 = 프롬프트가 지정하지 않은 자유도입니다. 그곳이 바로 채워야 할 구멍입니다.

여기에 함정이 있습니다. 분산되는 축을 찾아 지시 사항을 추가하는 과정을 반복하면 프롬프트가 비대해지고, Lost in the Middle (제2회) 현상이 발생하여 또 다른 축에서 새로운 분산이 생겨납니다. 하나를 채우면 하나가 새어나간다——필자가 경험한 "몇 번을 반복해도 알 수 없는" 역학적 정체는 바로 이 두더지 잡기 루프였습니다.

해답은 지시 사항을 추가하는 것이 아니라, 공정을 분할하는 것입니다. 하나의 거대한 프롬프트에 모든 축의 지시 사항을 욱여넣는 것이 아니라, 공정별로 프롬프트를 나누면 각 프롬프트가 좁혀야 할 축이 소수로 줄어들어, 짧은 상태를 유지하면서도 분포를 뾰족하게 만들 수 있습니다. 이것이 프롬프트 레벨의 워터폴(Waterfall)화이며, 후반전을 향한 가교가 됩니다.

연구 분야에서도 수동 프롬프트 조정은 "시간이 오래 걸리고, 직관에 의존하며, 당락의 차이가 크다"는 점이 문제시되고 있으며, 체계적인 최적화로 전환하는 것만으로 정밀도가 46.2% → 64.0%로 급증했다는 보고도 있습니다 (DSPy/MIPRO 계열 연구). 수동 반복 작업에 부족한 것은 재능이 아니라 "경사 (Gradient)"——이전보다 좋아졌는지를 측정하는 척도입니다. 척도와 종료 조건을 먼저 고정하십시오.

# STEP 0 (반복을 시작하기 "전"에, 딱 한 번만)
이하를 확정한 후에 비로소 반복을 시작하십시오.
1. 대표 태스크를 3개 고정한다 (Golden Task)
...

1회차 1변수 (제6회의 어블레이션(Ablation) 원칙: 무엇이 효과가 있었는지 특정할 수 있음), 평가는 별도 세션 (제1회·제9회: 자기 평가는 동일한 병폐를 계승함), 로그 1줄 ("이거 전에도 시도했던 거다" 방지), 종료 조건 (무한 반복 금지). 이 4가지가 갖춰져야 비로소 반복 작업은 축적이 됩니다.

나아가 필자가 실무에서 효과를 실감한 것은, "작성 역할"과 "평가 역할"을 별도의 AI 인스턴스로 분리하는 운영 방식입니다. 프롬프트나 프로젝트를 만드는 AI와, 그것을 실제로 사용하여 평가 및 개선점을 도출하는 AI를 나누는 것입니다. 평가 측에는 작성 경위를 공유하지 않고, "작성자의 의도를 추측하지 말고, 실제로 사용한 경험만을 근거로 평가하라"고 제약을 겁니다. 제4회에서 확립한 "소유권을 숨기는" 방식의 프로젝트 단위 버전으로, 자기 평가의 안일함을 구조적으로 회피할 수 있습니다.

0→50 단계를 마쳤을 때, 손에 남아야 하는 것은 "작동하는 AI"가 아니라, 다음 항목들이 채워진 실측 사양서입니다 (제7회의 PROJECT_META.md 초기 버전에 해당합니다).

• 할 수 있는 것 / 할 수 없는 것 (능력 인벤토리 검증 결과)
• 환경의 1차 제약과 회피 완료된 2차 증상 (예: 외부 연결 불가 / 라이브러리는 수동 제공으로 회피)
• 채택한 방법 (여러 후보 중 선택한 이유 및 버린 후보도 기록)
• 효과가 입증된 지시 사항 (Ablation 통과분) 및 정답 사례 (few-shot용 합격 출력)
• 골든 태스크(Golden Task)와 합격 기준 및 현재 스코어
• 분포의 특성 (어떤 태스크에서 분산되기 쉬운가)

이 사양서야말로 후반전에서 워터폴을 구축하기 위한 "확정된 요구사항과 제약"입니다.

실측 사양서를 바탕으로 공정을 확정합니다. 설계 원칙은 제3회·제7회에서 이미 확립되었습니다.

• 페이즈(Phase)별로 채팅(또는 Project)을 분리한다. 저자의 초기 실패—7종류의 태스크 자재 40개 파일을 하나의 Project에 몰아넣었다가 단일 채팅보다 정밀도가 떨어진 사례—를 반복하지 않는다. 페이즈 간에는 **Handoff 스키마(제5회)**로 연결한다: 확정 사항 + 원문 인용 + 확신도 + 미확인 사항. 대화가 아니라 확정된 성과물만을 전달한다.
• 모든 페이즈 공통의 최소 지식(용어 CONST · 명명 규칙)만을 '척추(Backbone)'로 공유하고, 각 페이즈의 자재는 해당 페이즈 전용으로 분리한다.

저자의 프로젝트라면, 해석 → 차분 추출 → 테스트 케이스 작성 → 테스트 데이터 작성 → 실행(타건) → 차분 비교 → 재검토·자료화라는 각 페이즈가, 각각 짧고 깔끔한 세션 + 전용 프롬프트 + 이전 페이즈의 확정 성과물로 완결되는 형태가 됩니다.

각 페이즈의 프롬프트를 실측 사양서의 '실증된 지시 + 정례(Few-shot)'로부터 구성하여 확정합니다. 여기서는 더 이상 벽치기(Wall-hitting, 아이디어 탐색)를 하지 않습니다. 벽치기는 전반부에서 끝났습니다. 각 프롬프트는 자신의 페이즈 축만을 담당하므로 짧고, 분포는 날카롭게 유지됩니다(두더지 잡기 식 구조적 문제의 해소).

페이즈의 출구에는 **품질 게이트(Quality Gate)**를 둡니다. 내용은 제10회의 도구입니다.

• 성과물 메타 블록 의무화(근거 ID · 확신도 · 미확인 사항 · 실시 완료 검증)
• 수락 검사 프롬프트(총평 금지 · 항목별 ◯✕ · 원문 인용 강제)를 별도 세션 또는 별도의 모델로 실행
• 기계 검증이 가능한 것(테스트 실행, 형식 체크)은 반드시 기계로 수행(제10회 L0)

게이트를 통과하지 못한 성과물은 다음 페이즈로 흘려보내지 않는다——워터폴(Waterfall)의 공정 관리 그 자체를 그대로 품질 보증으로 사용합니다.

월간 골든 태스크 회귀(제7회): 지식 추가 · 지시 변경 · 모델 업데이트 중 무엇이 열화를 일으켰는지 변경 로그와 대조하여 구분한다.
피드백 동선의 인위적 확보(제8회): 배포할 경우, 이탈 대신 한마디 남길 수 있는 동선을 답변 끝에 정형화하여 삽입한다.
실측 사양서 업데이트: 드리프트(Drift) 발생 턴, 영합 카나리아(Sycophancy Canary) 결과 등을 계속해서 추가한다. 모델의 버전 업그레이드는 전면 재측정의 트리거로 삼는다.

100에 도달한 상태란 '완벽한 AI'가 만들어진 상태가 아닙니다. '열화되면 검지할 수 있고, 원인을 구분할 수 있으며, 고칠 수 있는 계통'이 돌아가고 있는 상태입니다(제10회: 신뢰는 성격이 아니라 설계로 만든다).

• AI 프로젝트의 0→100은
  2주기 모델이다: 전반부는 애자일(Agile)로 측정하고(실측 사양서를 작성), 후반부는 워터폴(Waterfall)로 굳힌다(대본적 파이프라인으로 돌린다).
• 전반부가 애자일일 수밖에 없는 이유는,
  모델과 환경의 사양서는 실측으로만 작성할 수 있기 때문이다. 초기의 시행착오는 생략 불가능한 계측 공정이며, 부끄러운 일이 아니다.
• 후반부가 워터폴이어야 하는 이유는,
  LLM의 실패 물리학(Rot · Drift · 영합)이 모두 대화적 상호작용에서 발생하기 때문이다. 대본화는 구조적 방어다.
• '어쩌다 보니 좋은 것이 나온다'의 정체는 샘플링이다.
  좋은 출력 ≠ 좋은 프롬프트. 3~5회 추출하여 '편차의 형태'로 판단하며, 개별 차이의 원인은 추적하지 않는다.
• 편차를 발생하는 축을 지정하여 계속 채우려 하면 Lost in the Middle 현상과 충돌한다(두더지 잡기). 해답은
  공정 분할을 통해 각 프롬프트의 담당 축을 줄이는 것이다.
• 회차를 축적으로 바꾸는 4종 세트:
  1회차 1변수 · 별도 세션 평가 · 로그 1줄 · 종료 조건
• 탐색의 주요 기술: 능력 인벤토리 작성 × 다수 방법의 왕복, 작게 부딪히기, 실패 이유의 1차/2차 분해, 독자 고정, 작성역과 평가역의 분리

저자의 '몇 번을 돌렸는지 모를, 괴로웠던' 시행착오는 돌이켜보면 이 지도를 가지지 못한 채 걸었던 탐색이었습니다. 이 글이 여러분의 회차를 셀 수 있는 횟수로 바꾸어 주기를 바랍니다.

• Khattab, O., et al. (2023). DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines. Stanford NLP. - Opsahl-Ong, K., et al. (2024). MIPRO: Optimizing Instructions and Demonstrations for Multi-Stage Language Model Programs. - Lemos, F., et al. (2025). Is It Time To Treat Prompts As Code? A Multi-Use Case Study For Prompt Optimization Using DSPy. arXiv:2507.03620 - 본 연재 1~10회에서 인용한 각 연구