긴 채팅이 조용히 빌드를 깨뜨릴 때

발행: (2025년 12월 26일 오후 04:16 GMT+9)
8 분 소요
원문: Dev.to

Source: Dev.to

위에 제공된 소스 링크 외에 번역할 텍스트가 없습니다. 번역이 필요한 본문을 제공해 주시면 한국어로 번역해 드리겠습니다.

컨텍스트는 생각보다 빨리 사라진다

나는 마이그레이션, API 표면, 테스트 하네스를 반복하는 일주일 간의 디버깅 스레드를 진행했다. 시작할 때 모델에게 다음과 같이 알려줬다: Node 18, Postgres 13, TypeScript, 네이티브 모듈 없음. 몇십 차례의 대화 후에 어시스턴스는 최신 Postgres에만 존재하는 Python 스니펫과 클라이언트 라이브러리를 제안하기 시작했다. 각 새로운 답변은 여전히 일관돼 보였지만, 내가 제시한 제약 조건을 따르지 않게 되었다.

그 결과는 빠른 수동 검사는 통과했지만 CI에서는 테스트 DB가 프로덕션 스키마의 MySQL 복제본이었기 때문에 실패했다. 실패 양상은 눈에 띄는 것이 아니라, 대화와 실제 실행 시스템 사이에 서서히 생겨나는 불일치—느린 컨텍스트 드리프트였다.

Hallucinations sneak in through missing tools

우리는 모델을 스키마 추출기와 CI 상태 엔드포인트에 연결합니다. 이러한 도구들은 때때로 부분적인 혹은 빈 페이로드를 반환하고, 모델은 그 빈틈을 메우게 됩니다.

  • 예시: 추출기에서 잘린 스키마가 반환되었고, 모델이 컬럼 타입을 추측했습니다.
  • 생성된 마이그레이션이 로컬에서 실행되어 잘못된 정밀도의 컬럼을 만들었습니다.
  • 테스트에서는 스키마 레이어를 모킹했기 때문에 이를 잡지 못했습니다.

이러한 추측을 바탕으로 이후 변경 사항이 잘못된 컬럼에 조용히 의존하게 되었습니다. 하나의 잘못된 가정이 긴 흐름 속에서 작은 오류가 되어, 이후 변경들의 기반이 되는 점이 단일 환각 라인보다 더 우려됩니다.

긴 세션에서 숨겨진 가정이 곱해진다

채팅을 열어두면 매번 암묵적인 기본값이 누적됩니다. 모델은 최신 토큰을 선호하기 때문에 새로운 예시와 즉석 발언이 원래 제약보다 더 큰 비중을 차지합니다.

  • 누군가 같은 스레드에 다른 저장소의 코드를 붙여넣은 뒤, 어시스턴스가 기본 타임아웃, 메모리 제한, 심지어 다른 인증 흐름까지 가정하기 시작한 것을 보았습니다.
  • 모델이 잘못된 런타임이나 의존성 버전을 가정하면, 구문은 올바르지만 실제 동작은 틀린 코드를 제안합니다.

이를 완화하기 위해 정기적인 리셋을 수행하고 프롬프트 상단에 명시적인 매니페스트 블록을 추가하기 시작했습니다. 접근 방식 간 비교가 필요할 때는 별도의 멀티‑모델 워크스페이스를 사용하여 하나의 대화에서 발생한 드리프트가 다른 대화에 영향을 주지 않도록 합니다. 이러한 비교 공간이 있으면 공유 채팅 도구를 통해 대안을 나란히 테스트할 때 제어된 방식으로 진행할 수 있어 도움이 됩니다.

피드백 루프를 끊는 실용적인 검증 및 로깅

  1. Logging – 모델이 반환하는 모든 내용은 프롬프트와 도구 출력과 함께 원시 텍스트로 기록됩니다. 이를 통해 시간에 따라 응답을 비교(diff)하고 제안이 이전 제약조건에서 벗어나는지를 감지할 수 있습니다.
  2. Pipeline checks – 생성된 코드는 검토 전에 파이프라인을 통과합니다:
    • 정적 타입 검사,
    • 정제된 데이터셋을 사용한 샌드박스 실행,
    • 환경 가정을 검증하는 목표형 통합 테스트 집합.
  3. Tool validation – 스키마 추출기가 N개 미만의 컬럼을 반환하거나 상태 엔드포인트가 느릴 경우, 모델이 추측하도록 두지 않고 중단하여 도구 오류를 인간에게 표시합니다.
  4. Citation verification – 출처와 검증을 위해 모델에게 정확한 문서 섹션이나 변경 로그 항목을 인용하도록 요청하고, 채팅 내 주장에 바로 신뢰하기보다 공식적인 연구 워크플로우를 사용해 교차 검증합니다.

실제로 현재 따르는 운영 규칙

  • Segment work – 긴 작업을 짧은 구간으로 나눕니다. 자연스러운 체크포인트에서 컨텍스트를 재설정합니다: 주요 리팩터링 전, 병합 전, 그리고 새로운 사람이 스레드에 참여할 때마다.
  • Manifest requirement – 대화 상단에 최소 매니페스트를 요구합니다: 런타임, DB, 테스트 픽스처, 그리고 금지된 변경 사항의 짧은 목록.
  • Tool call logging – 모든 툴 호출을 기록하고 간단한 어설션으로 응답을 검증합니다.
  • Changelog & assumptions – 모델이 기계가 읽을 수 있는 형태로 간결한 변경 로그와 모델이 만든 가정 목록을 출력하도록 강제합니다. 이를 통해 CI가 새로운 명시되지 않은 가정을 도입하는 병합을 거부할 수 있습니다.
  • Structured research pass – 보다 풍부한 검증이나 삼각측량이 필요할 때, 모델 추론과 증거 수집을 분리하고 외부 소스를 선택적 인용이 아닌 사실 기반으로 취급하는 구조화된 연구 단계를 거치도록 합니다.
Back to Blog

관련 글

더 보기 »