첫 번째 파트에서 저는 긴 지시문(instruction)이 단순한 프롬프트(prompt)를 넘어 문서화되지 않은 프로그램처럼 작동하기 시작하는 지점에 대해 썼습니다. 지시문은 상태(state), 전이(transitions), 복구 경로(recovery paths), 문서 간의 의존성(dependencies), 그리고 로컬에서 변경하기 이미 어려운 규칙들을 개발합니다. 하지만 이를 수용하더라도 불편한 질문이 남습니다. 모델이 실제로 당신이 필요로 했던 프로세스를 따랐는지 어떻게 알 수 있을까요? 가장 쉬운 방법은 결과를 보는 것입니다. Jira 티켓, 기술 설명, 수락 기준(acceptance criteria), 그리고 여러 테스트 시나리오가 있습니다. 형식은 올바르고, 필요한 섹션들이 존재하며, 이름들도 일치합니다. 빠른 검토 과정에서 패키지는 완벽해 보입니다 — 그리고 바로 그 지점이 우리가 여러 번 실수했던 부분입니다. 올바르게 보이는 결과라고 해서 모델이 올바른 소스(sources)를 사용했는지, 모든 필수 체크를 수행했는지, 그리고 필수 단계를 건너뛰지 않았는지를 증명하지는 않습니다. 또한 다음 작업자가 작업의 일부를 스스로 재구성해야 하지 않을 것이라는 점도 증명하지 못합니다. 이를 확인하는 가장 명확한 방법은 구체적인 인수인계(handoff)를 통해서입니다.

패키지는 준비된 것처럼 보였다

아래 예시는 통제된 실행(controlled run)에서 가져와 수정되었습니다. 도메인, 이름, 필드, 값은 완전히 변경했지만, 실패 메커니즘은 그대로 유지했습니다. profile.notificationChannel이 email에서 sms로 변경될 때 생성되어야 하는 PREFERENCE_CHANNEL_CHANGED라는 내부 이벤트를 추가하는 팀을 상상해 보세요. 데이터 수준에서 요구사항은 대략 다음과 같을 것입니다:

event:
  name: PREFERENCE_CHANNEL_CHANGED
  trigger:
...

모델은 긴 프로세스를 거쳐 Jira 티켓, 기술적 설명 (technical description), 수락 기준 (acceptance criteria), 수동 QA 시나리오 (manual QA scenarios), 짧은 롤백 (rollback) 계획, 그리고 테스트 및 문서 업데이트 요구 사항을 생성합니다. 언뜻 보기에는 모든 것이 괜찮아 보입니다. 긍정적인 시나리오 (positive scenario), 부정적인 케이스 (negative case), 중복 체크 (duplicate check), 그리고 예상되는 이벤트에 대한 설명이 모두 포함되어 있습니다. 명칭은 일관되고, 문서 구조는 정확하며, 프로세스는 성공적으로 종료됩니다. 처음에는 거의 아무런 의견 없이 이 패키지를 수락했을 것입니다. 하지만 테스터가 이 문서를 잘 정리된 문서가 아닌 실제 작업 지침서로 읽기 시작했을 때, 그들은 두 번째 시나리오에서 멈춰 서서 다음과 같이 물었습니다. “여기서 제가 어떤 데이터를 준비해야 하며, 나중에 무엇을 정리해야 하나요?” 패키지는 그 질문에 답하지 않았고, 모델이 의도한 바를 파악하는 데 문서 자체를 읽는 것보다 더 많은 시간이 걸렸습니다.

첫 번째 간극은 Jira에서 나타났습니다. 요구 사항은 처음에는 완벽하게 정상적으로 보였지만, 구현에 필요한 수준의 세부 사항이 이미 누락되어 있었습니다. 다음과 같이 적혀 있었습니다:

technical_requirements:
  - update unit tests
  - update documentation

형식적으로는 요구 사항이 존재하지만, 실제로는 다음과 같은 몇 가지 기본적인 질문에 답하지 못합니다: 어떤 컴포넌트 (component)에 커버리지 (coverage)가 필요한지, 어떤 테스트가 필수적인지, 어떤 픽스처 (fixtures)를 사용해야 하는지, 감사 기록 (audit record)은 어디에 저장되는지, 그리고 어떤 문서 페이지를 업데이트해야 하는지 말입니다. QA도 동일한 문제를 겪었습니다. 첫 번째 시나리오는 상세했습니다:

{
  "case": "channel changes from email to sms",
  "setup": [
...

두 번째 시나리오는 이미 “이전 단계들을 반복하되, 값을 변경하십시오”로 시작되었고, 세 번째 시나리오는 앞선 두 시나리오를 참조했습니다. 테스터는 어떤 데이터가 상속되는지, 실행 사이에 무엇을 정리(clean up)해야 하는지, 그리고 중복 체크 시 동일한 프로필을 사용할지 아니면 새로운 프로필을 사용할지를 결정해야 했습니다. 롤백(rollback)도 있었지만, 단 하나의 일반적인 지침뿐이었습니다: “알림 채널을 이전 값으로 되돌리십시오.” 이는 실제 테스트를 수행하기에는 충분하지 않았습니다. 만약 시나리오가 이벤트를 생성하고, 프로필을 변경하며, 감사 기록(audit record)을 남긴다면, 롤백은 이러한 각각의 영향에 대해 무엇을 해야 하는지 설명해야 합니다. 그렇지 않으면 다음 실행은 설정(setup)에 기술된 상태와는 다른 상태에서 시작하게 됩니다. 이 패키지는 명백히 잘못되어 보이지는 않았습니다. 적절한 주제를 다루고 있었고, 예상되는 모든 섹션을 포함하고 있었으며, 심지어 설득력 있게 읽히기까지 했습니다. 문제는 누군가가 이를 인수인계(handoff)용으로 사용하려고 했을 때 비로소 드러났습니다. 그때 이 문서가 단순히 작업의 일부를 다음 사람에게 떠넘기고 있다는 사실이 명확해졌습니다.

유효한 형식이 곧 준비된 인수인계는 아니다

많은 AI 프로세스에서 결과 검증은 스키마 검증(schema validation)으로 시작됩니다. 이는 유용합니다. 스키마는 필수 필드가 존재하는지, 값의 타입(value types)이 올바른지, 문서가 예상된 구조를 갖추고 있는지, 그리고 JSON 또는 YAML을 프로그래밍 방식으로 파싱(parse)할 수 있는지를 확인할 수 있기 때문입니다. 예를 들어, 이 검증은 비어 있는 rollback을 실제로 잡아내고 필수 필드가 누락되는 것을 방지할 수 있습니다:

{
  "required": ["title", "test_cases", "rollback"],
  "properties": {
...

하지만 그것(모델)은 해당 롤백(rollback)이 독립적인 테스터에게 충분한지 여부는 알지 못합니다. `

반대 방향으로 너무 치우쳐서 모델이 모든 내부 단계를 토씨 하나 틀리지 않고 반복하도록 요구하기 쉽지만, 대부분의 작업에서 그것은 불필요할 것입니다. 저는 모델의 숨겨진 사고 사슬 (Chain of Thought)을 드러내거나 모든 내부 동작을 제어하는 것에는 관심이 없습니다. 실질적인 프로세스란 외부적으로 기록될 수 있는 것입니다. 즉, 어떤 소스 (sources)가 사용되었는지, 어떤 필수 점검 사항이 완료되었는지, 사람이 어떤 결정을 승인했는지, 수정 후에 어떤 일이 일어났는지, 그리고 왜 프로세스가 특정 최종 상태로 종료되었는지와 같은 것들입니다. 만약 승인 후에 문서가 변경된다면, 이전의 승인은 더 이상 유효한 것으로 간주해서는 안 됩니다. 만약 모델이 이전 단계로 돌아가 정준 값 (canonical value)을 변경한다면, 종속된 문서들은 재생성되거나 명시적으로 재점검되어야 합니다. 만약 필수 데이터가 누락되었다면, 프로세스는 그 공백을 그럴듯한 추측으로 채우기보다는 중단되어야 합니다. 이것을 매우 단순한 프로세스 상태 (process state)라고 생각할 수 있습니다. 여기에는 복잡한 것이 없습니다. 몇 가지 버전, 종속된 산출물 (artifacts)의 상태, 그리고 완료가 허용되는지에 대한 명시적인 답변뿐입니다:

state:
  canonical_value: sms
  approved_version: 3
...

이 파편은 모델이 어떻게 "생각"했는지를 설명하지 않습니다. 그것은 실행에 중요한 것들, 즉 현재 버전, 종속된 문서의 상태, 그리고 프로세스가 종료될 수 있는지 여부만을 기록합니다. 일반적인 프롬프트 (prompt)는 종종 이러한 것들을 명시적으로 나타내지 않습니다. 그것들은 텍스트, 채팅 기록, 그리고 이전 응답의 어딘가에 존재하지만, 반드시 제어된 상태 (controlled state)로서 존재하는 것은 아닙니다.

한 번의 성공적인 실행은 거의 아무것도 증명하지 못한다

또 다른 함정은 긴 프로세스를 오직 해피 패스 (happy path)로만 테스트하는 것입니다. 모델이 완전한 입력을 받고, 사용자가 모든 질문에 답변하며, 문서가 첫 시도에 승인되고, 패키지가 성공적으로 생성되는 경우입니다. 그런 실행이 한 번 이루어지고 나면, 지시 사항(instruction)이 제대로 작동한다고 결론 내리기 쉽습니다. 첫 번째 파트에서 저는 이미 최소 5가지 시나리오 세트를 언급했으며, 각 시나리오는 서로 다른 범주의 문제를 포착합니다. 일반적인 성공적인 실행은 기본 경로 (base route)를 확인합니다. 분기(branch)가 많은 시나리오는 대안이나 회귀(returns)가 나타날 때 모델이 길을 잃는지 보여줍니다. 유효하지 않거나 무관한 입력 (invalid-or-irrelevant-input) 시나리오는 그럴듯하지만 잘못된 패키지를 생성하는 것을 거부할 수 있는지 테스트합니다. 수정 (correction) 시나리오는 이전의 문서와 승인 사항들이 무효화되는지를 보여줍니다. 하드 스톱 (hard stop)은 가장 곤혹스러운 사례를 확인합니다. 즉, 프로세스가 반드시

QA (Quality Assurance)에도 동일하게 적용됩니다. 시나리오가 있다고 해서 각 시나리오가 설정 (setup), 실행 (action), 검증 (verification), 그리고 정리 (cleanup) 과정을 모두 포함한다고 보장할 수는 없습니다. 모델은 당신이 설명한 것에 최적화됩니다. 만약 기준이 단순히 섹션의 존재 여부 수준에서 정의된다면, 모델은 정확히 그 수준에서만 기준을 충족할 수 있습니다. 이는 AI만의 고유한 문제는 아닙니다. 사람 또한 형식적으로는 완벽하지만 실질적으로는 부실한 문서를 작성할 수 있습니다. 차이점은 규모(scale)입니다. 모델은 방대한 패키지를 매우 빠르게 생성할 수 있으며, 불완전함 또한 그만큼 빠르게 확장할 수 있습니다.

지금 바로 확인할 수 있는 것들

AI가 생성한 패키지를 수락하기 전에, 최소한 몇 가지 질문을 던져볼 것을 권장합니다. 이 질문들이 전체 검토를 대신할 수는 없지만, 인수인계 과정에서 보았던 것과 동일한 결함들이 올바른 구조 뒤에 숨어 있는지 빠르게 드러내 줄 것입니다.

• 작성자의 추가 설명 없이도 다음 작업자가 업무를 수행할 수 있는가?
• 모든 테스트 케이스가 독립적(self-contained)인가?
• 단순한 일반적 희망 사항이 아닌, 구체적인 기술적 산출물(deliverables)이 정의되어 있는가?
• 상태를 변경하는 모든 작업에 자체적인 롤백 (rollback) 또는 정리 (cleanup) 절차가 있는가?
• 핵심 가치를 뒷받침하는 출처가 명확한가?
• 문서가 변경된 후 이전의 승인 사항들이 무효화되는가?
• 수정 사항이 반영된 후 의존 관계에 있는 산출물(artifacts)들이 업데이트되는가?
• 필수적인 사실이 누락되었을 때도 프로세스가 여전히 성공적으로 종료될 수 있는가?
• 형식을 확인하는 것뿐만 아니라, 인수인계 내용이 실제로 사용 가능한지 확인하고 있는가?

이 체크리스트는 새로운 플랫폼이나 언어를 필요로 하지 않습니다. 코드 리뷰 (code review), QA 리뷰, 또는 일반적인 문서 리뷰에 추가할 수 있습니다. 때로는 이것만으로도 보기에는 좋지만 사람들이 실제로 업무에 활용할 수 있는 문서 사이의 차이를 드러내기에 충분합니다.

통제권은 어디에 있어야 하는가?

이러한 사례를 겪고 나면 자연스러운 반응은 더 많은 검증자 (validators)를 추가하는 것입니다. 하나는 Jira 구조를 확인하고, 다른 하나는 QA 완결성을 확인하며, 세 번째는 문서 간의 일관성을 확인합니다. 워크플로 (workflow)가 단계의 순서를 제어하고, 사람이 중요한 결정을 승인합니다. 이는 어느 정도 효과가 있으며, 한동안은 문제가 해결된 것처럼 느껴질 수 있습니다. 그러다 또 다른 질문이 나타납니다. 프로세스 전체에 대한 책임은 누구에게 있는가? 워크플로는 다음 단계가 무엇인지 알고, 검증자 (validator)는 특정 문서를 확인하며, 평가자 (evaluator)는 결과에 점수를 매기고, 사람은 프로세스를 중단할 수 있습니다. 하지만 이 계층들 중 어느 것도 상태 (state), 소스 (sources), 승인 (approvals), 수정 경로 (correction paths), 최종 프로세스 상태 (final process states), 그리고 산출물 간의 의존성 (dependencies)과 같은 전체 그림을 반드시 스스로 파악하고 있지는 않습니다.

만약 워크플로가 모든 단계를 완료하고, 검증자들이 모든 문서를 승인했음에도 불구하고 결과가 여전히 틀렸다면 — 실제로 프로세스를 통제하고 있었던 사람은 누구였을까요?