통제 전환

프롬프트를 고치고, 컨텍스트를 늘리고, 실행을 다듬는다. 그런데도 같은 문제가 돌아온다.

앞에서 본 문제는 낯설지 않다.

시스템이 조용히 어긋나고, 수정해도 다른 곳에서 다시 나타나고, AI를 쓰면서 그 속도가 빨라진다. 이 상황에 맞닥뜨리면 대부분은 같은 방향으로 대응한다.

프롬프트를 더 정교하게 만들고, 컨텍스트를 더 많이 제공하고, 규칙을 더 촘촘하게 적는다.

처음에는 효과가 있다. 조금 더 일관된 결과가 나오고, 조금 덜 흔들리는 것처럼 보인다. 그래서 계속한다. 더 정교하게, 더 많이.

하지만 오래 가지 않는다.

같은 문제가 다른 형태로 다시 나타난다. 막았다고 생각한 지점이 아니라, 다른 경로에서 터진다. 그래서 다시 고친다. 그리고 다시 어긋난다.

이 과정이 반복되는 이유가 있다.

프롬프트, 컨텍스트, 실행 — 이 세 가지는 모두 같은 한계를 공유한다.

경로를 고정하지 못한다. ^{핵심 한계}

프롬프트는 방향을 준다. 컨텍스트는 상태를 전달한다. 실행은 결과를 만든다. 하지만 어느 것도, 그 결과가 어떤 경로를 통해 만들어졌는지를 통제하지 않는다. 경로는 여전히 열려 있다.

세 문서가 겨냥하는 지점도 다르다.

• 프롬프트 한계 - 방향은 주지만 합법 경로를 고정하지 못한다
• 컨텍스트 한계 - 상태를 설명하지만 시간에 걸쳐 유지하지 못한다
• 실행 모델 - 절차가 매번 재선택되어 같은 요청이 다른 경로로 흘러간다

이 문서가 말하는 통제는 추상 원칙이 아니다. Roslyn Analyzer, ESLint, runtime guard, transition validator, test harness처럼 실패를 실제로 발생시키는 기술적 장치를 가리킨다.

이 섹션은 그 한계를 각각 들여다본다.

프롬프트가 왜 경로를 막지 못하는지, 컨텍스트가 왜 상태를 유지하지 못하는지, 실행이 왜 동일하게 반복되지 않는지.

목적은 이 방식들을 부정하는 게 아니다. 어디까지 가능한지, 그리고 어디서부터 다른 무언가가 필요한지를 보는 것이다.