AI Native 레포에서 조직으로: hollon-ai 구축기

레포를 AI Native하게 만들고 나니 다른 병목이 보였다는 데서 시작한다. 문제는 AI가 코드를 못 쓰는 게 아니라 사람이 여러 도구를 오가며 AI를 오케스트레이션해야 한다는 점이었다. 태스크는 팀챗에서 설명하고 코드는 터미널에서 만들고 리뷰는 GitHub에서 하고 운영 확인은 Datadog과 Grafana에서 했다. hollon-ai는 팀챗이라는 공용 인터페이스 위에 실행 harness와 메모리 계층을 올려 보안 대응·배포 직후 관측·코드 수정·지식 축적이 같은 스레드에서 이어지게 만든 시스템이다.

핵심 포인트

별도 웹 UI나 IDE 플러그인 대신 팀챗을 고른 이유는 병목이 코드 작성이 아니라 그 앞뒤의 조율이었기 때문이다.
Claude Code를 대체하지 않고 그 위에 조직용 실행 harness를 얹었다. 이미 잘 만들어진 coding harness를 다시 구현할 이유가 없었다.
대화가 곧바로 임의 실행으로 이어지지 않는다. 계획 승인이나 머지 판단 같은 협업 규칙이 암묵적 합의가 아니라 시스템의 상태 전이 규칙이 된다.
팀챗은 UI로는 단순하지만 시스템으로 만들면 오히려 더 많은 인프라 작업이 필요했다.
사용량 증가는 모델 품질이 좋아져서가 아니라 실행 가능한 인터페이스를 하나씩 메워가며 늘었다.

상세 정리

이전 단계의 한계 셋: AI 코딩 도구를 잘 쓰는 사람만 그 능력을 활용할 수 있어 IDE 바깥 협업 흐름에서는 접근 장벽이 높았고, 실제 업무의 요구사항 정리·승인·피드백은 팀챗에서 일어나는데 AI만 그 바깥에 있었으며, 좋은 레포를 읽을 수는 있어도 이전 결정이나 반복한 실수를 장기적으로 축적하지는 못했다.
팀챗을 고른 근거: 태스크 생성과 우선순위 결정, 피드백과 승인, 상태 공유가 이미 거기서 일어나고 있었고, 시간이 쌓일수록 팀챗은 조직의 요구사항과 승인·반려·예외 처리·의사결정 히스토리가 남는 저장소가 된다.
같은 스레드에서 계획 검토와 수정 요청이 가능하고 PR 생성·CI 상태·리뷰 반영·머지 결과가 같은 맥락에 남는다는 것이 이점이다.
필요했던 harness: 같은 메시지를 여러 pod가 동시에 처리하지 않게 하는 dedup, 구현부터 PR 생성·리뷰 반영·머지까지 이어지는 상태머신, 그리고 Datadog·Grafana·GitHub·Linear·브라우저 같은 외부 도구 연결이다.
3계층 구조: API 서버가 외부 webhook을 받고 스레드 문맥을 복원하며 태스크 상태머신과 지식 API를 맡고, orchestrator가 같은 DB를 보며 실행할 태스크를 스캔해 worker를 생성·회수하며, worker가 실제 코드 탐색·수정·PR 생성·로그 분석을 수행한다.
서버는 판단과 상태를 맡고 실제 작업은 worker에서 하며, 서버를 stateless로 두고 실행 상태를 DB에 남겨 수평 확장이 쉬워진다. 승인하면 orchestrator가 worker용 K8s Job을 띄운다.
Claude Code를 안에서 쓰는 이유: 계획·수정·테스트·Git 작업으로 이어지는 흐름이 이미 성숙해 있고 긴 작업 중에도 상태를 유지하고 복구하는 기본 동작이 갖춰져 있기 때문이다.
역할 규정: Claude Code가 잘 일하는 개인용 coding harness라면 hollon-ai는 그 위에 얹은 조직용 실행 harness다.
스레드 문맥 복원: 한 줄 메시지만 보면 같은 대화 안에서도 매번 새 태스크로 오해하므로, root message와 reply history를 다시 읽어 현재 질문을 재구성한다. 덕분에 요구사항·제약·피드백·중간 상태·최종 결과가 같은 맥락에 남아 나중에 결정 이유를 되짚기 쉽다.
대화형 요청과 구현형 요청을 같은 입구에서 받도록 설계했다. 질문과 구현을 다른 인터페이스로 나누면 사람이 컨텍스트를 다시 옮겨 적어야 하기 때문이다.
전문 에이전트 위임: 브라우저 자동화나 관측성 분석은 일반 conversation agent만으로 어려워, 같은 스레드 문맥에서 specialized agent를 호출한다. 사용자에게는 하나의 봇으로 보이지만 내부적으로는 역할별로 분업한다.
권한 고려: 같은 질문이라도 질문자의 역할과 권한, 접근 가능한 저장소가 무엇인지에 따라 답변의 깊이와 실행 범위가 달라져야 한다.
도구 호출 구조 변경: 초기에는 팀챗 MCP 도구가 외부 API를 직접 호출했지만 운영에서 한계가 드러나, 서버가 자격 증명을 관리하고 pod는 도구 호출만 하도록 바꿨다. 이미지와 파일도 서버에서 안전하게 다루고 조직별 설정도 한곳에서 관리한다.
가장 시간이 많이 든 부분은 기능 자체보다 같은 webhook이 여러 pod에 들어와도 한 번만 처리되게 하고 리뷰 코멘트가 달리면 상태가 올바르게 돌아가게 하는 일이었다. 이 시스템의 품질은 잘 될 때보다 꼬였을 때 얼마나 자연스럽게 복구되느냐에 달려 있다고 정리한다.
사례 1 보안 대응: 2026년 4월 외부 보안 사고가 공유되자 한 엔지니어의 요청으로 조직 내 Next.js/Vercel 배포 프로젝트를 훑어 무엇이 영향받는지, 어떤 조치가 프로젝트 담당자 몫이고 어떤 것이 관리자 몫인지 정리했다. 후속 질문에는 팀별로 좁혀 다시 정리했다.
사람이 멘션을 칠 때만 일어나는 것도 아니다. 운영 알람 채널에 자동화가 붙어 특정 경고가 들어오면 같은 스레드에서 1차 트리아주를 시작한다.
메모리 경고가 들어온 날에는 몇 초 뒤 가능한 완화 조치가 무엇이고 각각 어떤 trade-off가 있는지, 기존 운영 문서만으로는 답하기 어려운 공백이 어디인지를 정리했다.
사례 2 배포 관측: 2026년 4월 9일 백엔드 배포 직후 이상징후 확인 요청에, 배포 시각 전후의 Datadog과 Grafana 지표를 보고 롤링 배포 직후 짧은 latency spike가 있었지만 정상 범위로 회복했다는 점과 후속 검토 대상만 남겼다. 이어진 질문에서는 수십 건의 로그를 배포 관련 정상 종료인지 외부 의존성 오류인지 단발성인지로 분류했다.
사례 3 지식 인터페이스: 엔지니어링 채널 밖에서 커머스 환불 스펙 질문이 들어오자 관련 코드와 앱 함수 구현을 읽고 어떤 경우는 취소 신청까지만 되고 관리자 수동 처리가 필요한지 정리했으며, 후속 질문에는 매트릭스로 완전 자동화 가능 케이스와 수동 처리 케이스를 나눠 설명했다.
사례 4 자기 수정: AWS 도구 중 특정 부분을 제거하고 문서도 정리해 달라는 요청을 한 스레드에서 끝까지 처리해 실제 코드와 문서 변경까지 반영했다.
사례 5 관측과 구현의 연결: 보안 방어 로직 배포 후 오류 증가 확인 요청에 대부분이 정상 차단임을 설명하고, 추가 분석으로 정상 외부 URL의 링크 프리뷰까지 실패하는 사이드이펙트를 찾아 원인을 좁힌 뒤 수정 방향 제안과 PR 생성까지 이어갔다.
사용량 측정: hollon이 남긴 시작 메시지 기준으로 직접 멘션과 자동 트리거를 같은 기준으로 셌다. 완벽한 제품 분석 지표는 아니지만 주 단위로 보면 어떤 기능이 붙은 뒤 사용량이 튀었는지 또렷이 보인다고 밝힌다.
변곡점들: 3월 17일 모든 메시지를 conversation agent로 모으고 thread history를 함께 읽게 하면서 대화 품질이 올랐고, 이후 specialized agent dispatch와 기존 PR 수정 workflow로 범위가 운영 대응과 멀티에이전트 실행까지 넓어졌다.
4월 초에는 trigger rules editor와 키워드 기반 자동 트리거, 내부 프록시 경유 도구 호출, browser CDP가 들어와 자동 실행 경로가 안정됐고, 4월 중순에는 reply dedup과 PR thread notification, trigger role routing 안정화로 반복 사용에 버틸 품질을 확보했다.
엔지니어링 전용 채널 밖 공개 그룹의 사용량을 보수적으로 센 값만 봐도 조직 인터페이스가 되기 시작했음을 보여준다고 해석한다.