AI 네이티브 조직이 '모노레포'에 목숨 거는 진짜 이유

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

솔직히 고백하자면, 저는 한때 거대한 모노레포(Monorepo)에 회의적이었습니다. "서비스가 커지면 당연히 저장소를 분리해야지(MSA), 하나에 다 때려 넣으면 빌드 시간만 길어지고 관리하기 힘들지 않나?"라는 고정관념이 있었죠. 하지만 최근 AI 도구들을 개발 프로세스에 깊숙이 도입하면서, 그 생각이 완전히 바뀌는 경험을 했습니다. 아니, 오히려 뼈저리게 반성했습니다.

우리가 겪었던 가장 고질적인 문제는 '동기화의 지옥'이었습니다. 예를 들어 서비스의 가격 정책을 바꾼다고 가정해 볼까요? 백엔드 개발자가 API의 로직을 수정하고, 프론트엔드 개발자가 UI에 표시되는 가격표를 바꾸고, 마케팅 팀은 랜딩 페이지의 숫자를 수정하고, 테크니컬 라이터는 공식 문서를 업데이트해야 합니다.

이 과정에서 누군가 하나라도 실수를 하면 어떻게 될까요? 고객은 웹사이트에서 "월 10달러"를 보고 결제하려는데, 결제창에는 "15달러"가 찍히는 대참사가 벌어집니다. 각 팀이 쓰는 도구가 다르고, 저장소가 다르고, 배포 타이밍이 다르기 때문에 발생하는 필연적인 사고죠.

우리는 이 문제를 해결하기 위해 'Everything as Code(코드로서의 모든 것)'라는 개념을 도입하기로 했습니다. 핵심은 간단하지만 강력합니다. 제품 코드뿐만 아니라 마케팅 웹사이트, 내부 문서, 심지어 투자자를 위한 피치덱(Deck)까지 하나의 리포지토리에 담는 것입니다.

이 변화가 가져온 파급력은 놀라웠습니다. 가장 큰 변화는 바로 '진실의 원천(Source of Truth)'이 하나가 되었다는 점입니다.

가령 billing-plans.json이라는 단 하나의 파일을 수정한다고 칩시다. 이 파일 하나를 고치고 커밋하면, 백엔드의 제한 로직, 프론트엔드의 가격 표시, 마케팅 사이트의 요금제 테이블, 그리고 사용자 가이드 문서까지 동시에 업데이트됩니다. 별도의 CMS에 로그인할 필요도, 마케팅 팀의 컨펌을 기다릴 필요도 없습니다. 그저 git push 한 번이면 됩니다.

하지만 이 구조가 진짜 빛을 발하는 순간은 바로 AI와 협업할 때입니다.

요즘 우리는 Claude나 Cursor 같은 AI 도구를 끼고 삽니다. 그런데 저장소가 파편화되어 있으면 AI는 바보가 됩니다. 프론트엔드 코드를 짜달라고 하면 백엔드 API의 변경 사항을 모르고, 문서를 써달라고 하면 최신 기능을 누락합니다. '컨텍스트(Context)'가 끊겨 있기 때문이죠.

반면, 모든 것이 하나의 모노레포에 있으면 AI는 '신'과 같은 시야를 갖게 됩니다. 제가 Claude에게 "이번에 추가된 Asana 연동 기능에 맞춰 가격 페이지랑 문서를 수정해 줘"라고 요청하면, AI는 실제 구현된 백엔드 코드를 읽고, 그것이 프론트엔드에 어떻게 반영되었는지 확인한 뒤, 그 사실에 입각해 정확한 마케팅 문구와 문서를 작성합니다. AI가 스스로 '팩트 체크'를 할 수 있는 환경이 조성되는 셈입니다.

이것이 제가 생각하는 진정한 의미의 AI-Native Development입니다. 단순히 코딩을 빨리하는 게 아니라, AI가 전체 맥락을 이해하고 원자적(Atomic)인 단위로 업무를 수행할 수 있게 판을 깔아주는 것이죠.

개발자 여러분, 혹시 아직도 배포할 때마다 "프론트랑 백엔드 버전 맞췄나요?"라고 슬랙에 묻고 계시나요? 혹은 마케팅 팀이 1년 전 스크린샷을 홈페이지에 올려놔서 곤란했던 적은 없으신가요?

그렇다면 이제는 저장소를 쪼개는 것보다, 어떻게 하면 우리 조직의 모든 자산을 '코드'라는 하나의 언어로 통합할 수 있을지 고민해 보셨으면 합니다. 기술적인 부채를 줄이는 것을 넘어, AI라는 강력한 동료에게 최고의 작업 환경을 제공하는 길이니까요.

우리의 일하는 방식은 도구에 따라 바뀝니다. 그리고 지금, 그 도구는 우리에게 '통합'을 요구하고 있습니다.