1인 기업의 집중과 스킬
도구가 늘수록 착각하기 쉽습니다 — "에이전트를 더 똑똑하게 조율하면 병목이 풀린다." 실제 병목은 다른 곳에 있었습니다.
진짜 병목은 도구 수가 아니다
코딩 에이전트(Claude Code·Codex 계열), 상시 운영 에이전트(스케줄·메시징을 맡는 Hermes 계열), 로그인이 필요한 외부 SaaS를 대신 조작하는 브라우저 기반 에이전트(Grok Bot 계열) — 종류가 다른 도구를 동시에 쓰면 "누가 뭘 하고 있는지"가 가장 먼저 흩어집니다. 에이전트끼리 대화를 많이 시키는 것으로는 해결되지 않습니다. 필요한 건 사람이 소유한 목표·작업·증거 원장 하나(회사 두뇌)를 중심에 두고, 각 도구를 교체 가능한 실행면으로 쓰는 것입니다.
레인을 실패 비용으로 나눈다
"어떤 모델이 더 똑똑한가"가 아니라 잘못됐을 때 되돌리기 얼마나 어려운가로 배차하세요.
- 판단·설계 레인 — 상충하는 조건을 정리하는 일(전략·PRD·아키텍처). 되돌리기는 쉽지만 잘못 정하면 하위 작업 전체가 헛됩니다.
- 구현·생산 레인 — 명세가 고정된 코드 작성·리팩터·테스트. 검증 게이트가 있으면 실패 비용이 낮습니다.
- 상시 수집·전달 레인 — 정기 점검·알림·메시지 전달. 정형 작업은 LLM 없이 스크립트로, 해석이 필요한 마지막 단계만 에이전트로.
- 외부 SaaS 실행 레인 — API가 없는 대시보드·CRM 조작. 로그인 세션·파일·브라우저를 공유하므로 계정별 보안 경계는 사람이 별도로 설계해야 합니다.
- 승인 레인 — 비용 발생, 외부 발행, 계정 변경, 삭제처럼 되돌리기 어려운 모든 행위. 어떤 도구가 제안했든 사람이 마지막에 확인합니다.
사람이 반드시 쥐고 있어야 하는 것
- 목표 우선순위 — 무엇을 먼저 할지는 위임하지 않습니다
- 비용과 권한 — 어떤 도구에 얼마를 쓰고 무엇에 접근하게 할지
- 공개 발행 — 세상에 나가는 순간은 항상 사람 승인 뒤
- 비가역 행위 — 삭제·결제·계정 변경의 최종 확인
이 네 가지를 도구에 넘기는 순간, "AI가 다 했는데 왜 이렇게 됐지"를 되돌릴 방법이 없어집니다.
실제로 필요한 스킬
- 명세를 쓰는 능력 — 코딩 실력보다 우선. 모호함 없는 PRD를 쓸 줄 알아야 결과를 예측할 수 있습니다
- 검증 기준을 세우는 능력 — "완료"를 사람 느낌이 아니라 확인 가능한 조건으로 정의하는 습관
- 도구 경계를 설계하는 능력 — 어떤 역할에 어떤 권한을 줄지 판단(매뉴얼 02)
- diff를 읽는 최소 리터러시 — 직접 짤 필요는 없지만, 뭐가 바뀌었는지 보고 위험을 감지할 정도는 필요합니다
- 실패를 기록하는 습관 — 같은 실수를 반복하지 않으려면 실패 원인을 두뇌에 남겨야 합니다(매뉴얼 03)
- 멈출 줄 아는 판단력 — 자동화가 잘 도는 것처럼 보여도, 방향이 틀렸으면 계속 도는 것보다 멈추는 게 더 어렵고 더 중요합니다
흔한 함정 — 우리가 직접 겪은 것
- 슈퍼 오케스트레이터의 유혹 — 도구 하나가 나머지를 전부 지휘하게 만들고 싶어집니다. 실제로는 각 도구가 서로의 세션·권한·메모리를 자동으로 정본화하지 않으므로, 지휘탑 하나를 새로 짓기보다 공유 원장(회사 두뇌) 쪽이 유지비가 낮았습니다.
- 관제 UI를 먼저 짓고 싶은 유혹 — 화면이 있으면 다 보인다는 착각. 데이터 계약(무엇을 기록할지) 없이 화면부터 만들면, 화면이 낡은 데이터를 예쁘게 보여주는 것으로 끝납니다.
- "만들었는데 배선 안 함" — 파일을 생성한 것과 그 파일을 실제로 누군가 읽는 것은 다릅니다. 소비처가 진짜로 그 결과를 쓰는지까지 확인해야 완료입니다.
- 자율성을 목표로 착각하기 — "더 많이 자동화했다"는 진척이 아닙니다. 목표는 결과이지, 사람이 개입하는 횟수를 줄이는 것 자체가 아닙니다.