AI 도구를 쓰면서 코드를 쓰는 속도는 확실히 빨라졌다. 그런데 티켓 하나가 끝나는 데 걸리는 시간은 기대만큼 줄지 않았다. 이유를 곰곰이 생각해 보니, AI와 함께 처리하는 구간은 대부분 빨라졌지만 사람과 맥락을 맞추는 구간은 그만큼 줄지 않았다.

AI가 줄여 준 시간과 줄이지 못한 시간

AI를 쓰고 빨라진 것은 구현뿐만이 아니었다. 요구사항을 이해하기 위해 관련 논의와 코드를 찾는 일, 설계 아이디어에 빠뜨린 부분이 없는지 살펴보는 일도 전보다 수월해졌다. 구현 뒤에는 별도의 AI 리뷰를 돌려 다른 관점의 의견을 빠르게 받아볼 수 있었다.

그렇다고 판단과 리뷰가 모두 AI 안에서 끝난 것은 아니다. AI를 통한 검토는 내가 생각을 정리하는 데 도움을 주는 과정에 가까웠다. 동료가 수행하는 PR 리뷰는 달랐다. 동료는 변경된 코드뿐 아니라 어떤 요구사항을 어떻게 이해했고, 여러 설계안 중 왜 이 결론을 택했는지도 함께 파악해야 했다.

AI와 한 티켓을 처리하는 동안 설계안, 코드, 검토 의견, 문서가 빠르게 쌓였다. 나는 그 흐름을 이어서 보고 있었지만 이 맥락을 함께 만들지 않은 동료는 결과와 판단 과정을 한꺼번에 받아들여야 한다. 결과물이 만들어지는 시간은 줄었지만, 이 맥락 차이를 메우는 시간까지 줄지는 않았다.

맥락은 부족해도, 너무 많아도 병목이 된다

문서를 만드는 속도도 빨라졌다. AI를 이용하면 회의 내용, 작업 과정, 확인한 로그를 바탕으로 상세한 문서 초안을 빠르게 만들 수 있다. 그러나 모든 과정이 같은 비중으로 적혀 있으면 다음 사람은 무엇이 결정됐고 지금 무엇을 해야 하는지 찾기 위해 처음부터 읽어야 한다.

AI가 문서 작성 비용을 낮췄지만, 사람이 핵심을 찾는 비용까지 낮춰 주지는 않았다. 맥락이 없으면 다시 물어봐야 하고, 너무 많으면 핵심을 찾느라 지친다. 둘 다 협업을 느리게 만든다.

티켓 하나에서 늘어난 이 읽기 비용은 처리하는 티켓이 많아질수록 반복해서 쌓였다.

읽는 쪽은 사람만이 아니다

그래서 사람과 AI에게 같은 내용을 그대로 보여 주는 방식이 맞는지 의문이 들었다. 같은 작업의 맥락이라도 사람에게 보여 줄 내용과 AI에 넘길 내용은 다르게 구성해야 하지 않을까.

내가 나눠 본 기준은 다음과 같았다.

사람AI
먼저 보여 준 것결정 사항과 다음 행동재현에 필요한 조건과 예외
덜어낸 것결론이 묻히는 장황함관련 없는 설명과 낡은 전제

실제로 어떻게 나눴는가

사람에게는 무엇이 바뀌었는지, 무엇을 결정해야 하는지, 그 결정이 언제까지 필요한지만 짧게 전달했다.

AI가 참고할 세부 맥락은 이슈와 PR의 본문이나 댓글에 남겼다. 버그 재현 절차, 확인한 로그, 설계 의도, 검토했지만 채택하지 않은 대안과 그 이유 같은 내용이다. 동료는 필요할 때만 이 기록을 찾아봤고, AI는 작업과 연결된 이슈나 PR을 읽는 과정에서 자연스럽게 세부 맥락을 얻었다.

AI가 읽을 세부 맥락에는 후속 작업의 목적과 범위를 담은 프롬프트 예시도 함께 남겼다. 인계를 받은 작업자는 이 예시를 자신의 작업에 맞게 조정해 사용할 수 있었다.1

사람에게는 다음과 같은 형식으로 공유했다.

@담당자 인증 만료 응답을 구분하도록 API를 변경했습니다. (PR #42)

클라이언트에서는 AUTH_EXPIRED를 다른 인증 실패와 구분해 처리해 주세요. (Issue #18)

API 계약과 확인 시나리오, AI로 후속 작업을 이어 갈 때 사용할 지시문은 Issue #18 댓글에 정리했습니다.

정리

AI를 쓰면서 내가 느낀 변화는 개발 과정 전체가 같은 속도로 빨라지지는 않는다는 점이었다. 혼자 맥락을 쌓고 결과를 만드는 일은 빨라졌지만, 그 맥락을 동료와 맞추는 시간은 내가 체감하기에 그만큼 줄지 않았다. 산출물이 많아지면서 오히려 더 오래 걸린다고 느낄 때도 있었다.

지금의 나는 정확하게 넘긴다는 것을 빠짐없이 길게 적는 일로 보지 않는다. 오히려 사람에게는 판단에 필요한 내용만 짧게 전달하고, AI가 이어서 읽을 세부 맥락은 기록으로 남기는 편이 낫다고 생각한다. 그 편이 동료가 읽어야 할 분량을 줄이고 협업의 피로감도 덜 수 있다.

다음으로는 내가 확인한 사실을 어디까지 전달하고, 어디부터 상대의 판단에 맡길지 고민했다. 이 고민은 핸드오프에서 넘길 것과 넘기지 않을 것에서 이어진다.

Footnotes

  1. 서버 작업 뒤에 클라이언트 구현이 이어진다면, 클라이언트 구현의 목적과 작업자가 참고할 API 규격, 검증 항목을 프롬프트에 담는다. ↩