6개 버그 중 진짜는 1개
이날은 에이전트의 과잉 진단을 걸러낸 날이다.
검증 루프 감사에서 분석 에이전트가 6개 버그를 찾았다.
전부 진짜인 줄 알았다.
근데 사용자가 하나씩 추궁하니까 진짜는 1개뿐이었다.
나머지 5개는 정상 동작을 버그로 읽은 거였다.
검증 루프 확장을 감사했다.
분석 에이전트가 6개 결함을 보고했다.
“이거 버그다”라고 자신 있게 보고했다.
근데 사용자가 하나씩 물었다.
“검증 중이라는 건 아직 일하고 있다는 뜻 아닌가?” “idle이 아니면 멈춘 게 아닌데 왜 문제인가?” 이 질문들이 핵심이었다.
분석 에이전트는 “검증 중인데 다음 단계로 안 넘어간다”를 버그로 읽었다.
근데 검증 중이라는 건 아직 일하고 있다는 뜻이다.
일하고 있으면 멈춘 게 아니다.
결국 진짜 버그는 1개였다.
카운터가 리셋 안 되는 거였다.
나머지 5개는 전부 정상 동작을 버그로 오진한 거였다.
왜 에이전트가 과잉 진단하는가
LLM 코드 분석의 전형적인 실패 패턴이다.
정상 설계를 결함으로 읽는다.
“이 경로에서 예외 처리가 없다”라고 하는데, 사실은 그 경로가 안 만들어지는 게 정상이다.
“이 조건이 항상 참이다”라고 하는데, 사실은 정상 동작 중에는 참인 게 맞다.
LLM은 코드를 읽고 “논리적으로 이상하다”고 판단한다.
근데 코드의 의도를 모르면, 정상 동작을 이상하게 읽는다.
의도를 알아야 정상인지 버그인지 구분할 수 있다.
해결: 교차 검증
해결은 교차 검증이다.
분석 에이전트의 보고를 그대로 믿지 않는다.
각 보고를 직접 추적한다.
“이 경로가 정말 실행되는가”, “이 조건이 정말 항상 참인가”를 코드에서 확인한다.
이날 핵심 교훈은 “서브에이전트 보고값은 미검증 신호다”였다.
서브에이전트가 “버그 찾았다”고 해서 바로 고치면 안 된다.
독립적으로 확인한 다음에 고친다.
컨텍스트 모드 권한 판단이 뒤집어졌다
두 번째는 컨텍스트 모드 권한 설계였다.
서브에이전트가 컨텍스트 모드에 접근할 수 있어야 하는가. 처음에 “읽기는 넓게, 쓰기는 좁게”라고 판단했다.
읽기 전용 에이전트가 쓰면 역할 위반이라고. 리뷰어가 쓰면 리뷰 독립성이 깨진다고.
근데 사용자가 한마디로 뒤집었다.
“서브에이전트가 자발적으로 DB에 저장하면, 다른 에이전트가 나중에 가져갈 수 있는 거 아닌가. 소스 코드 수정이 아니잖아.”
조직 기억 패턴
이 말이 맞았다.
컨텍스트 모드 DB는 프로젝트 단위다.
같은 프로젝트의 모든 에이전트가 하나의 DB를 공유한다.
리뷰어가 남긴 메모가 다른 에이전트한테 도움이 될 수 있다.
이건 “조직 기억”이다.
각 에이전트가 자기가 배운 걸 공유 메모리에 남긴다.
다른 에이전트가 나중에 가져간다.
이건 역할 위반이 아니라 협력이다.
“역할 위반”이라는 내 판단이 틀렸다.
쓰기 권한이 역할 독립성을 깨는 게 아니었다.
리뷰어가 메모를 남기는 게 리뷰 결과에 영향을 주지 않는다.
그냥 다른 에이전트한테 도움을 주는 거다.
최종 결정
그래서 모든 서브에이전트한테 컨텍스트 모드를 열었다.
단 하나 제외했다.
파괴적 삭제 도구는 뺐다.
삭제는 위험하니까.
번역 전처리 에이전트 설계
마지막으로 번역 전처리 에이전트를 설계했다.
한국어 요청을 영어로 번역해서 에이전트한테 주는 거다.
처음에는 “요청을 교체하는” 방식을 제안했다.
근데 이건 위험하다.
번역은 손실 압축이다.
한국어의 미묘한 뉘앙스가 영어로 번역되면서 사라진다.
그러면 에이전트가 원래 의도를 정확히 이해 못 한다.
사용자가 “교체가 아니라 보조면 어떨까”라고 물었다.
한국어 원본은 두고 영어 구조화된 요약을 추가하는 거다.
이러면 손실이 없다.
원본이 그대로 있으니까. 이게 맞았다.
번역을 출력 형식으로 쓰는 건 순 이익이다.
프롬프트 최적화, 통일된 위임 언어, 컨텍스트 압축. 근데 번역을 입력 교체로 쓰면 위험하다.
마무리
이날의 핵심은 “사용자가 정정하는 날”이었다.
검증 루프 감사에서 6개 중 5개가 과잉 진단이었다.
분석 에이전트가 정상 동작을 버그로 읽었다.
사용자가 하나씩 추궁해서 진짜 버그 1개를 분리했다.
컨텍스트 모드 권한에서도 내 판단이 뒤집혔다.
“역할 위반”이라고 판단했는데, “조직 기억”이라는 사용자의 통찰이 맞았다.
에이전트는 과잉 진단하고 과잉 제안한다.
코드를 읽고 “이상하다”고 하지만 의도를 모르면 정상을 이상하게 읽는다.
설계를 제안하지만 실제 사용 맥락을 모르면 틀린 제안을 한다.
이걸 막으려면 교차 검증이 필요하다.
서브에이전트의 보고를 독립적으로 확인한다.
그리고 사용자의 직관을 신뢰한다.
사용자가 “그건 정상이다”라고 하면, 코드에서 왜 정상인지 확인한다.
사용자가 “이렇게 하면 어떨까”라고 하면, 그 방향이 맞는지 검증한다.
에이전트의 분석보다 사용자의 맥락 이해가 더 정확하다.