2편에서 도구 이야기는 끝났습니다. 이제부터는 생각의 이야기입니다. 이 글은 흐름의 첫 동작 "키운다"를 다룹니다. 구현이 AI의 몫이 된 지금, 결과의 크기는 넘기기 전 머릿속 그림의 크기가 정합니다. 읽고 나면 자기도 모르게 사리는 버릇을 알아채고, 세 가지 질문으로 그림의 해상도를 올릴 수 있습니다. 다음 편 머릿속 그림을 말로 옮긴다에서 그 그림을 문장으로 바꿉니다.
핵심 요약
- 사린 기획에서는 시시한 것밖에 나오지 않습니다. 구현 비용이 낮아진 지금 사릴 이유가 없습니다.
- "있으면 좋겠다"를 죽이는 변명은 세 가지입니다. 기술적으로 될까, 아무도 안 쓸 텐데, 나중에 하자.
- 해상도를 올리는 질문은 누가, 언제, 어떤 기분일 때 쓰는가입니다.
- 그림에는 유통기한이 있습니다. 키운 그림은 그 주 안에 다음 단계로 넘깁니다.
사린 기획에서는 시시한 것밖에 안 나온다
"엑셀 정리만 좀 자동으로 됐으면"에서 출발하면 엑셀 정리기가 나옵니다. 그것도 쓸모는 있지만, 여러분이 진짜 원하는 것은 대개 그 뒤에 있습니다. 정리된 엑셀로 무엇을 하려 했는지, 그 다음에 누구에게 무엇을 보내려 했는지까지 그려야 도구가 업무를 바꿉니다. 예전에는 크게 그리면 견적이 커져서 사리는 것이 합리적이었습니다. 지금은 구현이 문장 몇 개이므로 사리는 것이 손해입니다. 우리 7주차 시연에서 보여 드리는 것이 그 예입니다. 영업 녹음이 들어오면 고객 DB가 갱신되고 사업계획서 초안까지 나오는 흐름은, "녹음을 글로 바꿔 줘"에서 사리지 않고 끝까지 그렸기 때문에 나온 것입니다.
"있으면 좋겠다"를 죽이는 변명 세 가지
머릿속에서 좋은 그림이 떠오르는 순간 바로 따라오는 변명이 있습니다.
- "기술적으로 될지 모르겠다." 될지 안 될지는 여러분이 판단할 일이 아닙니다. Claude Code에게 "이게 가능한지, 가능하다면 어떤 방식이 있는지 먼저 알려 줘"라고 물으면 됩니다. 판단을 AI에게 넘기면 변명이 사라집니다.
- "아무도 안 쓸 텐데." 첫 사용자는 여러분 자신입니다. 내가 매주 쓰는 도구라면 사용자 한 명으로 충분히 가치가 있습니다. 시장성은 나중 문제입니다.
- "나중에 하자." 나중은 오지 않습니다. 그림은 시간이 지나면 흐려지고, 흐려진 그림으로는 넘길 수 없습니다.
세 변명에 공통점이 있습니다. 전부 구현 비용이 비쌌던 시절의 습관이라는 점입니다.
해상도를 올리는 질문 세 가지
그림을 키운다는 것은 막연히 크게 부풀리는 것이 아닙니다. 구체적으로 만드는 것입니다. 세 가지 질문에 답하면 해상도가 올라갑니다.
- 누가 쓰는가. 나 혼자인가, 직원도 쓰는가, 고객이 직접 만지는가. 답에 따라 만드는 것이 완전히 달라집니다.
- 언제 쓰는가. 매일 아침 출근 직후인가, 상담이 끝난 직후 차 안에서인가, 월말 마감 때인가. 시점이 정해지면 입력이 무엇인지도 정해집니다.
- 어떤 기분일 때 쓰는가. 급해서 짜증이 난 상태인가, 차분히 검토하는 상태인가. 급한 상태라면 버튼 하나여야 하고, 검토 상태라면 표가 커도 됩니다.
우리 1주차 교재의 반복 업무 위임 골격이 이 세 질문의 실전판입니다. "나는 정책자금 컨설턴트다. 매주 상담 내용을 보고서로 정리한다. 이 폴더의 상담 메모로 그 일을 해 달라. 결과는 고객명, 상담일, 핵심 쟁점, 다음 액션 표로." 누가, 언제, 어떤 형태인지가 한 문단에 다 들어 있습니다.
실제 사례: 몇 년째 손 못 대던 업체 블로그
원구연의 장인어른이 운영하는 산업 자재 업체에는 블로그가 있었지만 오래 방치돼 있었습니다. 현장 사진은 수백 장이 NAS에 잠들어 있었고, 글을 쓸 사람은 없었습니다. 처음 그림은 "블로그 글 하나 써 주는 도구"였습니다. 사린 그림입니다. 세 질문을 던지자 그림이 커졌습니다. 누가 쓰는가, 글을 쓸 줄 모르는 사람이 확인만 한다. 언제 쓰는가, 매주 정해진 요일 오후에 자동으로 나간다. 어떤 기분인가, 신경 쓰고 싶지 않다. 그래서 만든 것은 글쓰기 도구가 아니라 "NAS 사진을 자산으로 정리하고, 원고를 미리 쌓아 두고, 주 2회 정해진 시간에 발행하는 파이프라인"이었습니다. 첫 글이 실제로 발행됐고, 이후 원고가 스무 건 넘게 대기 상태로 쌓였습니다. 처음 그림대로 만들었다면 글 한 편 쓰고 끝났을 것입니다.
머릿속 그림에는 유통기한이 있다
키운 그림은 오래 두면 상합니다. 일주일 지나면 세부가 흐려지고, 한 달 지나면 "왜 만들려 했지"부터 다시 생각해야 합니다. 그래서 규칙은 하나입니다. 그림을 키운 주 안에 4편의 방법으로 말로 옮기고, 5편의 방법으로 GitHub에 적습니다. 완벽하게 키운 뒤에 옮기려 하지 마십시오. 70퍼센트 그림을 적어 두는 쪽이 100퍼센트 그림을 잊는 쪽보다 낫습니다. 우리 5주차 교재의 "한 번에 만드는 것이 아니라 단계별로 조립한다"는 원칙이 여기에도 적용됩니다.
해 보기
지금 반복하고 있는 업무 하나를 고르고, 종이든 메모 앱이든 상관없이 세 질문에 한 줄씩 답을 적으십시오.
업무:
누가 쓰는가:
언제 쓰는가:
어떤 기분일 때 쓰는가:
그래서 만들고 싶은 것(한 문장):
그다음 Claude Code를 켜고 마지막 줄만 던져 보십시오. 아직 만들지 말고, Shift+Tab으로 plan 모드로 바꾼 뒤 "이게 가능한지, 어떤 방식이 있는지 계획만 세워 줘"라고 하십시오. plan 모드에서는 파일을 고치지 않고 계획만 씁니다. 돌아온 계획을 읽고 "생각보다 크게 그려도 되겠다"는 느낌이 들면 이 편의 목적은 달성된 것입니다.
정리
- 구현 비용이 낮아졌으므로 사리는 것이 손해입니다.
- 세 변명(될까, 안 쓸 텐데, 나중에)은 전부 옛 습관입니다.
- 누가, 언제, 어떤 기분일 때 쓰는가로 해상도를 올립니다.
- 키운 그림은 그 주 안에 말로 옮기고 GitHub에 적습니다.
자주 묻는 질문
기술적으로 가능한지 모르는 아이디어는 어떻게 하나요?
여러분이 판단하지 말고 Claude Code에게 묻습니다. plan 모드로 "가능한지, 가능하다면 어떤 방식이 있는지, 각 방식의 장단점을 알려 줘"라고 하면 파일을 건드리지 않고 답만 줍니다. 안 된다는 답이 와도 대개 "이 부분은 되고 이 부분은 다른 방법"이라는 형태입니다.
아무도 안 쓸 것 같은데 만들어도 되나요?
첫 사용자가 여러분이라면 만들어도 됩니다. 매주 내가 쓰는 도구는 사용자 한 명으로 값어치를 합니다. 우리 수업의 산출물 대부분이 수강생 본인의 업무 도구였고, 그중 일부가 나중에 다른 사람이 쓰는 서비스로 자랐습니다.
그림의 해상도를 올리려면 무엇에 답해야 하나요?
누가 쓰는가, 언제 쓰는가, 어떤 기분일 때 쓰는가입니다. 이 셋에 답하면 입력이 무엇인지, 화면이 얼마나 단순해야 하는지, 결과가 어떤 형태여야 하는지가 따라 나옵니다.
크게 그리면 오히려 할 일이 막막해지지 않나요?
그림을 크게 그리는 것과 한 번에 다 만드는 것은 다릅니다. 그림은 크게, 착수는 작게가 원칙입니다. 큰 그림을 적어 둔 뒤 5편에서 Issue로 잘게 쪼개고, 그중 하나씩 넘깁니다. 막막함은 그림이 커서가 아니라 쪼개지 않아서 생깁니다.
그림을 키운 뒤 얼마나 빨리 다음 단계로 가야 하나요?
같은 주 안입니다. 완벽하지 않아도 4편의 틀로 문장을 만들고 5편의 방법으로 저장소에 적으십시오. 적어 둔 그림은 나중에 키울 수 있지만, 머릿속에만 있는 그림은 잊힙니다.