AI 에이전트가 멀쩡한 코드를 '수정'하려고 해서 곤란했던 적 있나요?

한두 번이 아님. 난 에이전트의 상시 지시사항 파일에 이렇게 적어둠. 모든 프롬프트에 넣는 게 아니라 말이야. 요청한 작업 외에 눈에 띄는 건 보고서 끝에 후속 섹션으로 넣고, 절대 diff에는 넣지 말라고. 덕분에 리뷰 방식이 깜짝 '개선'을 찾아내는 것에서 diff가 요청 사항과 일치하는지 확인하는 것으로 바뀌었음. 여전히 진짜 버그는 잡아내지만, 언제 수정할지는 내가 결정함.

맞음. 난 '참고 사항'을 위한 임시 마크다운 파일을 따로 유지해서 나중에 검토함. 그냥 둘지, 아니면 백로그에 이슈로 등록할지 결정하는 거지.

응, 특히 'high thinking'을 쓰거나 프롬프트가 명확하지 않을 때 자주 그래. 그냥 '수정'만 하는 게 아니라 프로젝트 폴더 밖의 불필요한 파일에 접근하거나 수정하려고도 함.

그래서 난 보통 복잡하지 않은 작업에는 'low thinking'을 쓰고 'Plan Mode'를 먼저 켬. 모델이 뭘 할지 계획을 설명하면, 내가 원하는 대로 될 때까지 계획을 검토하고 다듬음. 보통 이렇게 하면 문제를 예방하는 데 도움이 됨.

또한, Codex나 DeepSeek CLI 같은 일부 에이전트는 실제로 계속하기 전에 확인을 요청하기도 함. 난 Pi를 쓰는데, 계획 모드도 똑같이 작동해서 개인적으로 꽤 괜찮다고 생각함.

시니어 엔지니어 감성이네. 다 건드려놓고 테스트는 안 함.

그 함수가 '잘 작동'했던 건 경험적인 이야기일 뿐, 기계적으로 정의된 게 아니었음. AI는 바로 그 틈을 파고드는 거임. AI는 '지금 상태로 충분함'과 '지저분하지만 없으면 안 됨'을 구분하지 못함.

수정은 정리하기 전이 아니라 그보다 먼저 해야 함. 바로 특성 테스트(characterization test)를 먼저 작성하는 거임. 함수가 뭘 해야 하는지 테스트하는 게 아니라, 현재 어떻게 작동하는지(엣지 케이스와 지저분한 특성까지 포함해서) 기록하는 테스트를 말이야. 그러고 나서 정리를 맡기는 거지. '동작을 바꾸지 마'라는 말은 모델이 대충 읽어버리는 문장일 뿐이지만, 테스트는 모델이 더 나은 버전을 내놨을 때 크게 실패하며 알려주는 검증 수단이 됨.

이 테스트는 더 어려운 상황에서도 빛을 발함. 잘못된 동작이지만 의존하고 있던 기존 코드 말이야. 진짜 좋은 수정이 특성 테스트를 통과하지 못할 때, 그건 서프라이즈가 아니라 의도적으로 대화를 나눠야 할 주제가 되는 거임.