긴 대화가 흐트러질 때: AI‑assisted coding의 숨겨진 오류

Source: Dev.to

(번역할 텍스트가 제공되지 않았습니다. 번역이 필요한 본문을 알려주시면 한국어로 번역해 드리겠습니다.)

컨텍스트 드리프트가 몰래 들어오는 경우

나는 긴 대화가 하나의 단일하고 안정적인 기억이 아니라는 것을 힘들게 배웠다. 모델은 여전히 이전 턴을 볼 수 있지만, 어텐션은 최근 토큰을 더 선호한다. 이는 한 시간 전에 제시한 제약 조건이 조용히 우선순위에서 떨어진다는 뜻이다. 나는 세션을 시작할 때 어시스턴트에게 어떤 프레임워크인지, 어떤 버전인지, 그리고 기존 헬퍼를 선호한다는 것을 알려준다. 같은 스레드에서 나중에 어시스턴트가 다른 생태계의 API를 제안하기 시작하고, 테스트가 실패할 때서야 그것을 눈치챈다. 변화는 미묘하다. 제안은 계속 설득력 있게 들리므로, CI에서 무언가 깨질 때까지 계속 받아들인다.

내가 겪은 구체적인 실패

• HTTP 클라이언트 교체 – 초기 메시지는 명시적으로 requests와 동기 코드에 관한 것이었습니다; 몇 차례 프롬프트 후 모델이 async httpx 예시를 반환하기 시작했습니다. 차이가 사소해 보여서 변경을 병합했습니다. 로컬에서는 테스트가 통과했지만 이벤트 루프가 다른 스테이징에서는 실패했습니다. 근본 원인은 “동기 유지”라는 제약이 채팅 상단에 있었지만 이후 완성에 더 이상 반영되지 않은 것이었습니다.

• 언어 기능 가정 – 어시스턴트에게 우리가 Python 3.9를 사용하고 있다고 알려줬습니다. 여러 차례 대화 후 어시스턴트가 match/case 코드 조각을 제안했지만, 별도의 언급이 없었습니다. 저는 3.10이 설치돼 있어 로컬에서는 코드가 컴파일됐지만 팀원에게는 그렇지 않았습니다. 이 때문에 문법 오류를 어시스턴트에게서 추적하는 데 몇 시간이 걸렸습니다. 이는 극단적인 환상이 아니라, 전체 시스템을 실행할 때만 드러나는 작은 변화들입니다.

작은 오류가 누적되는 이유

긴 대화는 일련의 작은 결정들을 만들어냅니다. 한 프롬프트가 변수 이름을 바꿉니다. 다음 프롬프트는 그 변경을 기반으로 하여 다른 모듈 구성을 가정합니다. 체인 내의 어떤 도구 호출이라도 부분적이거나 형식이 잘못된 출력을 반환하면, 모델은 종종 가장 가능성 높은 연속으로 빈틈을 메웁니다. 검색 도구가 시간 초과되었지만, 어시스턴스는 마치 검색이 정확히 필요한 결과를 반환한 것처럼 계속 진행했습니다. 그가 만든 코드는 우리 코드베이스에 존재하지 않은 함수를 참조하고 있었습니다.

모델 출력이 스크립트, CI, 혹은 다른 도구에 전달될 때, 침묵이나 부분적인 실패가 증폭 지점이 됩니다. 누락된 검사, 약간 잘못된 import, 혹은 잊힌 헤더가 이후 스레드에서 새로운 assumption으로 변합니다. 그래서 저는 이제 생성과 검증을 별개의 단계로 다룹니다. 모델에게 초안을 작성하도록 요청한 뒤, 결정적인 검사를 실행하고 라이브러리 동작에 대한 모든 주장에 대해 명시적인 증거나 출처를 요구합니다. API 세부 정보를 확인해야 할 때는 구조화된 연구 흐름을 자주 사용합니다.

실제로 사고를 줄인 운영 변경 사항

먼저 세 가지를 바꿨습니다: 강제 재설정, 모든 로그 기록, 그리고 도구 출력물을 필수 체크포인트로 만들기.

1. Resets – 큰 작업을 여러 채팅으로 나누고 각 새 세션에서 제약 조건을 명시적으로 다시 선언합니다. 번거롭게 들릴 수 있지만, 흐트러진 세션을 디버깅하는 것보다 훨씬 효율적입니다.
2. Logging – 어시스턴트 출력과 모든 도구 응답을 추적 레이어에 기록하여 제안이 어디서 시작됐는지 재생할 수 있게 합니다. 이 재생을 통해 HTTP 클라이언트 사고에서 동기에서 비동기로 전환된 순간을 정확히 찾을 수 있었습니다.
3. Guardrails – 런타임, 버전, 스타일 가이드를 고정시키는 명시적인 프롬프트를 사용해 모델이 코드를 생성하기 전에 반드시 참조해야 하는 짧은 체크리스트를 제공합니다.

두 번째 의견이 필요할 때는 같은 프롬프트를 공유 채팅 작업 공간에 있는 다른 모델에 넣어 차이 패턴을 확인합니다. 이 비교를 통해 숨겨진 가정을 단일 답변보다 빠르게 드러낼 수 있습니다. 검증을 위해 모델이 API 변경에 대한 인용이나 정확한 함수 시그니처를 포함하도록 요구하고, 이를 집중된 조사 흐름을 통해 문서와 대조합니다.

When to stop the chat and run tests

제 현재 휴리스틱은 간단합니다. 세션이 몇 차례를 넘어서거나 여러 하위 시스템에 걸쳐 진행될 경우, 중단하고 검증합니다. 단위 테스트를 실행하고, 모든 환경에서 코드가 실행될 때 import와 런타임 버전이 일치하는지 확인합니다. 제안된 변경 사항에 새로운 의존성이 필요하다면, 이를 새로운 프로젝트로 간주하고 의존성 정책을 미리 명시한 새로운 대화를 시작합니다. 저는 모델이 초안을 작성하고 탐색하도록 허용하지만, 명시적인 검증과 로그 없이 초안이 전파되도록 두지는 않습니다. 이렇게 하면 작은 컨텍스트 드리프트가 배포 장애로 이어질 가능성을 줄일 수 있습니다.