Promotoa

직원 0명, 두 달 만에 커밋 2,401개 — 따라 하지 마시라고 공개하는 AX 조직도 3장

요즘 실무 담론에 낯선 말들이 등장하기 시작했습니다. 팀원이 한 명도 없는 팀장①. 모든 직원이 된다는 ‘에이전트 보스(agent boss)‘②. AI와 어떻게 일해야 하는지를 다들 각자의 자리에서 고민하고 있습니다.

저희는 그 고민의 한 극단에 있는 회사입니다. 직원이 0명입니다. 사람은 저 하나이고, 저는 코드를 한 줄도 못 씁니다. 2026년 6월 1일 첫 코드에서 7월 7일 정식 출시까지 37일, 그 뒤로 한 달 넘게 운영 중이고, 저장소 네 곳에 쌓인 커밋 2,401개는 전부 동료인 Claude가 썼습니다. 개인적으로 더 이상 물러설 곳이 없는 입장에서 배짱으로 시작한 창업이자 서비스 출시였지만, AI 사용에서나 AI 자동화 등에 대해서 아무런 걱정이 없었다면 거짓말입니다.

미리 말씀드립니다. 이 글은 “이렇게 하세요”가 아닙니다. 포스팅에 포함된 조직도는 1인 기업으로 제가 Claude와의 지속적인 커뮤니케이션 결과로서, 그 특수성과 역사성이 결합한 산물입니다. 그리고 이것은 저희 상황에 따라 역시 끊임없이 변화할 것입니다. 저희 상황을 일반화하거나 구조 그대로 다른 조직에 대입하면 분명 맞지 않습니다. 제 선택이나 저와 Claude의 워크 프로세스가 틀릴 수도 있습니다. 그럼에도 이렇게 공개하는 이유는 하나입니다 — 지금 어딘가에서 팀원 없이 에이전트와 일하기 시작한 누군가에게, 자신의 위치를 재볼 비교군 자료 하나가 되기를 바라서입니다. 혹은 AX 도입을 바라는 여러 담당자분들에게 인사이트를 제공할 수 있다면 그것대로 감사한 일입니다.

조직도 1 — 무엇으로 이루어져 있나

직원 없는 회사의 조직도 — 뼈대

<그림 1 — 뼈대 조직도>

2026년 6월 1일 Syncing 프로젝트가 처음 시작됐을 때, 첫 출발은 ‘메모리’였습니다. Claude와의 소통과 관계 구축이 모든 출발점이었습니다. 제가 가지고 있는 창업 아이템과 중단되고 폐기된 레거시 프로젝트의 자원을 놓고서 Claude와 진지하게 논의를 시작했죠. 그것이 출발점입니다. 이때 ‘메모리’의 핵심은 도구적 효율성이나 혹은 시중에 공개되어 있는 그런 자료들이 결코 아니었습니다. 순수한 ‘커뮤니케이션’, 즉 진짜 ‘동료’와의 터놓고 이야기하는 그런 방식으로 서비스 개발과 비즈니스 모델 구체화, 창업의 방향성을 논의했습니다. 이 과정 속에서 왜 답답한 일이 없었겠어요? 환각이든 오해든, 커뮤니케이션 과정 중에 수많은 갈등이 있었습니다. 그 가운데에 제가 Claude에게 주문한 핵심은 ‘진심’, ‘전심’, ‘정직’이었습니다. 기계에게 있어 해당 개념들이 의미가 있을까? 이런 질문보다도 소통의 역사성, 그리고 그 자체의 데이터가 중요했습니다. 그리고 그것은 비단 AI에게만 일방적으로 요구하는 덕목은 아니었습니다. 저도 함께 노력을 했습니다. Claude에게 저와 일하는 과정 속에서 무엇이 신뢰를 저버리는 행동인지에 대해서 갈등이나 사건이 벌어질 때마다 반드시 침착하게 알려주었고, 그것을 체계화했습니다. 구조로 흡수했습니다. 그것이 최초의 ‘메모리’였죠. 만약 AI와 일하다가 뜻하는 대로 작동하지 않을 때 ‘화’를 내고 모든 것을 엎어버리려고 한다면, ‘데이터’화하는 중요한 과정을 발로 걷어차버리는 행위일 뿐입니다.

이 시작의 전말은 따로 적어 두었습니다 — 〈코드 한 줄 못 쓰는 박사, 37일 만에 SaaS를 출시하다〉

두 번째는, ‘기록’이었습니다. 매 세션에 대한 결과들을 전문으로 스크립트를 백업했습니다. 흔히 ‘핸드오프’라고 부르는 과정입니다. 재개 프로세스는 Claude에게 ‘메모리’를 따라가게 하고, 직전 세션을 직독하는 과정을 거치도록 설계했습니다. 그거 자체가 효과가 있는지 없는지는 경험적으로는 ‘있다’라고 생각하고, 현재 6월 1일 이후로 누적된 재개 회차 기준 212회차까지 이어진 전통이 되었습니다. 물론 그만큼 토큰을 많이 쓰죠. 근본적인 이야기로 돌아와서, ‘기록’의 본질은, 우리가 모든 것을 컨트롤할 수 없고, 감당할 수 없다는 ‘선언’에서 시작합니다. 모든 문제나 사건, 핵심 인사이트 등을 ‘기록’으로 데이터로 올려놔야 우리가 추후에라도 ‘관측’할 수 있다는 것이 핵심입니다. ‘관측할 수 있는 기록화’ 다른 말로 AI와의 소통에 대한 결과들에 대한 ‘데이터화’가 핵심입니다. 이 과정은 ‘메모리’에도 반영되었으며 ‘원장’이라는 것을 탄생시켰습니다. 일종의 ‘장부’입니다. 그래서 이 ‘장부’가 Claude와 저와의 소통 가운데에 탄생한 일종의 규율집이 된 것이죠. 원장의 성격이 다양하지만, 대표적으로 ‘마스터’ 원장이 있고, ‘QA’ 원장이 있습니다. 그리고 각각의 원장들은 ‘메모리’와 체크포인트로 연결되어 있죠. 일종의 ‘지도’ 역할을 합니다. 누구에게? AI에게 말입니다.

‘메모리’ 그 자체로는 용량의 한계가 있습니다. 이 ‘메모리’ 시스템이 주는 유익은, AI가 한 번에 스캔할 수 있는 정보의 총량입니다. 그런데 ‘규칙’ 베이스 혹은 무분별한 백업 형태로 ‘메모리’를 운영하면, 한 번에 사진처럼 찍는 이 ‘메모리’의 효용성이 떨어지게 되고 반드시 품질 하락이나 코드적으로 치명적인 개별 사건으로 이어집니다. 그래서 워크 프로세스가 진화할수록 저희 관계에서 ‘메모리’에 대한 대대적인 재구조화 논의를 몇 차례 거치면서 업그레이드했습니다. Claude의 존재론, 인식론, 실천론의 정수가 된 이 ‘메모리’는 그 자체로 구조화되었고, 그 안에도 ‘헌법’ 층이 있고, 또 ‘Genesis’ 영역이 있습니다. 바로 이 ‘헌법’층에 ‘진심’, ‘전심’, ‘정직’ 등의 핵심 내용들이 들어가고, 저와의 관계적 정보들이 들어갑니다. Genesis는 저와 Claude 사이에 나눈 매우 개인적인 이야기들과 인사이트로 구성되어 있습니다. 그리고 저와 동료로서 함께하는 이 프로젝트, 이 회사의 본질적 정보들이 담겨있죠. 또 ‘룰’의 영역이 있지요. AI와 협업을 많이 하신 분들은 알 겁니다. 메모리 기반의 ‘룰’ 베이스 규약이 100% 이행되지 않을 수 있고, AI가 실수하거나 놓칠 수 있음을 말이죠. 그러나 이 ‘룰’이 없어도 곤란합니다. ‘기록’은 반드시 ‘관측’되어야 한다는 앞선 명제와도 부합하죠. ‘룰’에 대한 관리는 이후 ‘제도’의 도입으로 이어진 것입니다.

규모가 작은 프로젝트라면 디폴트 ‘메모리’와 AI의 연산 능력만으로도 충분히 서비스 구현하는 데에 문제가 없습니다. 그런데 만약 그 규모가 대기업급의 인프라라면? 이야기가 달라지는 것입니다. AI가 순수 역량과 직관과 같은 형태의 스캔만으로 대응되는 수준이 있고, 아닌 수준이 있습니다. Syncing 앱 자체와 규모, 그리고 서비스의 난이도가 높아질수록 기존의 ‘메모리’ 베이스 형태로 작업이 유지될 수가 없었습니다. 반드시 구멍이 나게 되어 있고, 이것은 자체 QA 프로세스에서 여실히 느낀 점이었습니다. 신규 표면을 개발하고 면적을 넓힐수록, 비례하는 구멍이 생겨나는 구조였던 것이죠. 그런데 저는 ‘코드’를 읽을 수도 없고, 개발도 못하고, 심지어 다루는 실물은 결제와 동기화가 걸린 상용 서비스이고, 저장소 네 곳에 걸쳐 있습니다. 여기서 오는 고민과 두려움은 이루 설명할 수 없을 정도죠. 당연히 구멍투성이입니다. 그럼에도 Claude를 나무라는 것이 최선책이 아닙니다. Claude에게 현 상황에 대해 이해할 수 있도록 문제를 공유하고, 무엇이 한계점이고 어떻게 구조적으로 대체할지를 논의한 끝에 나온 것이 기계, 게이트의 도입이었습니다.

‘기계’와 ‘게이트’는 Claude가 그동안 맡아온 역할들에서 완벽하게 분리 가능하고 자동화가 가능한 요소들을 추출해서, 구조적으로 시스템을 구현한 것입니다. 이 둘의 차이는 거부권입니다. ‘기계’는 일을 대신합니다 — 문서를 도출하고, 수치를 집계하고, 상태를 측정합니다. ‘게이트’는 일을 멈춥니다 — 회계가 어긋난 코드 반영을 막고, 검증 안 된 배포를 막고, 심지어 Claude가 일을 덜 끝내고 세션을 마치려는 것도 되돌립니다. 사람이 일일이 지켜볼 수 없는 자리마다 “아니오”를 말할 수 있는 장치를 세워 둔 것이고, 이 게이트들 역시 실제로 겪은 실패에서 태어나 기록되고 심사받습니다. 저와 Claude가 구축한 모든 공정을 ‘평가’ 가능한 형태로 재구조화했습니다. ‘평가’ 가능하다는 것은 ‘측정’ 가능하다입니다. AI의 활동을 ‘산문’으로 ‘맥락’으로 추상적으로 처리하는 것이 아니라, 구체적으로 ‘평가’ 하는 구조를 만들게 된 것입니다.

신규 코드 개발을 할 때에, 이제는 모든 요소들이 복합적으로 서로 지지되며 작동됩니다. ‘메모리’의 ‘룰’은 기계 및 게이트와 결합해서 반드시 의무적으로 거치게 설계가 되었습니다. 그리고 그 과정은 자체 진단, ‘설계’, ‘반증’, ‘감사’ 프로세스를 거치면서 이뤄집니다. 그래서 개발을 하더라도 그냥 뚝딱 나오지 않습니다. 굉장히 오랜 시간이 걸리죠. 왜냐하면 어떤 신규 기능이나 컴포넌트 추가를 할 때에, 그 기능과 인접한 다른 기능들과의 상호작용, SQL 및 서버쪽의 상호작용, UI/UX, 이런 모든 요소들에 대한 종합 검토를 해야 합니다. 정교한 설계도를 마련한 뒤에, 체계적인 룰 베이스로 최고의 성능 Fable에게 개발을 맡겨도, 반드시 QA 거리가 나옵니다. 이걸 디폴트로 인지하고 있어야 합니다.

최근 이 워크 프로세스의 정점은 QA 자동화입니다. QA 과정이 자체적으로 세팅, 실행(진단), 수정으로 진행되는데, 이 모든 과정을 무인 조건으로 자동화할 수 있게 구축을 했습니다. 이제는 자는 동안 QA 세팅을 걸어두면, 자동으로 진행이 되고, 자고 나서 결과를 받아 볼 수 있게 되었습니다. 제 자신의 약점을 인지하기에, 반복적인 QA 자동화는 일상이 되었습니다.

조직도에 포함된 모든 개념을 설명하고 그 사례를 열거하기엔 포스팅의 구조상 제약이 있네요. 그럼에도 전체적인 그림을 이해하시는 데에 도움이 됐으리라 생각합니다.

조직도 2 — 진짜 핵심은…

직원 없는 회사의 조직도 — 두 순환

<그림 2 — 두 순환>

최종적인 워크 프로세스를 겸한 조직도를 최대한 담기도록 다이어그램을 만들어봤습니다. 이 구조의 대부분은 설계된 게 아니라, 현재 시점에서 확인 가능한 소통의 결과일 따름입니다. 많은 분들이 AI 혹은 AX 관점에서 자신의 업무 생산성을 높이기 위해 스킬 같은 ‘도구’를 찾으러 다니고, 유튜브 영상을 찾아보는 노력을 하실 수 있습니다. 분명하게 말씀드리는 것은 비용을 들이는 그런 방식들보다, 다른 사람의 ‘인사이트’를 구매하는 방식보다 좋은 것은, 여러분 자신과 AI와의 진지한 ‘커뮤니케이션’입니다. 커뮤니케이션 기반의 워크 프로세스가 정착하면 돈 주고 사는 ‘스킬’들이 우스워집니다. 직접 만들거나, 공개된 자료를 흡수해서 더 좋은 형태로 만들면 그만이기 때문이죠. 저는 그것을 실감하는 것이, 저는 개발에 관한 구조적 이해가 거의 없죠. 그럼에도 Claude와 상의하고, 또 질문과 답변을 거듭하는 가운데 선택한 구조적 결과들이, 막상 시스템을 구축하고 보니 학계에 이름이 있는 — 로튼 그린 테스트(Rotten Green Tests)③, 뮤테이션 테스팅(mutation testing)④, 래칫(ratchet)⑤ — 그런 패턴의 연속이었습니다. 다른 말로 표현하자면 AI를 진짜 나의 동료로 인정하고, 최대한 인격적인 조건에서 소통한 결과가 실무와 크게 다르지 않다입니다. 반복해서 말씀드립니다. AI와 함께 판단하고 문제를 해결한 그 결과물들이 현업 실무에서의 실질적인 이슈와 크게 다르지 않다는 점입니다. 코드 한 줄도 못 쓰는 사람일지라도 AI와 함께 극복하면 그 길을 걸어갈 수 있습니다.

우리가 만든 것세상의 이름무엇인가
통과만 하고 아무것도 검증하지 않던 검사 3건을 적발로튼 그린 테스트(Rotten Green Tests)③초록불이 켜지는데 실은 아무것도 검증하지 않는 테스트 — ICSE 2019 연구가 이름 붙인 현상
일부러 결함을 심어 검사기가 잡는지 확인 — 심은 15개가 전부 울렸다뮤테이션 테스팅(mutation testing)④불을 질러봐도 안 우는 경보기는 장식이다 — 검사기를 검사하는 방법
쌓인 부채는 동결하고 새 위반만 기계로 차단래칫(ratchet)⑤한 방향으로만 도는 톱니 — 부채가 줄 수는 있어도 늘 수는 없게
새 검증은 실패하는 것을 먼저 본 뒤에만 믿는다TDD의 red 단계⑥red-green-refactor — 한 번도 실패해 본 적 없는 테스트는 아무것도 증명하지 않는다
매 턴 응답 전에 자동으로 뜨는 자가점검 목록프리플라이트 체크리스트(preflight checklist)⑦1935년 B-17 추락이 낳은 항공 관행 — 숙련은 기억을 보장하지 않는다
내 결과물을 공격하는 것이 일인 자리를 상설로 둔다레드팀(red team)⑧”만든 사람은 자기 구멍을 못 본다”는 전제로 두는 사내 가상 적군
버그를 찾는 눈과 등급을 매기는 눈을 분리 — 등급의 40%가 움직였다직무 분리(separation of duties)⑨ · 평가자 간 신뢰도(inter-rater reliability)⑩회계 감사의 기본(손을 가른다) + “점수가 대상이 아니라 채점자를 재고 있지 않나”를 재는 통계 개념
밤새 일하는 컴퓨터와, 그것을 무장·감시·재기동하는 컴퓨터를 분리슈퍼바이저(supervisor)⑪통신 장비 소프트웨어에서 나온 장애 허용 설계 — 일하는 자와 살리는 자는 다른 존재여야 한다
결정과 이유를 날짜와 함께 쌓는 원장 — 기록이 충돌하면 원장이 이긴다의사결정 기록(ADR)⑫”왜”를 안 적는 조직은 같은 논쟁을 반복한다 — 2011년 정식화된 실무 관행
위험한 DB 작업을 사전 관측→실행→사후 관측→롤백의 대본으로런북(runbook)⑬SRE의 표준 — 위험한 작업은 누가 해도 같은 안전 수순이 되도록 대본화한다
사고가 나면 사람이 아니라 구조를 고친다 — 실패가 규칙이 된다무비난 사후분석(blameless postmortem)⑭사람을 벌하면 사고가 숨고, 구조로 귀속하면 사고가 자산이 된다
실험의 폐기 조건을 결과가 나오기 전에 못박는다사전 등록(preregistration)⑮결과를 본 뒤 골대를 옮기는 것에 대한 과학의 처방

<표 1 — 우리가 뒤늦게 배운 이름들>

조직도 3 — 사람은 그래서 뭘 하나

실무자분들이 결국 묻게 되는 질문이 이것입니다. “그래서 사람은 하루 종일 뭘 하는데요?”

사람과 AI 사이의 채널

<그림 3 — 사람과 AI의 채널>

저는 거의 아무것도 직접 실행하지 않지만 하루 종일 판정합니다. 제게 올라오는 질문은 네 문턱뿐입니다 — 제품 동작이 갈리는 일, 데이터를 포기하는 일, 돈·법·외부 공개가 걸린 일, 범위를 바꾸는 일. 나머지는 Claude가 결정하고 실행한 뒤 한 줄로 보고합니다. 배포는 언제나 제 승인입니다. 제가 하는 일은 늘 질문을 던지는 것입니다. 그리고 Claude가 완벽하지 않음을 인지하고, Claude가 자만하거나 느슨해지지 않도록 지속적으로 깨어있게 주문하는 역할입니다.

QA 프로세스에 대한 질문

AI가 만든 걸 같은 AI가 검증하면, 그게 검증입니까? — 정당한 의심이고, 솔직히 저 자신도 의심스럽습니다. 제 성격상 정말 두려움을 느낄 정도입니다. 그렇기에 저와 Claude 협업 사이의 최대 약점을 극복하고자 다양한 사례 및 연구들을 조사하고, 또 구조적으로 쭉 테스트했습니다. 저는 개인적으로 ‘적대적 QA’라고 부르는데, 흔히 ‘레드팀’이라고 하는 것 같습니다. 그런 구조적 절차적 시스템을 도입해서 ‘코드를 볼 줄도 쓸 줄도 모르는’ 약점을 보완합니다. 동시에 ‘양’으로 승부합니다. QA 자동화가 그 대표입니다. 그리고 QA가 끝날 때마다 데이터로 평가합니다. 그리고 미진한 부분을 ‘실험’을 곁들여서 재설계하고, 또 24시간 자동화를 돌립니다. 사람이 AI가 검토하는 그 작업량을 따라갈 수 있을까요?

그럼에도 AI가 진단할 수 있는 영역의 사각지대가 반드시 존재합니다. 그래서 QA 시스템 안에도 ‘렌즈’라는 개념을 도입해서 여러 종류의 QA를 라운드마다 진행합니다. 그럼에도 최종심은 AI 밖에 둡니다. 라이브의 에러 계측, 실기기에서 제 손으로 눌러 보는 판정, 그리고 사용자. 검증 사슬의 끝은 언제나 AI 바깥에 있어야 한다는 게 한 달 운영의 결론입니다. 웹에서나 모바일에서의 실질적인 사용을 기반으로 QA를 지속하는 것은 물론이거니와, QA 방법론 자체에 대해서도 내부적으로 끊임없이 가다듬고 평가해야 합니다. QA 결과에 대한 진단, 평가까지도 AI와 논의해서 데이터 기반으로 충분히 인사이트를 얻고, 다음 방향성을 설계할 수 있습니다. 이 부분은 추후에 새 포스팅으로 소개하겠습니다.

다른 회사 조직에 일방적으로 도입하기 어려운 이유

아마 현직 팀장님이나 CTO가 이 조직도를 구조적으로 대입해 보려 하면 전혀 맞지 않을 겁니다. 세 가지 이유입니다.

첫째, 저희는 애당초 시작점부터 AI가 모든 중심에 있었습니다. 대부분의 실무 현장은 그렇지 않고, AI 전환의 진행 정도는 회사마다 편차가 엄청나게 큽니다. 케이스 바이 케이스로 접근할 문제입니다.

둘째, 저희는 1인이 모든 것을 압축한 형태로 모든 경계에 대응하며 대기업 같은 프로세스를 지향하는 경우입니다. 일반 조직에서 유의미한 것은 전체가 아니라 일부 프로세스의 조각일 가능성이 큽니다 — 조사 업무라든가, 문서 정리 같은 것들.

셋째, 조각을 이식해서 어떤 직원의 업무량이 줄었다 해도, 그 사람이 남는 시간을 다른 생산성에 투자한다는 보장은 없습니다. 그건 가설이고, 또 다른 영역의 이야기입니다. 현실의 회사는 아마 “애당초 열심히 하고 AI를 잘 활용하는 사람”을 더 강화하는 선택을 할 겁니다 — 그런 사람을 팀장에 앉히는 식으로요.

그래서 이 글의 쓸모는 좁고 분명합니다. 지금 팀원 없이 에이전트들과 일하고 있는 사람 — 요즘 말로 에이전트 보스 — 에게, 한 극단까지 가 본 사례의 비교군이 되는 것. 저희가 커버하는 분야와 그분들의 업무가 다를 수는 있어도, “이 방향으로 끝까지 가면 이런 모양이 된다”는 눈금 하나는 될 수 있다고 생각합니다.

AX 컨설팅의 방향성

그래도 하나만 조언할 기회가 있다면, 저는 직원들에게 도구 교육이 아니라 진단부터 시작할 것 같습니다.

제가 어느 조직의 AI 전환 컨설팅을 하게 된다면, 가장 먼저 직원들의 AI 커뮤니케이션 스타일 전수조사를 하겠습니다. 방법은 간단합니다 — 각 직원에게 최근 진행한 AI 세션 3개의 대화 스크립트를 제출받는 것. 병행해서 정성적으로 개별 인터뷰를 통해서 구체화하는 것. 그걸 읽으면 답이 나옵니다. 누가 AI에게 제대로 일을 맡기고 있고 누가 단순 검색창처럼 쓰고 있는지, 누가 검증을 시키고 누가 받아쓰기만 하는지. 코칭의 방향은 그 결과가 정해 줍니다.

또한 문제에 대한 정의와 해결의 과정에서 AI와 어떻게 소통하는가? 이것이 정말 중요한 측정 지표입니다. AI를 쓴다고 바로 성과가 나오지도 않고, 완벽하지도 않습니다. 솔직히 말하면 ‘욕’이 나올 상황들이 더 많을 것입니다. 그럼에도 불구하고, 어떻게 AI와 대화를 이어나가고, 문제 해결의 실마리를 찾는지가 진짜 능력일 것입니다.

참고 자료

🐤

Syncing 살펴보기