23단계코드를 못 써도 만들 수 있게 됐다
이제 코드를 몰라도 도구를 만들 수 있다. 다만 받은 결과를 판단하는 눈만큼은 내가 가져야 한다.
걸리는 시간 · 읽기 약 10분 · 따라 하기 약 30분 · 난이도 ★☆☆ 기본 · 화면 확인 2026.09.27
이 단계를 마치면
- 이 부에서 쓰는 세 도구(Claude Code, GitHub, 배포 서비스)가 각각 무슨 일을 하는지 설명할 수 있다.
- 첫 도구 후보를 "틀려도 되돌릴 수 있는가, 기밀이 들어가는가"로 걸러 하나만 고를 수 있다.
- 만들 도구를 "누가, 언제, 어떤 화면에서, 무엇을 하려고 쓰는가"가 담긴 한 문장으로 적을 수 있다.
영업팀 막내가 매일 저녁 엑셀 파일 하나를 붙들고 있다. 선배들이 메신저로 보내 준 외근 기록을 옮겨 적는 파일이다. 개발팀에 "방문 기록 받는 화면 하나만 만들어 주세요"라고 요청서를 넣은 지 몇 달이 지났지만 차례는 오지 않는다. 그러다 막내가 다른 부서로 옮기고, 그 파일은 누구의 폴더에 있는지도 모르게 사라진다.
낯익은 이야기일 것이다. 예전에는 사내 도구 하나를 만들려면 개발팀에 요청서를 넣고 차례를 기다려야 했다. 방문 일지 화면, 견적 계산기, 행사 참가 신청 페이지처럼 규모는 작은데 요청하는 쪽은 급하고, 개발팀에는 늘 더 큰 일이 쌓여 있다. 그래서 이런 도구는 엑셀로 버티다가 담당자가 떠나면 함께 사라지곤 했다.
Claude Code가 바로 이 틈을 메운다. 필요한 것을 말로 설명하면 파일을 만들고, 실행해 보고, 오류가 나면 스스로 고친다. 인사팀 박 팀장이 "신입 온보딩 체크리스트를 팀원별로 체크하는 페이지"를 원한다고 해 보자. 예전 같으면 기획서부터 써서 넘겨야 했지만, 이제는 오후 한나절이면 첫 화면을 직접 눈으로 본다.
이 부에서 만나는 도구는 셋이다. 역할부터 나눠 두면 뒤에서 헷갈리지 않는다.
| 도구 | 하는 일 | 비유 | 다루는 단계 |
|---|---|---|---|
| Claude Code | 내 폴더에서 파일을 만들고 고치고 실행한다 | 옆자리에 앉은 개발자 | 24~26단계 |
| GitHub | 파일과 바뀐 기록을 인터넷에 보관한다 | 기록이 남는 보관소 | 28~29단계 |
| 배포 서비스 | 보관소의 파일을 인터넷 주소로 열어 남이 쓰게 한다 | 가게 간판과 출입문 | 30~31단계 |
쉬워진 만큼 새로 생긴 위험도 있다. 코드를 읽지 못하는 사람은 무엇이 잘못됐는지도 모른 채 결과를 받는다. 화면이 떴다고 해서 체크한 내용이 저장되는지, 다른 사람이 열어도 보이는지, 개인정보가 밖으로 새지는 않는지 알 길이 없다. Claude가 "완료했습니다"라고 말하는 것과 도구가 실제로 동작하는 것은 전혀 다른 문제다. 이 간극은 33단계에서 다시 다룬다.
그래서 이 부에서 기르려는 것은 판단하는 눈이다. 거창한 기술은 필요 없고, 몇 가지 습관이면 된다. 원한 동작을 직접 눌러 확인하는 습관, 계획을 읽고 이상한 대목을 되묻는 습관, 틀리면 되돌리는 습관이다. 이 습관이 몸에 배어 있으면 코드를 몰라도 일을 맡길 수 있다. 없으면 코드를 알아도 사고가 난다.
첫 도구를 무엇으로 고르느냐에 이 부 전체의 성패가 달려 있다. 욕심을 내면 설치와 배포를 배우기도 전에 기능과 씨름하다 지친다. 그렇다고 너무 작으면 배포할 이유가 없다. 떠오르는 후보가 있다면 아래 표에 비춰 보자.
| 묻는 것 | 이 부에 맞는 답 | 맞지 않는 답 |
|---|---|---|
| 틀리면 무슨 일이 생기나 | 다시 입력하면 된다 | 돈이 잘못 나가거나 고객에게 잘못 알려진다 |
| 무엇이 들어가나 | 공개돼도 되는 정보, 가공한 연습 자료 | 고객 명단, 급여, 주민번호 |
| 누가 쓰나 | 우리 팀, 휴대폰으로 | 회사 밖 고객 전체 |
| 한 문장으로 말할 수 있나 | "누가 언제 무엇을 하려고 쓴다"가 나온다 | 기능을 나열해야 설명된다 |
같은 도구라도 어떻게 말하느냐에 따라 출발점이 달라진다. "영업팀 관리 시스템"에는 범위가 없다. 어디까지 만들어야 끝나는지 아무도 모른다. 반면 "영업 사원이 외근을 마치고 휴대폰으로 방문처, 만난 사람, 다음 약속을 적는 페이지"에는 누가, 언제, 어떤 화면에서, 무엇을 하는지가 다 들어 있다. 앞으로 내릴 모든 지시가 이 문장에서 출발한다.
끝으로 경계를 정해 두자. 이 부에서 만드는 것은 팀 안에서 쓰는 작은 도구다. 고객 결제, 급여 계산, 회사 핵심 시스템처럼 틀리면 되돌리기 어려운 일은 여전히 전문가에게 맡긴다. 작은 도구로 감을 익혀 두기만 해도 개발팀에 훨씬 정확하게 요청할 수 있다. 그것만으로도 얻는 것이 크다.
흔한 오해와 실제
첫 수업에서 자주 듣는 말이 세 가지 있다. 미리 풀어 두면 뒤에서 덜 헤맨다.
첫째, "코드를 몰라도 되니 아무것도 몰라도 된다." 그렇지 않다. 코드 문법은 몰라도 되지만 내 업무는 알아야 한다. 방문 일지에 어떤 항목이 필요한지, 누가 언제 적는지, 틀리면 누가 곤란해지는지는 Claude가 대신 정해 주지 못한다. 이것을 모르는 사람이 맡기면 그럴듯한 화면이 나오고, 그 화면은 결국 아무도 쓰지 않는 도구로 남는다.
둘째, "이제 개발팀은 필요 없다." 오히려 반대다. 이 부에서 만드는 도구는 팀 안에서 쓰는 작은 도구에서 멈춘다. 회사 시스템과 연결해야 하거나, 많은 사람이 동시에 쓰거나, 고객 정보를 다뤄야 하는 순간 개발팀과 보안 담당자의 판단이 필요해진다. 달라지는 것은 그때 들고 가는 자료다. 말로 된 요청서 대신 실제로 돌아가는 시안과 CLAUDE.md, 직접 겪은 막힘의 목록을 들고 간다. 요청받는 쪽도 훨씬 빨리 알아듣는다.
셋째, "한 번 말하면 완성품이 나온다." 첫 결과는 거의 언제나 초안이다. 이 부의 단계가 계획, 저장, 되돌리기, 검증으로 이어지는 까닭도 여기에 있다. 고쳐 가며 만드는 것이 정상이다. 그 과정을 차곡차곡 기록해 두는 기술을 이 부에서 배운다.
우리 조직에 맞게 고르기
같은 표에 비춰 봐도 부서마다 첫 도구의 모양은 다르다. 인사팀이라면 입사 첫 주 체크리스트처럼 이름 대신 순번만으로도 연습이 되는 것이 좋다. 총무팀에는 회의실이나 비품 대여 현황판처럼 틀려도 다시 적으면 그만인 것이 맞다. 마케팅팀은 행사 참가 신청 페이지를 먼저 떠올리기 쉬운데, 외부 고객이 이름과 연락처를 입력하는 순간 이 부의 범위를 넘어선다. 사내 참석 인원만 모으는 쪽으로 좁히자. 재무팀은 계산기류에 끌리겠지만, 계산이 틀리면 보고까지 틀어진다. 숫자 대신 절차를 확인하는 체크리스트부터 시작하는 편이 안전하다.
직급에 따라서도 다르다. 팀장이라면 직접 만들기보다 팀원 한 명이 만드는 과정을 곁에서 판단해 주는 편이 이 부를 더 잘 활용하는 길일 수 있다. 계획을 읽고 "이건 범위 밖이야"라고 말해 주는 역할이다. 실무자라면 매일 손으로 옮겨 적는 일 하나를 고르면 된다. 매일 쓰는 사람이 만든 도구가 가장 오래 살아남는다.
현장 장면
윤서진 과장이 처음 적은 후보는 거창했다. "영업 관리 시스템." 거래처 목록, 방문 기록, 견적, 매출 목표를 한곳에 모으겠다는 구상이었다. 그런데 표에 비춰 보니 네 줄 모두 오른쪽 답이 나왔다. 거래처 담당자 연락처가 들어가고, 매출 숫자가 틀리면 보고가 틀어지고, 기능을 늘어놓지 않으면 설명조차 되지 않았다.
윤 과장은 범위를 줄였다. 두 번째 문장은 "영업 사원이 외근을 마치고 휴대폰으로 방문 기록을 적는 페이지"였다. 틀리면 다시 적으면 되고, 쓰는 사람은 팀원 몇 명뿐이다. 이번엔 됐다 싶었다. 그런데 동료에게 설명하다가 묘한 일이 생겼다. "방문 기록"에 무엇이 들어가는지 정해 두지 않았더니, 말하는 사이에 거래처 담당자 이름과 전화번호 항목이 슬그머니 끼어든 것이다.
그래서 한 번 더 고쳤다. 연습하는 동안에는 거래처 이름 대신 "업종과 지역"만, 만난 사람은 직함만 적기로 했다. 최종 문장은 이렇다. "영업 사원이 외근을 마친 직후 휴대폰으로 방문 업종·지역, 만난 사람의 직함, 다음 약속을 적는 방문 일지 페이지." 옆자리 동료에게 읽어 주자 되묻는 말 없이 대답이 돌아왔다. "그거면 매일 쓰겠네요." 윤 과장은 이 문장을 메모장 맨 위에 붙여 두었다.
다음 날, 팀장의 반응은 달랐다. "기왕 만드는 김에 이번 달 매출 목표 대비 실적도 같이 보이게 하면 어때?" 솔깃한 제안이었다. 하지만 표에 비춰 보면 매출 숫자가 들어가는 순간 첫째 줄과 둘째 줄이 모두 오른쪽으로 넘어간다. 윤 과장은 거절하지 않았다. 대신 메모장 아래에 "다음에 붙일 것" 목록을 만들어 그 요청을 적고, 이렇게 답했다. "먼저 방문 기록이 매일 쌓이는지 확인하고, 그다음에 실적 연결을 개발팀과 같이 보겠습니다." 팀장은 그 순서에 고개를 끄덕였다.
아직 풀지 못한 문제도 하나 있었다. 적는 사람은 정해졌지만, 모인 기록을 누가 어떻게 볼지는 비어 있었다. 윤 과장은 지금 당장 풀지 않고 "팀장이 한 주에 한 번 모아 본다"고만 적어 두었다. 이 빈 곳은 33단계에서 하루치를 표로 내려받는 기능으로 다시 등장한다.
따라 하기
- 지난 한 달 동안 "이런 도구가 있으면 좋겠다"고 생각한 것을 세 가지 적는다. 성공 기준: 셋 모두 "누가 무엇을 하는 화면"의 형태로 적혀 있다.
- 각각 옆에 틀렸을 때 무슨 일이 생기는지 짧게 적는다. 성공 기준: "다시 입력하면 된다"인 것과 아닌 것이 구분된다.
- 위 표의 네 줄에 비춰 보고, 모두 왼쪽 답이 나오는 것 하나에 동그라미를 친다. 성공 기준: 이 부 내내 만들 도구가 하나로 정해진다.
- 그 도구에 들어갈 정보를 적고, 기밀이나 개인정보가 있으면 가공한 값으로 바꾼다. 성공 기준: 목록에 실명, 연락처, 실제 금액이 없다.
- 도구를 "누가, 언제, 어떤 화면에서, 무엇을 하려고 쓴다"의 한 문장으로 적는다. 성공 기준: 옆 사람에게 읽어 줬을 때 되묻지 않고 알아듣는다.
- (선택) 그 문장 아래에 "이번에는 안 하는 것"을 세 가지 적고, 팀장이나 도구를 쓸 동료에게 함께 보여 준다. 더 붙이자는 제안이 오면 "다음에 붙일 것" 목록으로 옮긴다. 성공 기준: 이번 범위와 다음 범위가 글로 나뉘어 있고, 보여 준 사람이 이번 범위에 동의했다.
막히면 이렇게
| 증상 | 원인 | 처방 |
|---|---|---|
| 후보가 모두 크고 중요해 보인다 | 업무 전체를 한 번에 풀려고 한다 | 그 업무에서 매일 반복되는 입력 한 장면만 떼어 낸다 |
| 윗사람이 기능을 자꾸 더 붙이자고 한다 | 범위가 말로만 정해져 있다 | "다음에 붙일 것" 목록을 만들어 적고, 이번 범위가 쓰이는지 먼저 확인하겠다고 답한다 |
| 한 문장으로 설명이 안 된다 | 쓰는 사람과 쓰는 때가 정해지지 않았다 | "누가, 언제"부터 채우고 기능은 나중에 붙인다 |
| 가공하면 쓸모가 없어 보인다 | 연습과 실제 운영을 섞고 있다 | 지금은 흐름을 익히는 때다. 실제 자료는 검증이 끝난 뒤 옮긴다 |
실습 파일
공개 저장소에 올려 둔 가공 자료와 양식이다. 회사 자료 대신 먼저 이것으로 해 본다.
- 샘플 자료 영업_방문기록.csv · 영업 사원 네 명의 3월 방문 기록 30건
스스로 점검
- ☐ 세 도구 중 "주소를 만들어 주는 것"이 무엇인지 말할 수 있는가
- ☐ 내가 고른 도구가 틀렸을 때 다시 입력하면 되는 수준인가
- ☐ 도구 설명 한 문장에 "누가, 언제, 어떤 화면에서"가 모두 들어 있는가
점검 해설 보기
- 배포 서비스가 보관소의 파일을 인터넷 주소로 열어 남이 쓰게 한다고 설명할 수 있으면 통과다. Claude Code는 내 폴더에서 파일을 만들고, GitHub는 파일과 바뀐 기록을 보관한다는 차이까지 말할 수 있어야 한다. 헷갈리면 세 도구를 비교한 표(도구·하는 일·비유·다루는 단계)를 다시 읽는다.
- 고른 도구 옆에 "틀리면 다시 입력하면 된다"고 적을 수 있고, 들어가는 정보에 실명·연락처·실제 금액이 없으면 통과다. 돈이나 고객 안내가 걸린 후보라면 "묻는 것 / 이 부에 맞는 답" 표에 비춰 매일 반복되는 입력 한 장면만 떼어 낸다. 「따라 하기」 2~4번을 다시 해 본다.
- 옆 사람에게 문장을 읽어 줬을 때 되묻지 않고 알아들으면 통과다. 기능을 늘어놓아야 설명된다면 「막히면 이렇게」대로 "누가, 언제"부터 채우고 기능은 나중에 붙인다. 「현장 장면」에서 윤 과장이 "영업 관리 시스템"을 최종 문장으로 좁혀 가는 과정을 참고한다.
기억할 것
- 첫 도구는 틀려도 되돌릴 수 있고 기밀이 들어가지 않는 것으로 고른다.
- 판단의 근거는 "완료했다"는 말이 아니라 내가 직접 눌러 본 결과다.