AI 에이전트에게 구현을 시키면 그동안 말을 걸 수 없었다. 정확히는 걸 수는 있는데, 하던 일이 끝나야 답이 온다. 코드를 짜는 5분, 10분 동안 "아 그거 말고" 한마디를 못 한다.
그게 답답해서 방식을 바꿨다. 무거운 일은 따로 떼어 보내고, 나는 계속 대화할 수 있게.
처음 노린 건 처리량이 아니었다. 넷을 동시에 돌리면 네 배 빨라진다는 이야기가 아니다. 일이 도는 동안 진행을 묻고, 다음을 정하고, 마음이 바뀌면 도중에 틀 수 있기를 원했다.
그런데 몇 달 쓰고 기록을 세어보니, 정작 이 방식이 값을 한 건 일을 대신 시킨 쪽이 아니었다.
맡긴 일의 구성이 예상과 달랐다
기억으로 쓰기 싫어서 기록을 뒤져 세어봤다. 기간을 셋으로 나눠 보니 120번쯤이다.
| 처음 | 중간 | 최근 | |
|---|---|---|---|
| 조사·탐색 | 45% | 60% | 64% |
| 리뷰·검증 | 36% | 14% | 36% |
| 구현·테스트 | 20% | 5% | 0% |
구현이 0이 됐다. 처음엔 이게 제일 큰 쓸모일 거라고 생각했는데 정반대로 갔다. 지금은 맡기는 지시문마다 "파일은 고치지 말고 보고만 해라"가 붙어 있다.
돌이켜보면 일 자체가 원래 그렇게 생겼다. 코드를 치는 시간보다, 어떻게 만들지 정하고 뭘 어디에 얹을지 궁리하고 지금 상황이 어떤지 파악하는 시간이 훨씬 길다. 구현은 그게 다 끝난 뒤에 하는 마지막 단계다.
여기에 하나가 더 겹친다. 구현은 설명하는 품이 많이 든다. 내가 뭘 원하는지 정확히 옮겨야 하고, 잘못 나오면 고치는 것보다 다시 하는 게 빠를 때가 많다. 반면 조사는 "이거 찾아줘" 한 줄이면 되고, 결과가 틀려도 버리면 그만이다. 그래서 부탁하기 쉬운 일부터 넘어간다.
나란히 보내면 실패를 늦게 안다
순차로 했으면 안 생겼을 문제가 있었다.
두 저장소에 비슷한 수정을 해야 해서 에이전트 둘을 같은 방식으로 띄웠다. 한쪽은 고치고 커밋까지 했는데, 다른 쪽은 작업 공간이 격리돼 있어서 저장소에 쓰지 못하고, 바뀐 내용을 패치 파일로만 남겼다. 같은 지시, 같은 구조, 다른 결과.
하나씩 돌렸으면 첫 번째에서 이 문제를 만나고 두 번째는 조건을 바꿔서 보냈을 것이다. 동시에 보냈기 때문에 둘 다 끝난 뒤에야 한쪽이 반쪽짜리였다는 걸 알았다.
그리고 더 큰 게 왔다.
여섯 개를 한꺼번에 띄운 날, 결과도 한꺼번에 돌아왔다. 나는 그걸 다 읽지 못했다. "너무 많아서 판단하기 어렵다, 믿고 넘어가겠다"고 말해버렸다.
실행은 병렬이 되는데 검토는 병렬이 안 된다. 여섯 갈래로 벌려놔도 그걸 다시 모아서 판단하는 사람은 나 하나다.
그래서 지금은 한 번에 두 개까지만 보낸다. 셋 이상 보낸 게 최근 열흘간 한 번도 없다. 대신 그 둘을 이렇게 쓴다 — 같은 대상을 서로 다른 각도로 보게 한다. 가설 A와 가설 B를 각각 반증해보라거나, 하나는 문장을, 하나는 사실관계를 보라거나.
숫자로는 후퇴다. 동시에 돌리는 비율이 90%대에서 30%대로 내려갔다. 그런데 못 읽고 넘어간 여섯 개보다 제대로 읽은 두 개가 낫다.
지우지 못하는 일은 안 나눈다
늦게 알아도 되는 일이 있고, 알고 나면 이미 늦은 일이 있다.
파일은 잘못 고쳐도 지우면 된다. 그런데 잘못 보낸 메시지는 못 지운다. 배포도, 원격 저장소에 올린 것도 마찬가지다.
그래서 선을 하나 그었다. 조사하고 초안 쓰는 데까지는 맡기고, 바깥으로 나가는 동작은 내가 직접 한다.
승인 절차가 필요해서가 아니다. 틀렸을 때 주워 담는 비용이 다르기 때문이다.
코드가 오면 반박부터 시킨다
어느 날부터 규칙을 하나 걸었다. 코드가 고쳐져 왔으면 끝내지 말고, 그 코드를 반박하라고 따로 보낸다.
코드를 맡기고 리뷰 없이 넘어간 날은 나중에 뭔가 하나씩 나왔다. 돌린 날은 덜 그랬다. 세어본 적은 없고, 그냥 그런 일이 쌓였다.
왜 그런지는 짐작이 간다. 코드를 쓰는 쪽은 목표를 달성하는 데만 매달린다. 그쪽 일은 시킨 대로 동작하게 만드는 거고, 실제로 잘한다. 그런데 그 변경이 옆에 무슨 일을 일으키는지는 관심 밖이다. 요청에 없었으니까.
부작용은 요청한 사람도, 만든 사람도 안 본다. 그러니 부작용만 보는 자리를 따로 만들어야 한다.
그래서 근거를 빼고 주장만 넘긴다. "이렇게 확인해서 이런 결론이 나왔다"고 쓰면 상대가 내 경로를 따라온다. 그냥 "A다, B다, C다"만 던지고 각각이 틀릴 수 있는 경우를 찾으라고 한다.
역할도 못 박는다. 첫 줄이 보통 이렇다.
너는 적대적 리뷰어다. 아래는 내가 보내려는 주장들이다. 확인하지 말고 반례를 찾아라. 그럴듯하게 들린다는 이유로 주장을 받아들이지 마라.
이렇게 안 쓰면 대체로 동의해준다. 동의를 받으려고 보내는 게 아닌데.
답은 그대로였고, 근거가 바뀌었다
이렇게 반박을 붙이기 시작한 뒤로 내 결론이 흔들린 게 다섯 번쯤 된다.
한번은 코드를 읽고 "이 방식은 연결이 안 끊긴다"고 적어 동료에게 보내려던 걸 붙잡혔다. 내가 본 함수는 맞았는데, 같은 파일에 같은 일을 하는 곳이 네 군데 더 있었다. 틀린 코드를 읽은 게 아니라, 맞는 코드를 좁게 읽었다.
그런데 그러고도, 최종 결론이 뒤집힌 적은 거의 없다. 위 건도 결국 원래 권하려던 방식을 그대로 권했다. 조건이 하나 붙었을 뿐이다.
바뀐 건 결론이 아니라 근거였다. 처음에는 "이 방식은 연결이 안 끊기니까 좋다"였는데, 나중에는 "둘 다 끊긴다. 다만 이쪽이 문제를 찾기 쉽다"가 됐다. 도착한 곳은 같은데 거기까지 온 길이 통째로 갈렸다.
일을 대신 시키려고 나눴다. 지금은 내 말이 틀렸는지 찾게 하는 데 더 많이 쓴다.
