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

안녕하세요, 채널톡 소프트웨어 엔지니어 페리입니다.

이전 글에서 저는 AI Native 개발의 비결은 모델이 아니라 시스템이라고 썼습니다. 레포를 AI가 읽기 좋게 만들고, 테스트와 린터, 아키텍처 규칙 같은 제어장치를 붙이면 AI는 훨씬 안정적으로 일할 수 있습니다.

https://channel.io/ko/team/blog/articles/ai-native-system-69c5a365

그런데 레포를 AI Native하게 만들고 나니 다른 병목이 보였습니다. 문제는 AI가 코드를 못 쓰는 게 아니라, 사람이 여러 도구를 오가며 AI를 오케스트레이션해야 한다는 점이었습니다. 태스크는 팀챗에서 설명하고, 코드는 터미널에서 만들고, 리뷰는 GitHub에서 하고, 운영 확인은 Datadog과 Grafana에서 합니다. 계획 승인과 피드백, 머지 판단도 사람이 계속 이어붙여야 했습니다.

hollon-ai는 이 병목을 줄이기 위한 다음 단계였습니다. 팀챗이라는 공용 인터페이스 위에 실행 harness와 메모리 계층을 올려, 보안 대응, 배포 직후 관측, 코드 수정, 지식 축적이 같은 스레드에서 이어지게 만들었습니다.

이 글은 "@hollon 이거 고쳐줘라고 말하면 코드가 고쳐진다"는 데모 소개가 아닙니다. AI Native 레포 위에 전사적 실행 harness를 어떻게 얹었는가에 대한 이야기입니다.

1. AI Native에서 무엇이 남아 있었나

이전 글에서 다룬 핵심은 두 가지였습니다.

• AI가 규칙을 어기지 못하게 만드는 결정론적 제어

• AI가 코드베이스를 이해하게 만드는 지식 시스템

이 두 가지 덕분에 AI는 훨씬 더 안정적으로 PR을 만들기 시작했습니다.

하지만 여전히 한계가 있었습니다.

첫째, AI는 개인의 IDE 안에 갇혀 있었습니다. AI 코딩 도구를 잘 쓰는 사람만 이 능력을 활용할 수 있었고, IDE 바깥의 협업 흐름에서는 여전히 접근 장벽이 높았습니다.

둘째, 실행 흐름이 협업 흐름과 분리되어 있었습니다. 실제 업무에서는 팀챗에서 요구사항을 정리하고, 승인하고, 피드백하고, 상태를 확인합니다. 그런데 AI는 그 흐름 바깥에서 따로 움직였습니다.

셋째, 세션이 끝나면 기억이 사라졌습니다. 좋은 레포를 읽을 수는 있어도, 이전에 어떤 결정을 했는지, 어떤 실수를 반복했는지, 누가 어떤 맥락을 남겼는지를 장기적으로 축적하지는 못했습니다.

그래서 다음 단계의 문제는 이렇게 바뀌었습니다.

좋은 레포를 만드는 것을 넘어서, 조직 전체가 AI를 호출하고 검증하고 기억하게 만드는 인터페이스와 harness를 만들 수 있을까?

2. 다음 단계는 전사적 harness였다

저희는 별도의 웹 UI나 IDE 플러그인 대신 팀챗을 선택했습니다. 이유는 단순합니다. 병목이 "코드 작성"이 아니라 팀 단위의 협업 흐름에 있었기 때문입니다.

그리고 시간이 쌓일수록 팀챗은 단순한 대화창이 아니라, 조직의 요구사항과 승인, 반려, 예외 처리, 의사결정 히스토리가 남는 살아있는 기억 저장소가 됩니다.

• "이 이슈 이 방향으로 진행해줘"

• "계획 먼저 보여줘"

• "이 부분은 스키마 마이그레이션 없이 가자"

• "CI 초록불이면 머지해도 돼"

• "지금 남은 blocker만 다시 정리해줘"

태스크 생성과 우선순위 결정, 피드백과 승인, 상태 공유는 이미 팀챗에서 일어나고 있었습니다. 그런데 AI만 그 흐름 바깥에 있었습니다.

새로운 인터페이스로 사람을 옮기기보다, 조직이 이미 일하는 인터페이스 안으로 AI를 넣는 편이 자연스러웠습니다.

여기서 중요한 건 챗봇을 하나 붙였다는 사실이 아닙니다. 팀챗을 실행 인터페이스로 삼으려면, 그 위에 다음과 같은 harness가 필요했습니다.

• 같은 메시지를 여러 pod가 동시에 처리하지 않게 하는 dedup

• 스레드 root와 reply history를 복원하는 문맥 회수

• 계획 수립과 사용자 승인 루프

• 구현, PR 생성, 리뷰 반영, 머지까지 이어지는 상태머신

• Datadog, Grafana, GitHub, Linear, 브라우저 같은 외부 도구 연결

• 세션 밖에서도 남는 지식과 메모리

팀챗은 UI로는 단순하지만, 시스템으로 만들면 오히려 더 많은 인프라 작업이 필요했습니다.

3. hollon은 어떻게 동작하나

hollon의 흐름을 한 문장으로 요약하면 이렇습니다.

팀챗 메시지 → 스레드 문맥 복원 → 계획 수립 → 사용자 승인 → 작업 실행 → PR/리뷰/관측 → 같은 스레드에 결과 보고

겉으로는 간단해 보이지만, 실제로는 아래처럼 여러 계층이 함께 돌아갑니다.

팀챗 메시지
  → webhook 수신 및 검증
  → API 서버가 스레드 문맥 복원
  → Redis로 dedup/lock 처리
  → PostgreSQL에 태스크/상태 저장
  → orchestrator가 작업을 스캔
  → Kubernetes Job으로 worker pod 실행
  → worker가 코드 탐색 / 수정 / PR / 도구 호출 수행
  → 결과를 다시 API 서버에 보고
  → 같은 팀챗 스레드에 상태와 결과 반영

3.1 API 서버, orchestrator, worker pod로 나뉜다

hollon-ai의 런타임은 크게 세 부분으로 나뉩니다.

• API 서버: 외부 webhook을 받고, 스레드 문맥을 복원하고, 태스크 상태머신과 지식 API를 담당

• orchestrator: 같은 DB를 보면서 실행할 태스크를 스캔하고, 적절한 worker를 생성/회수

• worker pod: 실제 코드 탐색, 수정, PR 생성, 로그 분석 같은 일을 수행

여기서 핵심은 API 서버가 "판단과 상태"를 맡고, 실제 작업은 Kubernetes Job으로 뜨는 일회성 worker pod에서 수행된다는 점입니다. 서버는 stateless하게 유지하고, 실행 상태는 DB에 남기기 때문에 수평 확장이 쉬워집니다.

3.2 실제 작업은 Kubernetes Job에서 돈다

사용자가 팀챗에서 작업을 승인하면 orchestrator가 worker용 K8s Job을 띄웁니다.

• init container가 대상 레포를 clone

• 메인 컨테이너가 에이전트를 실행

• 작업 중간 상태와 결과를 서버에 다시 보고

• 작업이 끝난 pod는 자동으로 정리

이 구조를 택한 이유는 분명했습니다.

• 태스크마다 격리된 실행 환경을 줄 수 있다

• 역할별 이미지와 도구 구성을 다르게 가져갈 수 있다

• 실패한 worker만 다시 띄우거나 회수하기 쉽다

즉, 대화 인터페이스는 팀챗이지만 실제 실행기는 Kubernetes 위의 ephemeral worker입니다.

3.3 왜 Claude Code를 그대로 썼나

여기서 한 가지는 분명히 하고 싶습니다. hollon-ai는 코딩 에이전트의 코어 루프를 처음부터 다시 만든 시스템이 아닙니다. 코드 탐색과 수정, 계획 수립, 패치 적용, 테스트 실행, Git 작업 같은 핵심 실행은 worker pod 안에서 Claude Code를 그대로 활용합니다.

이렇게 한 이유는 단순합니다. Claude Code는 이미 잘 갖춰진 coding harness이기 때문입니다.

• 코드 탐색과 수정 루프가 안정적이다

• 계획, 수정, 테스트, Git 작업까지 이어지는 흐름이 이미 성숙해 있다

• 긴 작업 중에도 상태를 유지하고 복구하는 기본 동작이 갖춰져 있다

즉, 저희가 다시 만들어야 할 것은 "코드를 고치는 에이전트" 자체가 아니었습니다. 이미 잘 만들어진 coding harness를 다시 구현하기보다, 그 위에 조직이 실제로 쓸 수 있는 실행 인터페이스와 운영 계층을 얹는 편이 더 중요했습니다.

그래서 hollon이 맡은 일은 Claude Code를 대체하는 것이 아니라, Claude Code가 조직 안에서 자연스럽게 일하게 만드는 것이었습니다.

• 팀챗 스레드에서 요구사항과 승인 흐름을 받는다

• 어떤 작업을 언제 실행할지 상태머신으로 제어한다

• Kubernetes Job 위에서 격리된 실행 환경을 제공한다

• Datadog, Grafana, GitHub, 브라우저 같은 외부 도구를 연결한다

• 세션 밖 메모리와 조직 지식을 이어 붙인다

말하자면 Claude Code가 "잘 일하는 개인용 coding harness"라면, hollon-ai는 그 위에 "조직용 실행 harness"를 얹는 작업이었습니다.

3.4 상태머신이 승인과 리뷰를 강제한다

이 시스템이 단순한 챗봇과 다른 점은, 대화가 곧바로 임의 실행으로 이어지지 않는다는 데 있습니다. hollon은 태스크를 상태로 관리합니다.

• 계획이 필요한 작업은 PLAN_REVIEW에서 사용자 승인을 기다린다

• 구현이 시작되면 IMPLEMENTING으로 전이된다

• 코드 변경이 발생하면 CODE_REVIEW를 거쳐야 한다

• 머지 또는 결과 확정 이후에야 COMPLETED가 된다

즉, 사람의 개입 지점이 명시적입니다. "계획을 먼저 보고 승인한다", "리뷰를 반영하고 머지를 판단한다" 같은 협업 규칙이 대화 속 암묵적 합의가 아니라 시스템의 전이 규칙이 됩니다.

3.5 스레드는 단순 입력창이 아니라 컨텍스트 저장소다

이 흐름에서 가장 중요한 건 같은 스레드가 작업 단위가 된다는 점입니다.

실제 팀챗 대화는 대부분 한 번에 끝나지 않습니다.

• 첫 메시지에서 요구사항 제시

• 두 번째 메시지에서 제약 조건 추가

• 세 번째 메시지에서 "기존 작업 이어서 하지 말고 새로 진행"

• 네 번째 메시지에서 "리뷰 반영 끝나면 머지"

AI가 이걸 스레드 단위로 이해하지 못하면, 같은 대화 안에서도 매번 새 태스크처럼 오해하게 됩니다. 그래서 hollon은 한 줄 메시지만 보는 것이 아니라 root message와 reply history를 다시 읽어 현재 질문을 재구성합니다.

이 덕분에 요구사항, 제약 조건, 추가 피드백, 중간 상태, 최종 결과가 모두 같은 맥락에 남습니다. 새로운 UI에 옮겨 적을 필요도 없고, 나중에 왜 그런 결정을 했는지 되짚기도 쉽습니다.

3.6 질문과 구현 요청을 같은 입구에서 받는다

실무에서는 질문과 구현이 자주 이어집니다.

1. 사용자가 질문한다

2. hollon이 답한다

3. 사용자가 "그럼 이 방향으로 실제로 수정해줘"라고 말한다

4. 같은 스레드에서 planning과 implementation으로 넘어간다

질문과 구현을 서로 다른 인터페이스로 나누면, 오히려 사람이 컨텍스트를 다시 옮겨 적어야 합니다. 그래서 hollon은 대화형 요청과 구현형 요청을 같은 입구에서 받도록 설계했습니다.

3.7 역할별 에이전트와 도구를 분리한다

일반적인 conversation agent만으로는 브라우저 자동화나 관측성 분석 같은 작업을 다 처리하기 어렵습니다. 그래서 필요할 때는 specialized agent를 같은 스레드 문맥에서 호출합니다.

• 사용자는 "스크린샷 찍어줘", "로그 봐줘"라고만 말하면 된다

• conversation agent는 전문 작업만 별도 역할에 위임할 수 있다

• 결과는 다시 원래 팀챗 스레드로 돌아온다

사용자 입장에서는 하나의 봇처럼 보이지만, 내부적으로는 역할별 에이전트가 분업합니다. 같은 질문이라도 질문자의 역할과 권한, 접근 가능한 저장소와 데이터가 무엇인지에 따라 답변의 깊이와 실행 범위가 달라져야 합니다. 전사적으로 쓰이는 에이전트라면 질문자의 역할과 권한에 맞는 응답도 함께 설계해야 합니다.

3.8 운영 가능한 MCP는 프록시가 중요하다

초기에는 팀챗 MCP 도구가 외부 API를 직접 호출하는 방식이었습니다. 빠르게 붙이기엔 좋았지만 운영 단계에서는 금방 한계가 드러났습니다.

• pod마다 자격 증명을 직접 들고 있어야 한다

• 이미지나 파일 URL을 안전하게 다루기 어렵다

• 조직별 설정과 권한 관리가 복잡해진다

그래서 이후에는 구조를 바꿨습니다.

MCP server in pod
  → hollon-ai internal API
  → 서버가 조직별 자격 증명 resolve
  → 외부 API 호출
  → 결과 반환

이렇게 바꾸면 자격 증명은 서버가 관리하고, pod는 도구 호출만 하면 됩니다. 이미지와 파일도 서버 쪽에서 안전하게 다룰 수 있고, 조직별 설정도 한곳에서 관리할 수 있습니다.

3.9 진짜 어려운 건 기능보다 복구다

이 구조에서 가장 시간이 많이 든 부분은 기능 자체보다도 복구였습니다.

• 같은 webhook이 여러 pod에 동시에 들어와도 한 번만 처리돼야 한다

• stale lock 때문에 재시도가 막히면 안 된다

• worker pod가 중간에 죽어도 상태가 엉키지 않아야 한다

• 리뷰 코멘트가 새로 달리면 상태가 다시 올바르게 돌아가야 한다

사용자가 원하는 것은 긴 장애 보고서보다 지금 믿을 수 있는 상태입니다. 그래서 이 실행 시스템의 품질은 잘 될 때보다, 꼬였을 때 얼마나 자연스럽게 복구되느냐에 달려 있습니다.

4. 이 시스템이 실제로 맡기 시작한 일들

팀챗 기반 실행 계층이 붙자, hollon이 맡는 일의 종류도 달라졌습니다. 아래 사례들은 모두 외부 공개를 위해 익명화했지만, 같은 스레드 안에서 운영 대응, 분석, 후속 수정, 실제 반영까지 이어진 장면들입니다.

4.1 조직 전체 보안 위험을 다루는 방식

2026년 4월, 외부 보안 사고가 공유되자 팀챗 스레드에서 한 엔지니어가 @hollon에게 이렇게 물었습니다.

next 쓰는 프로젝트 전수조사 해줘

이 요청이 좋았던 이유는 문제 정의가 아주 현실적이었기 때문입니다. "이 취약점이 위험하다"는 뉴스 자체보다, 우리 조직 안에서 어디를 먼저 봐야 하느냐가 더 중요했기 때문입니다.

몇 분 뒤 hollon은 조직 내 Next.js/Vercel 배포 프로젝트를 훑어 다음 내용을 정리했습니다.

• 어떤 프로젝트가 실제 점검 우선순위인지

• 어디에 환경변수 노출 가능성이 있는지

• 어떤 항목은 즉시 로테이션이 필요한지

• 어떤 조치는 프로젝트 담당자, 어떤 조치는 GWS 관리자나 GitHub 관리자 역할인지

이후 같은 스레드에서 후속 질문이 이어지자, hollon은 단순 목록 나열이 아니라 역할별 액션 아이템까지 좁혀서 다시 정리했습니다. 예를 들어 어떤 팀은 Vercel 환경변수와 배포 설정을 확인해야 하고, 어떤 팀은 GitHub 토큰과 OAuth 앱 접근 정책을 점검해야 하는 식입니다.

중요한 건 hollon이 단순히 코드를 써준 것이 아니라는 점입니다. 조직 전체 리스크를 훑고, 영향을 받는 시스템을 식별하고, 누가 무엇을 먼저 해야 하는지까지 하나의 스레드에서 정리했습니다.

그리고 이 "전사적 대응"은 사람이 직접 멘션을 칠 때만 일어나는 것도 아닙니다.

운영 알람 채널에는 자동화가 붙어 있어, 특정 경고가 들어오면 hollon이 같은 스레드에서 바로 1차 트리아주를 시작합니다.

예를 들어 어느 날 데이터 저장소 관련 메모리 경고가 들어왔을 때, hollon은 몇 초 뒤 같은 스레드에 이렇게 정리했습니다.

• 어떤 구성 요소가 영향 범위에 들어오는지

• 지금 바로 확인해야 할 로그와 지표가 무엇인지

• 가능한 완화 조치가 무엇이고 각각 어떤 trade-off가 있는지

• 기존 운영 문서만으로는 바로 답하기 어려운 공백이 어디인지

이 사례가 흥미로운 건 사람이 호출하지 않아도 같은 실행 루프가 돈다는 점입니다. 보안 공지든 운영 알람이든, 조직 전체의 위험 신호가 팀챗에 들어오는 순간 스레드 위에서 자동 트리아주가 시작됩니다. 보안 대응과 상시 알람 대응이 결국 같은 인터페이스와 같은 실행 구조를 공유합니다.

4.2 배포 직후 Datadog/Grafana 점검

2026년 4월 9일, 한 개발자가 백엔드 서비스 배포 직후 이렇게 요청했습니다.

@hollon 조금 전에 배포했는데, Grafana랑 Datadog 지표상 이상징후가 있는지 확인해 줘

hollon은 배포 시각 전후의 Datadog, Grafana 지표를 확인한 뒤 다음을 같은 스레드에 정리했습니다.

• 사용자 영향이 있는 에러 로그는 없었음

• 5xx와 trace 에러율 이상 없음

• 롤링 배포 직후 잠깐의 latency spike가 있었지만 정상 범위로 회복

• 기능 문제와 직접 관련 없는 메트릭 경고만 후속 검토 대상으로 남김

이어진 질문에서는 수십 건의 로그를 다시 분류해, 배포와 직접 연관된 정상 종료 로그인지, 외부 의존성 오류인지, 단발성 확인 대상인지까지 나눠서 설명했습니다.

이 사례가 보여주는 것은 hollon이 단순히 "배포 잘 됐어요"라고 말하는 봇이 아니라는 점입니다. 관측 데이터를 읽고, 이상 여부를 판단하고, 후속 조치가 필요한 항목만 남기는 운영 인터페이스로 동작합니다.

4.3 팀챗에서 조직 지식을 바로 조회할 수 있다

이 시스템은 엔지니어링 전용 채널 안에만 머무르지 않았습니다.

한 팀원이 팀챗에서 커머스 환불 스펙을 이렇게 물었습니다.

전체 환불은 가능해 보이는데, 부분 환불은 어떻게 진행해야 하는지, 결제수단에 따라 또 무엇이 다른지 확인해줘

hollon은 관련 코드와 앱 함수 구현을 읽고 먼저 다음을 정리했습니다.

• 전체 취소와 부분 취소가 코드상 어떻게 갈리는지

• 어떤 결제수단은 자동 환불까지 가능하고

• 어떤 경우는 취소신청까지만 되고 관리자 수동 처리가 필요한지

• 어떤 종류의 부분 환불은 아예 지원되지 않는지

그리고 질문이 한 번으로 끝나지 않았다는 점이 더 중요했습니다. 같은 스레드에서 "그러면 태스크로 처음부터 끝까지 처리 가능한 경우는 뭐냐"는 후속 질문이 들어오자, hollon은 다시 환불 종류 × 결제수단 매트릭스로 정리해 완전 자동화 가능 케이스와 수동 처리가 필요한 케이스를 나눠 설명했습니다.

중요한 건 엔지니어링 전용 채널 바깥에서도 팀챗에서 조직 지식을 바로 꺼내 쓸 수 있게 되었다는 점입니다. 같은 인터페이스에서 시스템의 동작 원리를 질문하고 후속 질문을 이어갈 수 있게 되면서, hollon은 구현 에이전트이면서 동시에 지식 인터페이스로도 동작하기 시작했습니다. 전사적 에이전트에서는 답변 정확도만큼이나 설명 수준과 근거 범위를 함께 조절하는 일이 중요했습니다.

4.4 hollon이 자기 자신을 수정하고 실제 업무 흐름에 반영한 사례

가장 상징적인 사례 중 하나는, 개발자가 팀챗에서 hollon-ai 자체를 고쳐달라고 요청한 경우였습니다.

요청 내용은 단순했습니다. AWS 도구 중 CloudWatch Logs 관련 부분을 제거하고, 문서도 같이 정리해달라는 것이었습니다. 하지만 실제로는 다음이 한 스레드에서 모두 일어났습니다.

• hollon이 먼저 변경 계획을 세움

• 사용자가 계획을 보고 승인함

• hollon이 자기 자신의 레포를 수정해 PR을 생성함

• 후속 요구사항이 이어지자 같은 스레드에서 다시 이어서 작업함

• 최종적으로 머지까지 완료하고 상태를 보고함

이 과정에서 컨텍스트를 이어받아 작업을 계속했고, 결국 실제 코드와 문서 변경이 반영됐습니다.

이 사례는 팀챗 스레드가 단순한 채팅 로그가 아니라 아래 전체를 담는 작업 로그가 될 수 있음을 보여줍니다.

• 요구사항

• 계획 승인

• 자기 자신의 코드 수정

• 머지 완료

• 실제 동작 반영

중요한 건 AI가 PR 하나를 만든 것이 아니라, 자기 자신의 코드를 수정하는 작업을 한 스레드에서 끝까지 처리하고 그 결과를 실제 시스템에 반영했다는 점입니다.

4.5 로그 분석에서 실제 수정까지 이어지는 방식

또 다른 사례에서는 보안 방어 로직이 배포된 뒤 한 개발자가 "오류가 늘었는지 확인해 달라"고 요청했습니다.

hollon은 먼저 로그를 분류해 대부분이 정상 차단이라고 설명했습니다. 그런데 추가 분석 끝에, 정상 외부 URL의 링크 프리뷰까지 실패하는 사이드이펙트를 찾아냈습니다. 원인을 좁힌 뒤에는 "차단 규칙 자체는 맞지만, 특정 리소스가 검증 함수까지 흘러 들어가는 것이 문제"라고 정리했고, 결국 수정 방향 제안과 실제 PR 생성까지 이어졌습니다.

이 사례는 관측과 구현이 같은 인터페이스 안에서 이어질 수 있다는 점을 잘 보여줍니다. 로그를 읽고 끝나는 것이 아니라, 원인 분석과 코드 수정까지 한 흐름으로 연결됩니다.

4.6 얼마나 자주 호출되기 시작했는가

구조와 사례만 보면 "재미있는 데모"처럼 보일 수 있습니다. 그래서 실제 사용량도 같이 봤습니다.

아래 숫자는 hollon이 작업을 시작할 때 남기는 확인 중입니다... 메시지를 기준으로 집계한 것입니다. 직접 멘션으로 시작된 호출과, 운영 알람 채널에서 자동으로 시작된 호출을 같은 기준으로 셌습니다. 이 방식은 완벽한 제품 분석 지표는 아니지만, 실제로 몇 번 실행 루프가 돌았는지를 보기에는 충분히 유용했습니다.

월 단위로 보면 변화는 더 분명합니다.

• 2026년 3월 전체 실행: 777회

• 2026년 4월 1일~22일 전체 실행: 2726회

• 같은 기간 운영 알람 채널 자동 트리아주: 4회 -> 230회

주 단위로 보면 어떤 기능이 붙은 뒤 사용량이 튀었는지도 꽤 또렷하게 보입니다.

주 단위 실행량과 운영 알람 채널 자동 트리아주 비중을 함께 그린 그래프입니다. 숫자 기준은 hollon이 남긴 확인 중입니다... 시작 메시지이며, A/B/C/D 마커는 바로 아래에 설명한 변곡점과 대응합니다.

특히 2026년 4월 20일부터 22일까지 단 3일 동안만 봐도 459회가 실행됐습니다. 같은 시기 대표적인 공개 질의응답 채널 두 곳에서만 136회의 실행이 발생했고, 디자인·CSM·FDE 성격의 다른 공개 실무 그룹에서도 11회의 추가 실행이 확인됐습니다. 여기서 중요한 점은 이 숫자가 "비개발자 사용량"이 아니라, 엔지니어링 전용 채널 밖에서 관측 가능한 공개 그룹 usage를 보수적으로 세어 본 값이라는 것입니다. 역할 기준으로 더 넓게 잡으면 사용량은 더 늘어날 가능성이 높습니다. 이 정도만 봐도 hollon이 엔지니어링 전용 채널 안의 도구를 넘어, 공개 질의응답 채널과 여러 실무 그룹에서 함께 쓰이는 조직 인터페이스가 되기 시작했음을 보여줍니다.

재미있는 건 이 증가가 단순히 모델 품질이 좋아져서 생긴 게 아니라는 점입니다. 변곡점마다 붙은 기능이 꽤 분명했습니다.

• 3월 17일: 모든 메시지를 conversation agent로 모으고, thread history를 함께 읽도록 바꾸면서 스레드 기반 대화 품질이 눈에 띄게 올라갔습니다.

• 3월 23일~26일: 운영 도구, 이미지 입력, @mention 없이 이어지는 스레드 처리, specialized agent dispatch, 기존 PR 수정 workflow가 들어오면서 사용 범위가 코드 수정에서 운영 대응과 멀티에이전트 실행으로 확장됐습니다.

• 4월 1일~2일: trigger rules editor, keyword 기반 자동 트리거, 내부 프록시 경유 도구 호출, browser CDP가 들어오며 자동 실행 경로가 한층 안정됐습니다.

• 4월 6일~13일: reply dedup, PR thread notification, trigger role routing stabilization이 붙으면서 반복 사용에 버틸 수 있는 품질을 확보했습니다.

결국 hollon의 사용량은 자연스럽게 늘어난 것이 아니라, 실행 가능한 인터페이스를 하나씩 메워가며 늘어났습니다. 더 쉽게 부를 수 있게 만들고, 더 길게 문맥을 이어가게 만들고, 더 많은 종류의 작업을 같은 스레드에서 닫을 수 있게 만들자 사용량도 같이 뛰었습니다.

5. 기억하는 시스템: Supermemory에서 자체 메모리까지

실행 계층만으로는 충분하지 않았습니다. 세션이 끝날 때마다 맥락이 사라지면, 조직은 같은 설명을 반복하게 됩니다.

초기에는 Supermemory 연동으로 "세션 밖 기억"의 가치를 먼저 검증했습니다. 목표는 메모리 자체를 완벽하게 설계하는 것이 아니라, AI가 이전 대화를 기억하기 시작했을 때 사용자 경험이 얼마나 달라지는지 확인하는 것이었습니다.

가장 이해하기 쉬운 사례는 사소한 개인 메모리입니다. 어떤 스레드에서는 한 팀원이 "동료 A가 어느 도시에 산다는 정보를 메모리에 추가해 달라"고 요청했고, 이후 다른 스레드에서 hollon이 그 정보를 다시 꺼내 답했습니다.

물론 이 예시는 직관적일 뿐입니다. 메모리의 진짜 가치는 여기에 있지 않습니다. Supermemory로 세션 밖 기억의 가치를 확인한 뒤, 저희는 자체 메모리 계층까지 들여왔습니다. hollon-ai의 지식 시스템은 장기적으로 다음과 같은 구조를 지향합니다.

• L1: 현재 Claude 세션의 컨텍스트

• L2: 태스크 단위 메모리

• L3: 레포 또는 서비스 단위 메모리

• L4: 조직 단위 메모리

현재 영속 저장되는 것은 주로 L2/L3/L4입니다. 즉, 태스크에서 나온 결정과 발견, 레포 패턴, 조직 규칙 같은 것들이 메모리로 남고 검색될 수 있습니다.

이 메모리는 단순한 key-value 저장소가 아닙니다. hollon의 지식 계층은 크게 세 종류를 함께 다룹니다.

• 벡터 검색: 코드와 문서를 의미 기반으로 찾는다

• 그래프 검색: 심볼 의존성과 관계를 따라간다

• 메모리 검색: 태스크, 서비스, 조직 수준에서 축적된 결정을 다시 꺼낸다

즉, "예전에 누가 뭐라고 말했는가"만 기억하는 것이 아니라, 코드와 문서와 운영 경험을 함께 연결해 재사용하는 지식 시스템으로 가고 있습니다.

자체 메모리가 왜 필요했는지는 pod 한 번 재시작되는 순간에 가장 잘 드러났습니다. 파일 기반 메모리는 k8s pod가 재시작되면 사라지기 때문에, hollon이 한 번은 "이전에 메모리에 저장했다는 건 사실상 무효였다"고 스스로 정정하는 장면까지 있었습니다. 이후에는 save_learning 같은 도구로 knowledge base에 영속 저장하는 경로를 추가해, pod 재시작 이후에도 결정과 규칙이 살아남도록 바꿨습니다.

이렇게 쌓이는 기억은 대체로 다음 네 가지입니다.

• 어떤 태스크에서 어떤 결정이 내려졌는가

• 어떤 레포 구조와 코드 패턴이 반복되는가

• 어떤 제약과 운영 규칙이 조직 차원에서 유효한가

• 어떤 실패와 사이드이펙트가 이미 관찰되었는가

메모리는 챗봇의 말재주를 위한 장치가 아니라 조직의 학습을 누적하는 기반입니다. 섹션 4의 사례들이 가능했던 이유 중 하나도 이 기억이 뒤에서 조금씩 쌓이고 있기 때문입니다.

6. 만들면서 확인한 것들

hollon-ai를 만들며 몇 가지를 분명하게 확인했습니다.

좋은 레포만으로는 부족하다

AI Native한 레포는 출발점이지 종착점이 아닙니다. 레포가 좋아도 AI가 개인의 IDE 안에만 있으면 조직 전체의 실행 속도는 바뀌지 않습니다.

팀챗 스레드는 생각보다 강한 작업 단위다

하나의 스레드 안에 요구사항, 승인, 구현, 리뷰, 결과, 후속 질문이 모두 남습니다. 같은 스레드가 작업 로그이자 협업 인터페이스가 됩니다.

메모리는 "기억력"보다 "축적"이 중요하다

사람 이름이나 거주지를 기억하는 것은 이해하기 쉬운 예시일 뿐입니다. 진짜 중요한 건 태스크의 결정, 레포 패턴, 조직 규칙, 운영 중 발견된 사이드이펙트가 누적된다는 점입니다.

이미 잘 만든 harness를 다시 만들 필요는 없었다

이번 작업에서 다시 확인한 건, Claude Code가 이미 훌륭한 coding harness라는 점이었습니다. 코드 탐색, 수정, 테스트, Git 작업까지 이어지는 코어 루프를 처음부터 다시 구현하는 것보다, 그 위에 팀챗 인터페이스와 상태 관리, 메모리, 운영 도구 연결을 얹는 편이 훨씬 중요했습니다. hollon이 잘 동작하기 시작한 이유 중 하나도 "에이전트 자체를 새로 만들었다"기보다, 이미 잘 만들어진 실행 루프를 조직 안으로 가져왔기 때문입니다.

완전 결정론적인 전이보다 대화형 도구가 더 잘 맞는 순간이 있다

처음에는 상태머신을 더 촘촘하게 만들면 모든 흐름을 제어할 수 있을 거라고 생각했습니다. 하지만 실제 대화는 생각보다 더 비정형적이었습니다. 사용자는 질문을 하다가 구현 요청으로 넘어가고, 구현을 하다가 다시 제약 조건을 추가하고, 같은 스레드에서 계획을 수정합니다. 이때는 모든 전이를 미리 고정하는 것보다, conversation agent가 스레드를 읽고 필요한 상태 전이 도구를 호출하게 만드는 편이 더 자연스럽게 작동했습니다. 결국 중요한 건 결정론을 포기하는 것이 아니라, 결정론적인 상태 관리와 비결정론적인 대화 해석의 경계를 어디에 둘지를 찾는 일이었습니다.

운영 사례가 쌓일수록 시스템의 가치가 커진다

기능 개발 한 건 성공하는 것보다, 보안 대응, 배포 직후 점검, 로그 분석, PR 생성 같은 흐름이 반복 가능하게 되는 것이 더 중요했습니다. 이 구조의 가치는 화려한 데모보다 재사용되는 운영 루프에서 드러납니다.

가장 많은 시간은 실패를 덜 이상하게 만드는 데 들어간다

중복 처리, stale lock, rolling restart 중 false failure, placeholder reply 정리, review loop 복구 같은 안정화 작업은 겉으로 잘 보이지 않지만, 이런 부분이 없으면 이 실행 시스템은 금방 신뢰를 잃습니다. 사용자가 원하는 것은 긴 장애 보고서보다 "지금 믿을 수 있는 상태"이기 때문입니다.

7. AI Native 레포에서 AI Native 조직으로

이전 글에서 저는 AI Native 레포를 만드는 것은 좋은 온보딩 환경을 만드는 것과 다르지 않다고 썼습니다. 지금도 그 생각은 유효합니다.

이번에 한 일은 거기서 한 걸음 더 나간 것입니다.

좋은 레포와 좋은 제어장치 위에, 조직 전체가 AI를 호출할 수 있는 공용 인터페이스를 만들고, 그 위에 실행 harness와 메모리 계층을 붙였습니다. 그 결과 AI는 더 이상 개인용 코딩 도구가 아니라, 보안 대응과 배포 관측, 코드 수정과 지식 회수를 맡는 조직의 실행 시스템이 되기 시작했습니다.

결국 필요한 것은 더 똑똑한 모델 하나가 아니었습니다.

• 좋은 레포

• 강제되는 규칙

• 조직 지식

• 세션 밖에서도 남는 메모리

• 팀챗 같은 공용 인터페이스

• 그리고 이 시스템을 실제로 업무에 쓰려는 문화

이 여섯 가지가 함께 있어야, AI Native 레포는 AI Native 조직으로 확장됩니다.

hollon-ai는 아직 완성된 시스템이 아닙니다. 더 정교한 메모리 승격, 더 좋은 검색 모드, 더 자연스러운 자동화, 더 견고한 복구가 필요합니다. 그래도 지금은 분명히 말할 수 있습니다. 팀챗에서 @hollon을 멘션하면, 조직이 이미 일하고 있는 흐름 안에서 실행하고, 확인하고, 기억하는 구조가 실제로 동작하기 시작했습니다.

이런 문제에 관심 있는 분을 찾고 있습니다. 멀티에이전트 orchestration, Kubernetes 기반 실행 환경, observability, knowledge system, developer tooling 같은 문제를 함께 풀고 싶다면 채널톡의 문은 언제나 열려 있습니다.