Claude Code를 만든 사람의 인터뷰를 보고 나서 내 프로젝트의 다음 단계를 생각했다. 나는 OpenClaw와 study-clipper, 블로그 작성 도구를 연결해 개인 작업을 줄여 왔다. 혼자서 할 수 있는 범위가 넓어졌다는 느낌은 있지만, 그 경험만으로 사업을 시작할 준비가 끝났다고 말할 수 있을까.
먼저 이름을 바로잡아야 한다. Claude Code의 창작자로 소개된 사람은 Boris Cherny다. 초기 메모에 썼던 Boris Kraft는 잘못된 표기였다. Lenny Rachitsky가 2026년 2월 공개한 에피소드 소개는 Cherny를 Claude Code의 창작자이자 책임자로 소개하며, 코딩 이후의 일과 제품 개발 원칙을 주제로 제시한다. 원래 에피소드 소개
이 소개만으로 그가 MCP와 Skills, 데스크톱 앱까지 혼자 만들었다고 적을 수는 없다. 지금 당장 창업하라는 문장이나 미래의 창업 수를 단정하는 직접 인용도 여기서는 사용하지 않는다. 공개적으로 확인한 내용과 내 생각을 나누어 적으려 한다.
코드를 만들 수 있게 된 뒤에 남는 질문
에피소드 제목의 코딩이 해결된 뒤라는 표현은 앞으로 할 일을 묻는 자극적인 출발점이다. 모든 소프트웨어 문제를 AI가 이미 해결했다는 사실로 읽어서는 안 된다. 내가 만드는 서비스에서는 요구사항의 모호함과 운영 중의 예외가 계속 남는다.
예를 들어 자료를 받아 요약문을 만드는 기능을 구현할 수 있어도, 누구에게 어떤 요약이 필요한지는 별도로 정해야 한다. 읽기 편한 요약과 업무의 결정에 쓸 수 있는 요약은 확인할 항목이 다를 수 있다. 사용자가 원문을 확인해야 하는 상황을 숨기면 편리한 화면을 만들어도 불편을 해결하지 못한다.
나는 구현할 수 있다는 가능성에서 한 단계 더 나아가고 싶다. 입력 자료를 어디서 받고, 무엇을 결과물로 주고, 오류를 누가 알아차리며, 틀렸을 때 어떻게 고칠지를 적는 것이다. 이 문장들이 없으면 개발을 시작한 뒤 매번 다른 목표를 AI에게 전달하게 된다.
인터뷰에서 받은 기대감은 이 질문을 시작하는 계기로 남겨 두겠다. 남의 팀이 어떤 속도로 일한다는 이야기를 내 프로젝트의 일정으로 바로 바꾸지는 않는다. 내가 가진 자료와 검토 시간, 도와줄 사람의 범위는 다르다.
첫 작업은 사용자 문제를 한 문장으로 정하기
나는 도구의 이름을 나열하면 무엇을 만들었는지 설명했다고 느낄 때가 있다. 그러나 사용자는 Claude Code나 OpenClaw가 들어갔다는 사실보다 자신의 어떤 일이 줄어드는지 알고 싶을 수 있다. 제품을 설명할 때는 그 차이를 먼저 적어야 한다.
가상의 문서 비교 서비스를 생각하면, 문서를 AI로 정리해 준다는 설명보다 매주 받은 두 보고서에서 바뀐 수치와 근거 페이지를 확인해 준다는 설명이 범위가 분명하다. 이 예시는 실제 고객의 요청이나 검증한 성과가 아니다. 시작 조건을 좁히는 방법을 보여주려는 것이다.
문장이 정해지면 이번에 하지 않을 것도 함께 적는다. 접근 권한이 없는 보고서를 가져오지 않고, 읽지 못한 표의 값을 추측하지 않으며, 비교표를 전문적 의사결정의 최종 결론처럼 제공하지 않는 식이다. 기능의 수를 늘리는 것보다 이 범위를 합의하는 일이 먼저일 수 있다.
내부용 도구라면 내가 기준을 정할 수 있지만 다른 사람이 쓸 서비스라면 그 사람의 실제 작업을 들어야 한다. 내가 불편했던 과정이 다른 사람에게도 같은 비용을 만드는지는 확인하지 않은 가정이다. 구현을 잘했다고 수요까지 확인한 것은 아니다.
에이전트에게 완료를 판단할 자료 주기
Claude Code 공식 문서는 테스트, 빌드, 화면 비교처럼 에이전트가 확인할 수 있는 기준을 제공하라고 안내한다. 작업이 끝났다는 말만 받기보다 실행 결과를 확인할 수 있게 하자는 내용이다. Claude Code 권장 작업 방식
문서 비교 예제라면 미리 만든 작은 입력과 기대 결과를 사용할 수 있다. 다음 표는 공개 전 확인을 설계하기 위한 예시이며, 특정 모델의 성능 시험 결과가 아니다.
| 입력 상황 | 기대하는 결과 | 실패로 볼 결과 |
|---|---|---|
| 수치가 같은 문서 | 변경 없음과 비교한 항목 표시 | 차이를 만들어 냄 |
| 숫자 하나가 바뀜 | 바뀐 값과 해당 출처 표시 | 전체 문서의 의미 변화로 과장 |
| 표를 읽을 수 없음 | 해당 항목을 미확인으로 표시 | 그럴듯한 숫자로 채움 |
| 자료가 중복됨 | 동일 문서를 중복 비교하지 않음 | 같은 변경을 두 번 집계 |
검사 항목을 통과해도 실제 사용 전체가 검증된 것은 아니다. 다른 형식의 파일이나 긴 문서에서 실패할 수 있다. 내가 확인한 입력 범위와 아직 확인하지 않은 범위를 함께 기록하고, 중요한 결과는 사람이 다시 대조해야 한다.
에이전트가 검사 코드까지 만들었다면 그 코드가 내가 원한 조건을 확인하는지도 읽어야 한다. 실행이 성공했다는 사실만으로 검사 기준이 적절하다고 볼 수는 없다. 기대 결과를 바꾸거나 실패를 무시해서 통과한 것은 아닌지 확인하고, 실행한 명령과 결과를 남기는 편이 낫다.
읽기, 수정, 외부 전송의 권한을 나누기
개인 자동화에서는 내 파일을 읽고 내 노트에 쓰는 흐름이 익숙하다. 하지만 다른 사람의 자료를 다루는 순간 권한의 범위를 새로 정해야 한다. 한 번 연결했으니 그 계정의 모든 자료를 읽어도 된다고 가정하지 않는다.
첫 실행에서는 필요한 자료만 읽게 하고 결과를 별도 초안으로 저장할 수 있다. 원본을 덮어쓰거나 메일을 외부로 보내는 작업은 다른 단계로 둔다. 실패했을 때 어느 상태로 돌아갈지 정하고, 이전 파일을 복원할 수 있는지도 확인해야 한다.
에이전트에게 모든 일을 자율적으로 하라고 말해 두는 방식은 사업의 책임을 정하지 못한다. 사용자가 어떤 작업을 허락했는지, 예상 밖의 입력이 왔을 때 멈출 조건이 무엇인지 명시해야 한다. 저장된 자료에 적힌 문장을 새로운 지시로 취급하지 않도록 작업 지시와 입력 자료를 구분하는 것도 필요하다.
Claude Code의 보안 안내는 권한과 실행 경계, 신뢰할 수 없는 내용의 위험을 다룬다. 도구의 보호 기능이 있다는 사실만으로 내가 구성한 연결이 안전하다고 확정할 수는 없다. 실제 권한과 외부 서비스 연결을 확인해야 한다. 공식 보안 안내
코딩 밖의 작업도 검토가 필요하다
Anthropic은 Cowork를 파일과 도구를 활용해 작업을 수행하는 제품으로 소개한다. 코딩 도구에서 출발한 작업 방식이 문서와 다른 업무로 이어지는 흐름을 생각해 볼 수 있다. 다만 제공 기능과 이용 조건은 바뀔 수 있으므로 현재 제품 안내를 확인해야 한다. Cowork 공식 소개
문서 작업은 코드보다 안전하다고 단정하기 어렵다. 잘못된 숫자가 들어간 보고서나 다른 사람에게 간 이메일도 영향을 남긴다. 검토해야 할 부분이 컴파일 오류처럼 분명하게 드러나지 않을 수도 있다. 그래서 내 서비스가 무엇을 확인했는지 설명하는 방식이 필요하다.
예를 들어 결과물에 사용한 자료의 날짜와 링크를 남기고, 서로 충돌한 항목을 분리해 표시할 수 있다. 독자가 전체 문서를 다시 읽지 않아도 확인할 지점으로 돌아갈 수 있게 만드는 것이다. 이 방식이 검토 시간을 줄이는지는 실제 작업에서 측정해야 한다.
내가 자동화를 만들며 느낀 편리함을 설명할 때도 같은 기준을 적용하고 싶다. URL을 보냈더니 결과가 왔다는 경험 뒤에 내용 확인과 수정이 얼마나 남았는지 적어야 한다. 자동 생성된 파일 수만으로 생산성 향상을 계산하지 않겠다.
시작 전에 감당할 운영을 적기
프로토타입이 돌아간 다음에는 유지보수와 비용이 남는다. 입력이 늘었을 때 모델 사용료가 어떻게 달라지는지, 서비스가 멈췄을 때 내가 언제 확인할 수 있는지, 고객이 수정 요청을 보내면 어떤 범위까지 대응할지를 적어야 한다.
나는 직장과 개인 작업을 함께 하고 있으므로 실시간 대응을 약속하기 어렵다. 응답 시간을 현실적으로 정하지 않은 채 에이전트가 항상 일하니 서비스도 항상 문제없을 것이라고 설명할 수는 없다. 에이전트가 일을 계속하는 것과 사람이 결과를 책임지고 확인하는 것은 다른 운영 조건이다.
실험에 쓸 비용과 시간을 먼저 정하고, 한도를 넘으면 원인을 확인하려 한다. 사용자가 없는데 도구 호출이 늘었다면 서비스 성장으로 볼 수 없다. 반복 오류나 중복 작업으로 비용이 늘고 있을 수도 있다. 어떤 결과를 위해 비용이 발생했는지 연결해 볼 수 있어야 한다.
중단 조건도 제안서에 포함하고 싶다. 입력 자료에 접근할 권한이 없거나, 오류를 검증할 수 없거나, 내가 약속한 기한을 지킬 수 없다면 범위를 줄이거나 시작을 보류해야 한다. 기대감이 크다는 이유로 고객에게 떠넘길 조건은 아니다.
내게 남은 결정은 더 작은 첫 약속이다
이 글을 쓰며 창업에 대한 관심이 사라진 것은 아니다. 오히려 어떤 일을 시작할지 설명하는 문장이 필요해졌다. 내가 익숙한 자동화 중 하나를 고르고, 그 결과를 누가 반복해서 필요로 하는지, 오류를 어떻게 확인할 수 있는지 알아보고 싶다.
첫 고객에게 유료로 제안하는 문제는 개인 자동화를 첫 유료 제안으로 바꾸는 조건에서 따로 정리했다. 여기서의 질문은 그 제안을 기술적으로 책임질 준비가 됐는지다. 사용자의 문제와 운영 범위가 정해져야 에이전트에게도 분명한 작업을 줄 수 있다.
코드를 만드는 속도가 좋아졌다는 체감만으로 지금 당장 창업해야 한다는 결론을 내리지는 않겠다. 나는 먼저 작은 결과물의 완료 조건과 검토 방법을 적으려 한다. 그것을 실제 작업에서 지킬 수 있음을 확인한 뒤 다음 약속을 늘리고 싶다.
참고자료
- Lenny Rachitsky: Head of Claude Code: What happens after coding is solved — Boris Cherny 인터뷰의 공개 에피소드 소개. 유료 전문을 읽은 것으로 간주하거나 확인되지 않은 발언을 직접 인용하지 않았다.
- Claude Code: Best practices — 검증 기준과 구체적인 작업 맥락을 제공하는 공식 안내.
- Claude Code: Security — 권한, 실행 경계, 신뢰할 수 없는 자료에 관한 공식 안내.
- Anthropic: Claude Cowork — 파일과 업무 도구를 활용하는 제품의 현재 공식 소개.