편집하기 전에 마커를 에코(Echo)하는 기능

저는 어시스턴트가 제가 방금 작성한 마커를 트리에 에코할 수 있을 때까지 처음 15분 동안은 신뢰하지 않습니다. 활발한 대화는 토큰이 이동할 수 있다는 것만 증명할 뿐이며, 이것이 논의되는 워크스페이스인지 여부와는 다른 문제입니다. 만약 마커가 돌아오지 않는다면, 저는 단 하나의 변경 사항을 요청하기 전에 세션을 중단하고 가시성을 수정합니다. 거울에 전혀 모르는 거리의 모습이 비친다면 운전을 계속하시겠습니까?

첫 15분은 보통 조용하게 실패하며, 팀원에게 스크린샷으로 찍어줄 만한 극적인 충돌을 일으키지 않습니다. 인증하고, 모델을 선택하고, 로딩 스피너가 안정되는 것을 지켜본 다음, 피하려고 했던 리팩토링에 대한 단락을 붙여넣습니다. 답변은 자신감 있게 들리고 몇 개의 파일을 언급하지만, 여전히 실제로 문제가 되는 함수를 놓칩니다. 그 누락은 보통 도구가 이 워크스페이스가 아닌 샘플 레포지토리, 부모 디렉터리 또는 어제의 체크아웃을 보고 있다는 것을 의미합니다.

저는 그 누락을 프롬프트에 형용사 하나와 두 번째 시도를 더해야 하는 것이 아니라 가시성 실패로 간주합니다. 또 다른 시도는 실제로 신경 쓰는 코드를 볼 수 없는 대화에 세션을 소비할 뿐입니다. 제가 유지하는 유일한 수정 사항은 새로운 프롬프트 템플릿보다 작고, 대부분의 설정 가이드가 인정하는 것보다 더 거칩니다. 보여준 적이 없는 주방을 리모델링하도록 계약자에게 고용하시겠습니까?

해결책은 첫 실제 요청 전에 실행되는 마커 프로브(marker probe)입니다. 이 프로브는 에코가 잘못되었거나 누락되면 계속하는 것을 거부합니다. 저는 작업 트리(working tree)에 작은 파일을 넣고, 훈련 데이터가 암기했을 수 없는 임의 토큰으로 채웁니다. 그런 다음 어시스턴트에게 그 파일 하나를 읽고, 어떤 조언이나 편집도 첨부하지 않고 해당 토큰을 반복하도록 요청합니다. 만약 토큰이 온전하게 돌아온다면, 저는 이 세션이 이 트리를 볼 수 있다는 것을 알게 되고, 그때서야 변경 사항을 허용합니다.

마커를 여러분이 만들고 있는 제품의 단위 테스트(unit test)로 생각하기보다는 코트 보관소 티켓처럼 생각하세요. 안내원은 여러분의 코트를 이해할 필요가 없고, 어시스턴트도 여러분의 아키텍처를 이해할 필요가 없습니다. 유일한 임무는 같은 티켓을 돌려주는 것이고, 잘못된 티켓은 여러분이 잘못된 카운터에 서 있다는 의미입니다. 제가 꼬리표(stub)에 인쇄된 번호를 읽기도 전에 낯선 사람이 소매를 줄여 입게 내버려 두겠습니까?

아래 스크립트는 실행할 수 있는 로컬 제안이며, 저는 벤치마크(benchmark), 할당량(quota), 또는 실험실 결과(lab result)를 보고하는 것이 아닙니다. 이 스크립트는 git 작업 트리(git work tree) 외부에서는 시작을 거부하고, 짧은 임의 토큰을 작성한 다음, 편집을 금지하는 프롬프트를 출력합니다. 저는 무시 파일(ignore file)이 쓰기 가능할 때 프로브 디렉터리(probe directory)가 히스토리에서 제외되도록 노력하여, 통과된 확인 작업이 쓰레기가 되는 것을 막습니다. 만약 여러분의 정책이 스크래치 파일(scratch file)조차 금지한다면, 이 스크립트는 건너뛰고 데모를 보기 위해 그 규칙을 약화시키지 마세요.

#!/usr/bin/env bash
# visibility-probe.sh — 로컬 제안이며, 측정된 벤치마크가 아닙니다.
set -euo pipefail
...

어시스턴트가 답변한 후, 저는 그 답변을 두 번째 명령어로 파이프(pipe)하여 디스크의 파일과 비교합니다. 일치 여부는 축하할 일이 아니며, 불일치 역시 제가 질문을 더 긴 목소리로 재진술함으로써 해결하는 미스터리가 아닙니다. 이 확인기는 공백(whitespace)을 제거하여 끝에 붙은 개행 문자(trailing newline)가 다른 작업 공간인 것처럼 속여 나중에 프로브를 무시하도록 만들지 못하게 합니다. 명백히 보이는 곳에 있는 16진수 문자 16자를 반복할 수 없는 답변과 협상함으로써 무엇을 얻겠습니까?

#!/usr/bin/env bash
# check-echo.sh — 사용법: pbpaste | ./check-echo.sh
set -euo pipefail
...

저는 그 두 명령어를 순서대로 실행하고, 원본 요청을 다시 건드리기 전에 FAIL 라인을 읽습니다. Linux에서는 제가 이미 신뢰하는 기기에 프로브가 맞아야 하므로 pbpaste 대신 xclip으로 클립보드를 읽게 합니다. PASS는 단지 이름이 지정된 파일에 작은 변경을 요청할 수 있다는 의미일 뿐이며, 저는 커밋하기 전에 여전히 diff를 검토합니다. 혹시 제안 사항을 10분 동안 디버깅하다가 그 도구가 형제 디렉터리를 설명하고 있었다는 것을 알게 된 적 있으신가요?

chmod +x visibility-probe.sh check-echo.sh
./visibility-probe.sh
# 출력된 프롬프트를 어시스턴트에게 복사한 다음, 그 답변만 파이프로 전달합니다.
...

체크가 실패하면, 저는 두 번째 채팅을 열고 희망하지 않습니다. 왜냐하면 운은 마운팅 전략이 아니기 때문입니다. 저는 작업 디렉터리를 출력하고, 마커 파일이 여전히 존재하는지 확인하며, 그 내용을 제가 보냈다고 생각했던 문자열과 비교합니다. 그런 다음 어시스턴트가 부모 폴더에 연결되었는지, 컨테이너 경로에 연결되었는지, 아니면 제 프로젝트 이름과 공유하는 샘플에 연결되었는지 확인합니다. 이 세 가지 점검으로도 누락된 이유를 설명할 수 없다면, 저는 맹목적인 세션이 정상이라고 스스로에게 가르치기보다는 중단합니다.

에코가 호스팅되는 공간에서 발생해야 할 때는 MonkeyCode의 무료 모델 액세스와 그 단일 시도를 위한 무료 서버 옵션을 사용합니다. 공개적으로 밝힙니다: 이 글은 MonkeyCode의 제품 홍보의 일환으로 작성되었습니다. 저는 이름, 할당량, 하드웨어 또는 해당 혜택이 영원히 유지된다는 약속에 의존하는 것이 아니라 오직 그 두 가지 가용성 사실에만 기대고 있습니다. 만약 그 공간이 가장 간단하다면 거기서 프로브를 실행하고, PASS나 FAIL을 직접 읽으며, 그 공간이 '완료'가 무엇을 의미하는지 결정하도록 내버려두지 마십시오.

프로브는 날카로운 모서리를 가지고 있어서, 녹색 PASS가 마땅히 가야 할 곳보다 더 멀리 이동하는 것을 보기보다는 그 이름을 붙이는 편이 낫습니다. 에코된 토큰은 이 세션이 하나의 파일을 읽을 수 있다는 것만 보여줄 뿐, 모든 경로가 보이거나 쓰기가 이루어질 것이라는 것은 아닙니다. 이는 마커를 반복하고 자신이 열지 않은 파일에 편집 내용을 꾸며내는 답변을 잡아내지는 못할 것입니다. 검토된 프로덕션 변경 사항, 에어갭(air-gapped) 프로세스 또는 임시 파일 사용 금지가 필요한 사람은 이 단축키를 건너뛰어야 합니다.

또한 저는 마커 안에 비밀 정보를 숨기는 것을 거부합니다. 왜냐하면 호스팅 모델은 당신이 반복하도록 요청하는 모든 문자열을 기록할 수 있기 때문입니다. openssl이나 다른 비(非)비밀 문자열의 무작위 출력을 사용하고, 세션이 끝날 때 프로브 디렉토리를 삭제하세요. ignore append가 실패하여 ignore 파일이 읽기 전용인 경우, 무엇인가 커밋하기 전에 마커를 직접 제거하십시오. 15분간의 승리가 만약 원격 히스토리에서 토큰을 지우는 데 저녁 시간을 보내야 한다면 여전히 의미가 있을까요?

에코가 통과하면, 제 다음 메시지는 의도적으로 지루할 것입니다: 이름이 지정된 파일 하나, 실패하는 명령어 하나, 그리고 그 명령어가 필요로 하는 변경 사항만입니다. 세션 초기에 투어나 재설계를 요구하지 않는 이유는 마커가 오직 구체성만을 구매했기 때문입니다. diff가 저장되거나 확인에 실패하면 채팅을 삭제할 수 있으므로, 처음 몇 분이 일기가 되는 것을 막아줍니다. 파일에 접근하도록 허용되기 전에 그 파일을 볼 수 있다는 것을 증명하는 것보다 더 나은 세션 사용법이 있을까요?