책에 포함된 노트클로드 코드 솔로 빌더: 혼자 만들고 운영하는 AI 제품 개발 시스템

21장. AI와 일하는 사람이 진짜 잘 하는 것

2026-04-25Views 45약 8분생성형 AI 활용

AI 시대에 개발자의 경쟁력은 더 이상 "얼마나 빨리 타이핑하느냐"로만 결정되지 않는다. 이제 더 중요한 것은 무엇을 만들지 선명하게 정하고, 어디까지 위임할지 판단하고, 나온 결과를 냉정하게 검토하는 힘이다. 특히 솔로 빌더에게 이 변화는 아주 크다. 원래 혼자서는 기획자, 개발자, QA, 운영자, 문서 작성자까지 다 해야 했다. 그런데 이제 AI가 손발이 되어주기 시작하면서, 진짜 병목은 손이 아니라 머리로 옮겨갔다.

예전에는 혼자 만드는 사람이 가장 부족한 자원이 시간이었다. 지금은 조금 다르다. 시간 부족은 여전히 문제지만, 그보다 더 자주 발목을 잡는 것은 애매한 지시, 불명확한 완료 기준, 그리고 너무 번듯해서 의심하지 않게 되는 AI 산출물이다. 이 장은 그 함정을 피하기 위한 사고법을 다룬다. 한마디로 말하면, 코드를 잘 치는 사람에서 결과를 잘 설계하는 사람으로 이동하는 법이다.

[7부] 솔로 빌더의 마인드셋

손이 아니라 머리가 레버리지가 되는 시대

AI를 쓰기 전의 일은 대체로 이랬다. 내가 직접 조사하고, 내가 직접 설계하고, 내가 직접 구현하고, 내가 직접 고쳤다. 도움을 받더라도 검색이나 자동완성 정도였다. 하지만 에이전트 도구가 들어오면 흐름이 바뀐다. 이제는 내가 모든 일을 직접 하는 대신, 일을 정의하고 나누고 검수하는 사람이 된다. 이 변화는 단순한 생산성 향상이 아니라 역할 변화에 가깝다. 여러 실전 사례에서도 성과가 커진 사람들은 AI를 "질문에 답해주는 도구"가 아니라 "명확한 산출물을 받아야 하는 작업자"로 다뤘다.¹²

솔로 빌더에게 이건 아주 좋은 소식이다. 사람을 채용하지 않고도 팀장처럼 일할 수 있기 때문이다. 물론 반대급부도 있다. 팀장처럼 일하려면 팀장처럼 생각해야 한다. 막연하게 "이거 좀 만들어줘"라고 말하는 습관으로는 생각보다 멀리 못 간다.

21.1 Outcome Engineering - 코드가 아니라 결과를 짜는 일

프롬프트를 잘 쓴다는 말은 많이 들었다. 하지만 솔로 빌더에게 더 중요한 것은 프롬프트 미사여구가 아니라 결과 설계다. 나는 이걸 Outcome Engineering이라고 부르고 싶다. AI에게 무엇을 하라고 말하는 것이 아니라, 어떤 결과가 나와야 성공인지 먼저 정하는 방식이다.

좋은 결과 설계는 대개 다섯 가지를 포함한다.

누가 이 결과를 쓰는가
결과가 바꿔야 할 행동이나 상태는 무엇인가
완료되었다고 말할 기준은 무엇인가
지켜야 할 제약은 무엇인가
어떻게 검증할 것인가

실무에서는 이것만 알아도 지시의 품질이 확 달라진다. 예를 들어 "온보딩 개선해줘"는 일처럼 보이지만 사실은 소원에 가깝다. 반면 "첫 방문 사용자가 3분 안에 계정을 만들고 첫 프로젝트를 생성하도록 온보딩을 바꾸자. 이탈률을 낮추는 것이 목표이고, 모바일 화면도 깨지면 안 되며, 기존 결제 플로우는 건드리지 말자. 완료 기준은 가입부터 첫 프로젝트 생성까지 실제 클릭 경로가 동작하고, 주요 화면에 대한 E2E 테스트가 통과하는 것이다"는 결과다.

AI 기능을 제품에 넣을 때도 마찬가지다. 먼저 사용자, 행동, 핵심 성공 지표를 하나로 좁혀야 한다. "AI를 넣자"가 아니라 "누가 무엇을 더 빨리 혹은 더 정확하게 하게 만들 것인가"를 정해야 한다. 실전 가이드들도 먼저 사용자 문제와 단일 성공 지표를 정의하고, 그다음에 모델과 구현을 선택하라고 강조한다.³

솔로 빌더가 특히 챙겨야 할 것은 완료 정의다. Definition of Done, 즉 "어디까지 되면 끝인가"를 먼저 적어두는 습관이다. 여기에 수용 기준, 즉 acceptance criteria까지 붙이면 더 좋다. 예를 들어 회원가입 기능이라면 "중복 이메일 거절, 비밀번호 해시 처리, 에러 메시지 통일, 테스트 통과, 모바일 폼 검증 동작"처럼 체크 가능한 문장으로 바꿔야 한다. 그러면 AI는 덜 헤매고, 나도 덜 화난다.¹

결국 Outcome Engineering은 거창한 이론이 아니다. 일을 시작하기 전에 결과물을 먼저 보는 습관이다. 요리를 하기도 전에 접시에 무엇이 올라갈지 정하는 셈이다. 레시피보다 플레이팅을 먼저 상상하라는 말이 아니라, 먹을 수 있는 요리가 무엇인지부터 확정하자는 뜻이다.

21.2 위임의 깊이 - 0%부터 100%까지의 스펙트럼

많은 사람이 AI 위임을 흑백으로 생각한다. "내가 직접 한다" 아니면 "AI에게 다 맡긴다"는 식이다. 실제로는 그 사이에 넓은 회색 지대가 있다. 잘하는 솔로 빌더는 이 스펙트럼을 다룬다. 매번 100% 자동화로 가는 사람도 위험하고, 끝까지 10%만 맡기는 사람도 레버리지를 놓친다.

AI와 함께 일하는 방식을 굳이 숫자로 나누면 대략 이렇다.

0% 위임: 내가 직접 구현하고 AI는 검색, 설명, 자동완성만 돕는다.
25% 위임: 내가 설계하고 AI가 초안, 테스트, 문서 같은 주변부를 맡는다.
50% 위임: 기능 단위의 구현을 통째로 맡기고 나는 요구사항과 검수에 집중한다.
75% 위임: 조사, 설계 초안, 구현, 1차 리뷰까지 AI가 처리하고 나는 의사결정과 예외 처리에 집중한다.
100% 위임: 고위험이 아닌 영역에서 목표와 제약만 주고 에이전트가 실행하며, 나는 체크포인트만 본다.

여기서 중요한 것은 용기가 아니라 판단이다. 결제 로직, 데이터 삭제, 보안 정책처럼 실패 비용이 큰 일은 위임 깊이를 얕게 가져가야 한다. 반대로 문서화, 테스트 초안, 운영 스크립트 정리, 리팩터링 후보 조사처럼 되돌리기 쉬운 일은 깊게 위임해도 된다.

좋은 위임은 늘 세 문장으로 시작한다. 첫째, 무엇을 만들어야 하는가. 둘째, 무엇이 끝난 상태인가. 셋째, 무엇은 절대 하면 안 되는가. 이 세 문장이 빠지면 AI는 성실하게 딴길로 간다. 그래서 요즘 생산성이 크게 오른 사람들은 "어떻게 내가 이걸 하지?"보다 "이 일이 끝났다고 말할 수 있게 나는 무엇을 설명해야 하지?"라고 묻는다.¹

이 지점에서 역할 전환이 일어난다. 나는 더 이상 작업자가 아니라 감독자가 된다. 손으로 만드는 양은 줄어들고, 분해하고 할당하고 검토하는 양은 늘어난다. Claude Code 커뮤니티에서도 이 변화를 operator에서 director로의 이동으로 설명한다. 목표를 정의하고, 병렬로 일을 나누고, 결과를 검증하는 쪽이 생산성의 핵심이라는 뜻이다.²⁴

재미있는 점은, 위임이 깊어질수록 오히려 생각은 더 많이 해야 한다는 것이다. 아무 생각 없이 맡기는 것은 위임이 아니라 방치다. 좋은 위임은 더 선명한 설계를 요구한다.

21.3 Artifact Paradox - 잘 만든 결과물이 비판적 검토를 줄이는 함정

AI 산출물의 무서운 점은 틀린 답도 꽤 그럴듯하게 보인다는 데 있다. 함수 이름도 예쁘고, 파일 구조도 말끔하고, 주석도 친절하다. 심지어 테스트 파일까지 붙어 있으면 사람은 쉽게 안심한다. 이것이 Artifact Paradox다. 결과물이 좋아 보일수록, 우리는 덜 의심하게 된다.

특히 솔로 빌더는 시간이 없기 때문에 이 함정에 더 취약하다. 눈앞에 동작하는 데모가 있으면 그냥 믿고 다음 단계로 넘어가고 싶어진다. 하지만 보기 좋은 산출물과 믿을 수 있는 산출물은 다르다. "블라인드 바이브 코딩"이 위험한 이유도 여기에 있다. 계획을 검토하지 않고, 이해하지 못한 코드를 그냥 받아들이고, 운영에서 잘 되기만을 비는 태도는 초기 속도는 줄 수 있어도 결국 큰 청구서를 남긴다.⁵

그래서 실전에서는 "AI가 얼마나 잘 만들었나"보다 "나는 어디를 의심해야 하나"를 먼저 정하는 편이 낫다. 내가 추천하는 최소 검토 습관은 다섯 가지다.

요구사항 원문과 최종 diff를 나란히 놓고, 빠진 조건이 없는지 확인한다.
AI에게 자기 결과를 반박하게 한다. "이 설계의 약점 세 가지를 찾아줘"라고 물으면 의외로 잘 잡아낸다.
코드 설명이 아니라 증거를 요구한다. 테스트 결과, 로그, 스크린샷, 쿼리 플랜 같은 바깥 증거를 보자.
실패 비용이 큰 부분만은 반드시 사람이 읽는다. 인증, 결제, 권한, 데이터 삭제는 특히 그렇다.
이해가 안 되는 줄은 머지하지 않는다. 지금 모른 척한 한 줄이 나중에 새벽 두 시 알람이 된다.

이 습관은 속도를 늦추기 위한 것이 아니다. 오히려 진짜 속도를 지키기 위한 것이다. 초기 10분을 아끼려다 운영에서 10시간을 날리는 일은 솔로 빌더에게 너무 흔하다.

여기서 한 걸음 더 나가면, AI를 리뷰어로도 쓸 수 있다. 같은 모델에게 "만들어"만 시키지 말고, 다른 관점으로 "부숴봐"도 시켜야 한다. 구현자와 리뷰어의 역할을 분리하면, 적어도 한 번은 의심하는 흐름이 생긴다. 잘 만든 결과물의 광택을 벗겨내는 데 이만한 방법이 없다.

21.4 AI Fluency - 반복이 능숙도를 두 배로 만든다

AI Fluency는 프롬프트를 멋지게 쓰는 재주가 아니다. 일을 AI가 처리할 수 있는 단위로 바꾸고, 중간에 수정하고, 실패했을 때 복구하고, 다시 더 좋은 방식으로 맡기는 능력이다. 다시 말해 대화 능력보다 운영 능력에 가깝다.

이 능숙함은 책 몇 권 읽는다고 생기지 않는다. 반복에서 나온다. 오늘 한 번 맡겨보고, 어디서 망했는지 기록하고, 내일 지시를 조금 더 선명하게 바꾸는 식의 루프가 필요하다. 실제 위임 사례에서도 생산성이 크게 오른 사람들은 일과를 "지시-검토-재할당"의 리듬으로 운영했다. 아침에는 작업을 정의하고, 중간에는 산출물을 검토하고, 저녁에는 수용하거나 다시 나눴다.¹

이 흐름은 솔로 빌더와 궁합이 좋다. 혼자 일하면 원래도 일의 전후 관계를 스스로 정리해야 한다. 여기에 AI가 들어오면 하루가 더 구조화된다.

아침: 오늘 필요한 결과를 문장으로 정의한다.
오후: 나온 산출물을 검토하고, 부족한 부분만 다시 위임한다.
저녁: 완료 기준을 통과했는지 확인하고, 배운 점을 규칙이나 템플릿으로 남긴다.

이렇게 쌓인 반복은 결국 나만의 운영 체계를 만든다. 자주 쓰는 지시문은 커맨드가 되고, 반복되는 검수 기준은 체크리스트가 되고, 자꾸 같은 실수가 나오는 부분은 CLAUDE.md나 스킬로 승격된다. 그러면 내 능력은 단지 "AI를 한 번 잘 쓴 경험"이 아니라 "AI가 계속 잘 일하게 만드는 시스템"으로 바뀐다.

Director Mode의 핵심도 같다. 단계를 하나하나 지시하는 대신 목표를 먼저 주고, 가능한 일은 팀처럼 병렬로 처리하게 하고, 마지막에는 결과를 검증하는 것이다.⁴ 이 감각이 생기면 솔로 빌더는 갑자기 여러 명이 된 것처럼 일한다. 정확히 말하면, 여러 명이 된 것이 아니라 여러 명의 일을 조정할 수 있게 된다.