Source of Truth

어느 정도의 라운드를 지난 스타트업은 사연이 많다. 사업은 좋을 수도 나쁠 수도 있지만, 히스토리도 길고 레거시도 많고, 제품과 서비스가 많은 사람의 손을 거쳐갔다는 사실은 대개 비슷하다.

그러므로 사내 위키를 운영하는 건 정말 중요했다. 온갖 문서, 정책, 기획, ... 중요하지 않은 게 없다. 당연히 버전의 관리도 필수다. 티도 안나고, 중요하지도 않아보이지만, 제대로 이루어지지 않는다면 많은 구성원들 모두에게 엄청난 병목으로 돌아온다. 신규 개발이 아니라면, 이 많은 문서들을 찾아보고, 히스토리를 거슬러 오르고, 그제서야 개발할 준비가 된다. 찾는 것 자체도 쉬운 건 아니지만, 요즘은 AI가 이런 ‘잔 일‘을 많이 해결해주곤 한다.

다만 Jira, Notion, Linear, Confluence, ... 이렇게 많은 도구를 뚜렷한 목적 구분 없이 여럿 사용한다면 어떨까? AI가 없었다면 정말 기록을 남기는 것에 비해 기록을 찾는 것은 너무나도 어려울 거고, 기록을 남기는 것 자체도 번잡할 것이다. AI가 있더라도 MCP, CLI, Plugin 지원 여부의 차이도 있고, 토큰 효율성, 컨텍스트의 한계 등으로 대부분이 해소된다고 보긴 어렵다.

나도 근래 비슷한 불편함을 겪었다. 어떻게 하는 게 좋을까? 먼저 목적이 불분명하다면 그런 채널들을 줄여야한다고 봤다. 적어도 그 편이 검색할 소스의 범위를 줄일 수 있지 않을까? 다행히도 코드는 Git 등으로 버전을 관리하는 것을 많은 이들이 당연시해왔기에 특정 버전을 보존하는 것에 대해서는 문제가 없었으나, 그것이 우리의 정책, 기획 등과 같은 시점으로 존재하는지에 대해서는 의문이 생길 수 있고, 그걸 대조하는 것은 AI를 사용하더라도 쉽지 않을 것이다. 그 긴장을 장시간 버틴다면, 그것은 버텨온 게 아니라 이미 어느정도 평행하고 있음을 맨파워로 극복하고 있거나, 생산성에서 손해를 보고 있을 확률이 높다.

그래서 요즘 떠오르는 생각은, 코드 베이스를 단일 진실 원천으로 삼아, 가장 최신의 기획과 정책 문서를 계속해서 반영해두는 것이다. 물론 프로젝트의 구조는 모두 다른 복잡함을 지니기에 쉽지 않겠지만, AI의 레버리지를 극대화하기에는 딱 좋은 구조라고 생각했다. 스펙, 코드, 테스트가 한 공간에 존재한다면 SDLC를 건강하게 준수할 수 있을 것이다.

게다가 AI Native한 시대가 아닌가. 모두가 도구는 다르지만 다들 각자의 AI를 들고 잘하는 분야를 기반으로 인접 분야까지 다루고 있고, 그런 역량이 요구되고 있다. 그렇다면 소프트웨어 생명주기에서 비롯하는 배포/운영 전략이나 인프라적 요소, 그 이상의 디테일들은 엔지니어가 계속해서 관리하게 되겠지만, 적어도 기존의 워터폴식 방법론에서 기인하는 특정 파트의 병목을 덜어내고, 단계적으로 현재의 수준보다 빠르게 스프린트할 수 있는 수준으로 나아갈 수 있지 않을까.

AI에게 효과적으로 질의하고, 필요한 컨텍스트를 부여하는 것도 중요하지만, 불필요한 질의와 불필요한 결정 사안을 줄이고, 스스로 컨텍스트를 확보할 수 있는 환경을 마련해주는 것도 중요하다고 본다. 그래야 휴먼인더루프를 줄이고, 인간은 인간만이 할 수 있는 부분에 더 집중할 수 있을테니까.

아직까지 모두가 AI를 다루는 수준의 차이가 상이하고, 비개발자는 Git이나 코드 중심의 버전 관리가 익숙하지 않겠지만, 그런 비개발자도 자연스럽게 코드 베이스를 SSOT가 될 수 있도록 만드는 플랫폼이나 프로세스가 있다면 적어도 현재는 좋지 않을까. Issues, Pull Request, Projects, Actions, Gist 등이 갖추어져 있는 GitHub가 몇 년을 사용해왔음에도 불구하고 이제서야 정말 잘 만든 제품이라는 생각이 든다.