터미널 = 개발자의 도구라는 고정관념

Claude Code는 '코딩 에이전트 (Coding Agent)'로 소개되는 경우가 대부분입니다. 하지만 몇 달간 사용해 본 지금, 제 안에서의 위치 설정은 바뀌었습니다. 이것은 개인의 업무 기반 (Back Office)이다, 라고 말이죠.

저는 혼자서 여러 개의 스몰 비즈니스를 운영하고 있습니다. 코드도 작성하지만, 업무 시간의 대부분은 개발이 아닙니다. 잠재 고객에게 연락하기, 의사결정, 주간 회고, 태스크 정리 ── 이른바 '경영의 잡무'입니다. 이 기사에서는 그 비개발 업무를 Claude Code에게 맡기고 있는 실제 사례 4가지를 소개합니다.

참고로 Anthropic의 커뮤니티 앰배서더 모집 페이지에도 "개발자 직함은 필요하지 않습니다."라고 명시되어 있습니다 (출처: https://claude.com/ja/community/ambassadors 2026-07-14 열람). 도구의 측면에서도 개발자 이외의 영역으로 열리기 시작했습니다.

코드는 한 줄도 나오지 않습니다. 나오는 것은 Markdown 파일과 규칙 (Rule) 설계뿐입니다.

사례 1: 주간 리뷰를 대행시키기

금요일 주간 리뷰, 계속하고 계신가요? 저는 계속하지 못했습니다. 집계가 귀찮기 때문입니다.

지금은 /weekly-review라고 입력할 뿐입니다. 스킬 (Claude Code에게 학습시킨 절차서)이 다음을 실행합니다.

• 이번 주 활동 로그 · 태스크 대장 · 기록 파일을 집계한다
• 인간에게 단 2개의 질문만 한다 (예를 들어, 이번 주의 판단에서 망설였던 것 · 다음 주의 최우선 사항)
• 답변을 기록 파일에 추가하고, 다음 주 분량의 정리를 업데이트한다

설계의 핵심은 "집계는 AI, 판단만 인간"으로 분리하는 것입니다. 주간 리뷰가 지속되지 않는 원인은 판단이 싫어서가 아니라, 판단 전 단계인 집계가 무거웠기 때문이었습니다. 전 단계를 전부 AI에게 넘기니, 제가 금요일에 할 일은 2개의 질문에 답하는 것뿐이 되었고, 덕분에 리뷰를 지속할 수 있게 되었습니다.

마찰의 비대칭 설계

이 리뷰에는 습관 가드(Habit Guard)의 승격·강등 규칙도 포함되어 있습니다.

• 승격 (제한을 강화하는 것)은 무마찰: 경고 후에도 계속 진행한 일수가 주 2회를 초과하면, 경고 모드에서 차단 모드로 자동 승격
• 강등 (제한을 완화하는 것)은 유마찰: 완화할 때는 이유 기입이 필수

인간은 자신에게 관대한 방향으로는 매끄럽게 움직이므로, 그쪽 방향에만 마찰을 둡니다. 규칙을 스스로 작성할 수 있는 것이 Claude Code의 재미이며, 이는 "자신의 의지력을 외부화하는" 경험입니다.

사례 2: 의사결정의 정체를 매일 아침 직면하기

혼자 일하다 보면 아무도 의사결정을 재촉해 주지 않습니다. "결정만 하면 앞으로 나아갈 안건"이 어느샌가 2주 동안 멈춰 있는 것 ── 이것이 1인 기업의 숨겨진 병목 현상(Bottleneck)이었습니다.

대책으로서, 의사결정은 반드시 Markdown 대장에 "기표"하는 규칙을 세웠습니다.

## 의사결정 큐 (결정만 하면 1루프 종료)
| 결정 사항 | 기표일 | 선택지 | 권장 | 상태 |
|---|---|---|---|---|
...

그리고 Claude Code가 대장에서 HTML 형태의 "decision board"를 자동 생성하며, 세션 시작 시마다 매번 다음과 같이 주입됩니다.

[decision] 미결정 3건 (최고 1일 정체) → decision-board.html

포인트는, AI에게 결정하게 하는 것이 아니라, 결정되지 않은 것을 가시화하게 하는 것입니다. 기표일로부터 정체 일수를 자동 계산하여 방치 상태를 숫자로 보여줍니다. 그것만으로 "미결정 상태로 잊어버리는 것"이 거의 사라졌습니다. 선택지와 권장안을 AI에게 정리하게 하는 단계까지는 맡기되, 결정 버튼은 항상 인간이 누릅니다.

사례 3: 태스크의 위치를 "한 질문"으로 결정하기

태스크 관리 도구 선정으로 소모된 경험은 누구에게나 있을 것이라 생각합니다. 저의 결론은 도구보다 먼저 **경계 규칙 (Boundary Rule)**이었습니다.

『남아 있는 작업은 인간의 송신 · 기입 · 공개 · 결정인가?』

• Yes → 인간의 대장 (Markdown)으로
• No (구현 · 검증 · 조사) → 기계의 태스크 큐 (Task Queue)로

이 한 질문으로 모든 태스크의 위치가 일의적으로 결정됩니다. 기계의 큐에 들어간 것은 Claude Code가 소화하며, 완료 시에는 검증 증적을 작성하게 합니다. 인간의 대장에 남는 것은 정말로 인간만이 할 수 있는 일 ── 보내기 · 기입하기 · 공개하기 · 결정하기 ── 뿐입니다.

도입하고 나서 알게 된 것은 인간의 대장에 남는 태스크의 적음입니다. "내가 반드시 해야 하는 일"의 대부분은 사실 그렇지 않았습니다. 반대로 말하면, 정말로 인간이 해야 할 몇 건의 일이 잡다한 태스크의 산더미 속에 파묻혀 있었던 것입니다.

사례 4: 「과잉 생산」을 시스템으로 막기

마지막은 실패담입니다. AI로 생산성이 높아지면, 내부 정비에만 몰두하게 되는 병에 걸리게 됩니다.

도구를 연마하고, 템플릿을 정리하고, 관리 체계를 만드는 일── AI와 함께라면 이 과정이 즐겁고, 게다가 결과물도 계속 완성되어 나갑니다. 반면 고객에게 연락하거나 결과물을 공개하는 것과 같은 「시장에 접하는 업무」는 AI가 대신할 수 없기 때문에, 상대적으로 점점 더 무겁게 느껴집니다. 저의 관찰(전송만 남은 몇 건의 태스크에 대한 개인적인 기록이며, 엄밀한 통계는 아닙니다)에 따르면, 기계 측의 태스크(자료·도구·계획)는 90점대까지 완성되는 반면, **인간의 전송만 남은 태스크의 방치율은 거의 100%**였습니다. 만드는 능력이 올라간 만큼, 보내지 못한 재고가 쌓여간 것입니다.

대책 역시 여기서도 시스템화였습니다.

• 주간 단위로 확인하는 지표를 「시장 접촉 수/주」 하나로 고정한다 (내부 완성도 점수는 진척 지표로 삼지 않는다)
• 세션 시작 시 접촉 수를 자동으로 주입한다:
  [market-first] 최근 7일간의 시장 접촉: 6건 | 최종 접촉: 4일 전
• 주의 첫 작업 시간 30분은 전송 큐(Send Queue)의 최상단부터 처리한다. 도구 연마는 그 이후에 한다.

AI 활용에 관한 기사들은 「얼마나 많이 만들 수 있게 되었는가」를 이야기하는 경향이 있지만, 개인의 실무에서는 **「만든 것을 외부로 내보내는 인간 측의 행동」이 새로운 병목 (Bottleneck)**이 됩니다. 이 점을 깨달은 것 자체가 Claude Code를 업무 기반으로 삼아 얻은 가장 큰 배움일지도 모릅니다.

관통하는 설계 원칙

4가지 사례에 공통되는 원칙을 추출하면 다음과 같습니다.

• 인간만이 할 수 있는 일만 인간에게 남긴다 — 전송·기입·공개·결정. 그 외에는 위임 후보
• 리마인드는 알림(Notification)이 아니라 세션 주입(Session Injection)으로 — 알림은 무시할 수 있지만, 작업 시작 시 눈앞에 놓인 한 줄은 무시하기 어렵다
• 마찰(Friction)은 비대칭적으로 배치한다 — 바람직한 방향은 마찰 없이, 바람직하지 않은 방향에만 마찰을
• AI는 판단 재료의 정리까지만, 결정은 인간이 — 책임의 소재를 모호하게 하지 않는다

비엔지니어의 시작 방법

「하지만 터미널(Terminal)이잖아요?」라고 생각하시는 분들께. 참고로 Claude Code 본체의 설치와 로그인은 완료되었다는 전제하에 작성합니다 (셋업 자체는 공식 문서의 절차를 따르며, 이 부분이 첫 번째 고비입니다). 그 이후에 제 구성이 사용하고 있는 도구는 사실 다음 두 가지뿐입니다.

• CLAUDE.md: Claude Code가 매번 읽는 지시서. 여기에 자신의 업무 규칙을 일본어(또는 한국어)로 작성한다
• Markdown 대장: 의사결정 큐, 주간 기록, 태스크 표. 전부 단순한 텍스트 파일일 뿐이다

첫걸음으로 추천하는 것은 사례 2의 축소판입니다.

• decisions.md라는 파일을 만들고, 결정되지 않은 사항을 표로 3건 작성한다
• CLAUDE.md에 「세션 시작 시 decisions.md를 읽고, 미결정 건수와 가장 오래된 작성일을 알려줘」라고 적는다
• 매일 아침 Claude Code를 연다

이것만으로도 「결정되지 않은 사항이 매일 아침 눈에 보이는」 상태를 얻을 수 있습니다. 프로그래밍 지식은 필요 없습니다. 제대로 돌아가기 시작하면 주간 리뷰 집계, 태스크 재검토(Inventory) 등으로 위임 범위를 하나씩 넓혀가면 됩니다.

저 스스로도 이 활용 지식을 공유하고 싶어 이 글을 썼습니다. 코드를 쓰지 않는 업무야말로 성장 잠재력이 크게 남아 있습니다. 「엔지니어가 아니니까 상관없다」고 생각하셨던 분들에게 첫걸음이 된다면 기쁘겠습니다.

Discussion