당근 기술 블로그의 「프론트엔드와 백엔드를 한 팀으로 합치면 어떤 일이 일어날까?」를 읽었다. 광고실 광고주플랫폼팀이 프론트엔드 4명과 백엔드 4명을 한 팀으로 합치고 한 분기를 보낸 기록이다.

결과적으로 완료량은 떨어지지 않았고, 한 사람이 [FE] 티켓과 [BE] 티켓을 함께 맡아 화면부터 서버까지 끝내는 방식으로 바뀌었다고 한다.

그런데 이 문장이 계속 걸렸다.

팀의 지식이 AI의 연료였습니다.

직군 통합은 저 팀의 조건에서 나온 선택이고, 글도 그 점을 분명히 한다. 내가 주목한 건 통합이라는 선택보다 그 이전에 팀이 갖춰 둔 것들이었다.

통합 전에 이미 갖춰져 있던 것들

글에 흩어져 있는 것을 모아 보면 네 가지다.

  • 이 팀은 무엇을 어떤 순서로 하는지, 일하는 방식을 미리 정해 적어 둔 문서
  • 작업마다 기획서와 설계 문서를 쓰고 시작하는 습관
  • 각 서비스 저장소에 쌓인 시스템 구조도와 DB 스키마 문서
  • 장애가 나면 증상별로 무엇부터 확인할지 적어 둔 대응 매뉴얼과 모니터링 대시보드

넷 다 문서다. 통합에 맞춰 새로 만든 것은 없다. 전부 그 전 분기에 다른 목적으로 쌓아 둔 것들이다.

그 원래 목적은 사람이었다. 새로 합류한 사람이 읽을 온보딩 자료였고, 장애 당번이 열어 볼 매뉴얼이었다. 둘 다 언제 일어날지 모르는 일이라, 쓰는 시점에는 들인 비용이 언제 리턴될지 알 수 없었다.

그런데 AI에게 낯선 직군의 코드를 맡기게 되자 해당 문서가 매 작업에서 읽히는 자료가 됐다. 문서에 들인 비용이 리턴되는 시점이 바로 다음 티켓으로 당겨진 것이다.

들인 비용이 언제 리턴되는가

문서를 쓰라는 말 자체는 오래됐다. 바뀐 건 그 비용이 언제 리턴되느냐다.

예전지금
읽는 주체사람사람 + AI
읽는 시점인수인계, 온보딩, 사고 후작업할 때마다
리턴 시점사람이 바뀔 때 (불확실)다음 작업 (거의 확정)
안 쓰면나중에 누군가 고생한다지금 AI 결과물이 나빠진다

예전에는 문서를 써 놓고도 언제 쓸모가 생길지 알 수 없었다. 후임이 안 올 수도 있고, 와도 읽을지 모른다. 그래서 늘 뒤로 밀렸다.

지금은 손해가 다음 티켓에서 온다. 맥락 없이 AI에게 일을 시키면 그럴듯하게 틀린 결과가 나오고, 그걸 걸러내는 데 문서 쓰는 시간보다 오래 걸린다.

내 작업 파이프라인의 첫 단계가 문서인 이유

내가 실무에서 쓰는 12단계 파이프라인도 코드를 만지기 전에 요구사항을 정리하고 작업 문서를 만든다. 당근 글의 “작업마다 기획서와 설계 문서를 쓰고 시작하는 습관”과 같은 자리다.

처음 이 단계를 앞에 둔 이유는 단순했다. AI가 확인되지 않은 정보를 임의로 판단해서 진행하는 게 싫었다. 그런데 굴려 보니 이 문서가 거기서 끝나지 않았다.

설계 문서 ──▶ PR 본문 ──▶ 릴리즈 노트 ──▶ Wiki

설계 문서에 영향도와 테스트 체크리스트를 붙이면 PR 본문이 되고, PR을 묶으면 릴리즈 노트가 되고, 릴리즈에서 반복해 설명하게 되는 내용이 Wiki로 올라간다.

문제는 뒤로 갈수록 원본을 고칠 수 없다는 것이다. 릴리즈 노트를 쓰는 시점에 설계 판단의 근거를 다시 만들어 낼 방법은 없다. 그때 남은 건 코드뿐인데, 코드는 자기가 왜 그렇게 되어 있는지 말해 주지 않는다.

그래서 설계 문서를 쓰는 태도가 바뀌었다. 지금 쓰고 마는 메모가 아니라 세 번 더 재사용될 원본이라고 생각하고 쓴다. 이 연쇄에서 PR이 어떤 역할을 맡는지는 PR을 의사결정 문서로 쓰는 이야기에 따로 적었다.

흩어진 지식을 모으는 일

당근 팀은 2분기에 기술 문서 저장소를 새로 만들어 흩어져 있던 도메인 지식을 한곳에 모았다. 한 분기 동안 문서와 수정 기록이 수백 개 쌓였다고 한다.

지식이 메신저 DM, 이슈 댓글, 누군가의 머릿속, 코드 주석에 흩어져 있으면 AI는 그중 하나만 보고 답한다. 사람은 “그거 예전에 누가 말했었는데” 하고 물어보러 갈 수 있지만 AI는 못 간다. AI가 일할 환경을 만든다는 게 결국 정보를 한 곳에 모으는 일이 되는 이유다.

집대성이라는 말이 어울린다. 세종대왕의 편찬 사업이 그랬듯 흩어진 것을 한 권으로 묶는 작업 자체는 지루하다. 그런데 그게 있어야 다음이 가능하다.

AX라고 하면 도구 도입이나 조직 개편을 떠올리기 쉽다. 실제로 효과를 가르는 건 그 앞에 있는, 아무도 하기 싫어하는 정리 쪽이라고 본다. 도구는 하루면 깔지만 지식 저장소는 하루에 못 만든다.

이제는 쌓는 동시에 쓸 수 있다

프로젝트를 진행하며 새로 남긴 문서가 곧바로 다음 작업과 포스트모템(사후 회고)에서 AI의 입력으로 쓰였거든요. (…) 지식 구축과 활용은 순서대로가 아니라, 동시에 시작해도 복리가 붙더라고요.

예전 위키가 실패한 이유가 여기 있다고 본다. 모으는 비용은 지금 내는데 효용은 언젠가 누가 읽을 때 나온다. 그 시차 때문에 아무도 안 채웠고, 안 채우니 아무도 안 읽었다.

지금은 오전에 정리한 문서가 오후 작업의 컨텍스트가 된다. 게다가 그 문서를 읽는 사람이 나 하나가 아니다. 팀에 있는 모든 사람의 에이전트가 같은 문서를 읽는다. 한 명이 정리하면 팀 전체가 즉시 쓴다.

같은 팀 회고에서 나온 문장이 이걸 짧게 정리한다.

글 쓰는 것이 비단 사람에게뿐만 아니라 에이전트에게도 도움이 되는 것 같아요.

낡은 문서 비용은 어디서 갚나

여기까지가 문서를 쌓아서 얻는 쪽이다. 그럼 대가는 없을까.

문서가 쌓일수록 낡은 내용도 함께 남는 것 아니냐는 의문이 들 수 있어요.

틀린 문서는 틀린 결과를 만든다. 따라서 당근 팀은 기획서와 테크스펙을 리뷰하는 단계마다 문서를 계속 보정한다고 한다.

나도 같은 방식으로 진행하고 있고, 이 때 보정에 드는 비용은 AI가 구현에서 줄여 준 시간으로 충분히 감당된다고 생각한다. (사실 이 보정도 문서 최신화 에이전트와 CI에 걸어 두고 자동으로 돌린다.)

애초에 떠안을 빚이라면 이쪽이 낫다. 코드 레거시는 걷어내기 전에 무엇이 깨질지부터 확인해야 하지만, 문서 레거시는 틀린 문장을 고쳐 쓰는 것으로 끝난다.

속도를 택하면 리스크는 운영으로 옮겨간다

당근 팀은 AI가 만든 결과물을 100%까지 다듬는 대신 80~90%에서 받아들이고 속도를 가져가기로 했다. 그렇게 남는 리스크는 문제가 생기면 빠르게 감지하고 빠르게 대응하는 쪽으로 감당한다.

앞부분만 보면 품질을 낮춘 이야기 같지만, 실제로 달라지는 건 결함을 어디서 잡느냐다. 예전에 코드 리뷰와 테스트에서 걸러내던 것 중 일부가 운영 단계로 넘어간다. 그럼 그만큼 장애 대응 매뉴얼과 모니터링 대시보드가 할 일이 커진다.

만약 낯선 서비스에 장애가 났을 때 그 시스템을 아는 사람부터 찾아야 하면, 대응 속도는 그 사람이 자리에 있느냐에 달린다. (개발자들이 노트북을 갖고 다니는 이유..?) 매뉴얼이 있으면 그 의존이 끊긴다. 당근 글에도 당번이 FAQ의 증상별 절차를 따라가며 특정 담당자를 기다리지 않았다는 후기가 실려 있다.

그래서 AI로 빨라졌다는 팀을 보면 속도보다 그다음이 궁금해진다. 빨라지면서 늘어난 실수를 무엇으로 잡고 있는지. (여기에 답이 없으면 속도만 챙기고 나머지는 운에 맡긴 거라고 봐야하지 않을까?)

전문성이 검증자로 옮겨간다는 말

돌이켜보면 옆자리에 묻든 리뷰로 거르든, 무엇이 확신이 안 서는 지점인지 아는 것부터가 전문성이었어요. 저희 팀에서 전문성은 AI가 넘어서는 장벽이 아니라, AI의 결과물을 걸러내는 최종 검증자로 자리를 옮겨가고 있어요.

검증이 생산보다 쉬운 일은 아니다. AI가 짜 준 코드를 보고 이상하다고 짚으려면 정상이 어떤 모습인지 알아야 한다.

내가 만든 최적화를 적대적으로 리뷰해 봤을 때 그걸 느꼈다. 리뷰어 셋을 붙여 반박을 시켰더니 지적이 잔뜩 나왔는데, 그중 무엇이 실제 위험이고 무엇이 교과서적인 이야기인지는 결국 내가 갈라야 했다. 근거가 없으면 리뷰어를 아무리 붙여도 무엇을 받아들일지 못 정한다.

그래서 내가 책임지는 영역만큼은 검증할 수 있을 정도로 알고 있어야 한다고 본다.

정리

핸드오프 이야기에 쓴 것과 같은 결론에 닿았다. AI를 쓰면서 병목이 구현에서 맥락 공유로 옮겨갔고, 그 맥락을 읽는 쪽이 사람만이 아니게 됐다. 규모도 조직도 다른 곳에서 같은 지점에 도착했다는 게, 이게 내 작업 환경만의 사정은 아니라는 신호로 읽혔다.

팀이 쌓아둔 문서는 생산성인 동시에 배려이기도 하다. 내가 정리해 둔 것이 다른 사람의 시간을 줄인다. 이건 이제, 사람뿐 아니라 각자의 에이전트에게도 적용된다.