긴 대화가 컨텍스트 드리프트와 숨겨진 오류를 초래할 때

I’m happy to translate the article for you, but I’ll need the full text of the post (the content you’d like translated). Could you please paste the article’s body here? Once I have the text, I’ll provide a Korean translation while keeping the source link, formatting, markdown, and any code blocks or URLs unchanged.

왜 긴 스레드는 일관돼 보이지만 몰래 변질되는가

나는 리팩터링 작업을 모델과 함께 하면서 일주일 동안 하나의 채팅을 열어 두었다. 처음에는 제안이 내 스타일과 맞았다: 작은 함수, 설명적인 이름, 단위 테스트 스케치 등. 주 중반에 들어서 모델이 내가 전혀 사용하지 않는 패턴을 추천하기 시작했다. 명백히 틀린 것은 아니었지만 미묘하게 달랐다. 모델은 여전히 같은 어조로 답했지만, 주의가 스레드의 최신 예시들로 이동했다. 최신 토큰이 우세해졌다. 초기 프롬프트를 이끌던 정신 상태가 얇아졌다.

그 변화는 극적인 전환이 아니다. 서서히 스며드는 것이다. 나는 데이터베이스 마이그레이션에 대해 물었을 때 다른 ORM을 전제로 한 답변을 받았다. 나는 코드 형태를 받아들였고 나중에 호출 서명이 존재하지 않음을 깨달았다. 그때쯤이면 여러 로컬 변경이 잘못된 가정에 의존하고 있었다.

작은 숨겨진 가정이 버그가 된다

구체적인 예시 하나: 나는 모델에게 일련의 SQL 업데이트를 배치 트랜잭션으로 변환하도록 요청했다. 긴 대화 중 어느 순간 모델은 자동 커밋이 꺼져 있다고 가정하기 시작했다. 모델이 만든 코드에서는 한 분기에서 명시적인 커밋이 누락되었다. 로컬에서는 테스트가 통과했는데, 개발용 DB 드라이버가 프로덕션과 다르게 동작했기 때문이다. 이 불일치가 프로덕션에서 조용한 실패를 일으켰다. 나는 커밋 의미론에 대해 물어보지 않았는데, 모델이 우리 DB에 대한 이전 메모를 기억하고 있을 거라 생각했기 때문이다. 하지만 모델은 신뢰할 수 있게 기억하지 못했다.

또 다른 경우, 모델이 라이브러리의 이전 버전과 일치하는 구성 플래그 이름을 제안했다. 리팩터링 과정에서 그 제안들을 여러 개 연결해 마이그레이션 스크립트를 만들었다. 그 스크립트는 스테이징 환경에서 실행돼 잘못된 S3 프리픽스에 데이터를 기록했다. 각각의 실수는 그럴듯했지만, 모두 합쳐지면서 사용자에게 영향을 주는 장애가 발생했다.

Tool calls fail and the model fills the gaps

우리는 모델을 도구에 연결합니다: 린터, 테스트 러너, 패키지 매니저, 작은 셸 등. 그로 인해 실패 가능성이 늘어났습니다. 저는 오케스트레이터가 테스트 요약에서 부분적인 JSON을 반환하고 모델이 누락된 필드가 존재하는 것처럼 계속 진행하는 것을 본 적이 있습니다. 출력은 일관되어 보였습니다. 또한 도구 출력이 잘못된 형식이라 실패한 작업을 무시하기도 했습니다. 로그에서는 유일한 단서는 서로 다른 체크섬과 나중에 기대했던 동작을 되돌린 변경이었습니다.

이 경험을 통해 도구 출력을 신뢰할 수 없는 입력으로 다루어야 함을 배웠습니다. 이제 우리는 모델 요약만이 아니라 원시 도구 응답도 기록합니다. 응답이 잘려 있거나 필수 필드가 없을 경우 우리는 중단하고 원시 페이로드를 사람에게 보여줍니다. 그런 다음 모델에게 전체 데이터를 사용해 다시 처리하도록 요청할 수 있습니다. 이는 보이지 않는 가정을 하는 대신 강제적인 정지를 만들게 합니다.

실용적인 가드레일 설정

나는 이러한 은밀한 오류를 어느 프롬프트 조정보다도 더 줄여준 세 가지 작은 규칙을 추가했다.

1. 연구와 코드 스레드를 분리한다.
   깊이 있는 탐색을 별도의 작업 공간으로 옮겨 코딩 스레드가 짧고 명확하게 유지되도록 했다. 탐색을 위해서는 인용과 원시 출력이 한 곳에 모여 있는 집중된 연구 흐름을 사용한다; 출처를 검증해야 할 때는 실시간 리팩터링 세션 대신 공유 작업 공간을 이용해 비교할 수 있는 연구 세션으로 작업을 옮긴다.

2. 몇 차례마다 컨텍스트를 리셋하거나 스냅샷을 만든다.
   스레드가 반 다스(6) 이상의 편집을 초과하면 상태를 스냅샷으로 저장하고, 가정들을 명시적으로 열거한 새로운 프롬프트로 시작한다.

3. 모델 출력에 스키마 검사를 적용한다.
   모델이 함수 시그니처나 의존성 이름을 주장하면, 작은 검증기가 이를 레포와 대조해 확인한 뒤 변경을 적용한다. 빠르게 실패하고, 모든 것을 로그에 남긴다.

이것들은 화려하지 않지만, 작은 실수들의 연쇄를 막는다.

언제 로그를 남기고, 언제 컨텍스트를 리셋하며, 언제 증거를 요청할지

로그를 남기는 것이 영리한 프롬프트보다 더 중요합니다. 저는 모델 제안, 도구 출력, 인간 승인 등을 순수 텍스트 타임라인으로 기록합니다. 그 타임라인 덕분에 생산 환경에서 발생한 사고를 쉽게 재구성하고 가정이 처음 등장한 지점을 확인할 수 있었습니다. 스테이징 환경에서 이상 현상이 나타나면, 변화를 일으킨 정확한 모델 입력을 재생합니다. 재현 가능성이 바로 드리프트를 발견하는 방법입니다.

컨텍스트를 리셋하는 비용은 연쇄적인 디버깅보다 저렴합니다. 세션에 서로 다른 스타일이나 여러 연구 흐름이 섞여 있다면, 새 채팅을 시작하고 제약 조건을 다시 명시한 뒤 검증된 스니펫만 붙여넣습니다. 모델이 버전, 테스트, 변경 로그 등을 언급하면 출처를 요구하고, 가능하면 도구를 강제로 사용해 권위 있는 파일을 가져오게 합니다. 우리는 이런 종류의 출처 확인을 위해 별도의 채널을 사용해 메인 스레드에 잡음이 쌓이지 않도록 합니다. 저는 여전히 모델이 초안을 작성하는 것은 신뢰하지만, 모든 숨은 가정을 기억하도록는 더 이상 신뢰하지 않습니다.