<클로드 올인원 with 코워크, 코드, 디자인> 프롬프트 잘 쓰는 법이 아니라, 일을 어디에 맡길지 정하는 법
한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.
이 책을 고른 이유
Claude Code는 매일 쓴다. 터미널에 띄워두고 리팩터링을 시키거나 테스트를 짜라고 던지는 게 일상이다. 그런데 클로드 계정으로 할 수 있는 나머지는 거의 안 써봤다. 코워크 탭은 열어본 적도 없고, 커넥터 목록은 승인 화면에서 겁먹고 닫았고, 디자인 탭은 있는 줄도 몰랐다.
문제는 이게 기능을 몰라서가 아니었다. 회의록 요약 하나를 시키려고 할 때 채팅에 붙여넣을지, 프로젝트를 만들어 자료를 모을지, 폴더째로 코드에 맡길지 매번 감으로 골랐다. 골라놓고도 이게 맞나 싶었다. 도구가 늘어난 만큼 판단할 게 늘었는데, 나는 판단 기준 없이 도구만 늘려온 셈이다.
이 책의 부제가 "with 코워크, 코드, 디자인"인데, 정작 저자가 들어가며에서 강조하는 건 기능 목록이 아니라 그 판단 기준이다. 그 지점이 궁금해서 골랐다.
이런 분에게 추천한다
- 클로드를 챗봇으로만 쓰다가 코워크·디자인·커넥터·예약 실행까지 한 번에 정리하고 싶은 사람
- 반복 업무를 줄이고 싶은데 자동화를 어디서부터 끊어야 할지 모르는 실무자
- 팀원(비개발자)에게 AI 도구 쓰는 법을 설명해야 하는 개발자
반대로 코드나 API를 파고드는 책을 기대한다면 이 책은 아니다. 저자가 들어가며에 아예 "이 책의 독자는 개발자가 아니다"라고 못을 박는다. 터미널 명령이나 문법을 외우게 하지 않고, 무엇을 맡기고 어디서 멈춰 확인할지를 반복해서 다룬다. Claude Code를 이미 쓰는 개발자라면 1~2부는 빠르게 넘겨도 된다.
읽어보니
기능 설명서가 아니라 분류 기준표다
첫인상은 "이건 매뉴얼이 아니라 분류법이구나"였다. 1부는 기능을 열지 않고 계속 묻는다. 이 일이 채팅으로 끝날 일인지, 프로젝트에 자료를 모아야 할 일인지, 폴더를 만져야 할 일인지.
44쪽의 네 문단이 이 책 전체의 축이다. 채팅은 결과를 보며 조금씩 고치는 일, 코워크는 중간 화면을 안 봐도 되는 일, 코드는 내 컴퓨터의 실제 파일을 다루는 일, 디자인은 글이 화면 배치로 바뀌어야 하는 일. 읽고 나서 내가 코드 탭에 던져놓고 답답해했던 작업들이 대부분 채팅으로 끝낼 일이었다는 걸 알았다.
중요한 것은 버튼의 위치가 아니라 작업을 나누는 기준입니다. (들어가며, 7쪽)
이 문장이 책 전체의 설계 의도다. 그래서 이 책은 화면이 바뀌어도 오래 쓸 수 있는 부분과 금방 낡을 부분이 뚜렷하게 갈린다.
개발자에게 제일 값어치 있는 곳은 7장 후반과 13장
정작 내가 가장 오래 붙잡은 건 실습 파트가 아니라 두 개의 Special 절이었다.
7.10절의 LLM 위키가 그중 하나다. 자료를 올려놓고 필요할 때마다 다시 질문하는 방식은 검색에 가깝고, 매번 처음부터 다시 요약하게 된다. 대신 새 자료가 들어올 때 기존 문서와 연결하고 충돌하는 부분을 표시해두면, 질문할 때마다 다시 찾을 필요가 없어진다. 폴더를 원천 자료(raw), LLM이 쓰는 위키(wiki), 운영 규칙 세 층으로 쪼개고 index.md와 log.md로 색인과 기록을 남기는 구조인데, 개발자 눈에는 그냥 README 규칙과 CHANGELOG를 지식 저장소에 옮긴 것으로 읽힌다. 익숙한 패턴이라 오히려 바로 따라 만들었다.
13장의 SKILL.md 설계도 비슷한 이유로 좋았다. 스킬 설명문을 기능 자랑이 아니라 호출 조건으로 쓰라는 조언, 그리고 초보자는 처리 기준보다 금지 사항을 먼저 적는 편이 안전하다는 조언(355쪽). "조심하기" 같은 추상적인 문장이 아니라 원문에 없는 수치를 만들지 않는다, 이름이 없으면 빈칸으로 둔다처럼 확인 가능한 문장으로 쓰라고 한다. 사실 이건 우리가 코드 리뷰에서 요구하는 것과 같다. 명세를 검증 가능한 단위로 쪼개라는 이야기.
name과 description은 영문으로 두는 편이 호출 매칭이 안정적이고 본문 지침은 한국어로 써도 된다는 노트(355쪽)처럼, 실제로 만들어본 사람만 알 수 있는 디테일도 중간중간 박혀 있다.
보안 파트가 형식적이지 않다
14장이 예상 밖이었다. 외부 스킬 ZIP을 받았을 때 폴더 구조는 갖췄지만 scripts/install.sh가 설명 없이 들어 있으면 "업로드 가능"이 아니라 "수정 후 테스트"로 판정하고, 그 이유를 스킬이 나빠서가 아니라 설치 스크립트의 역할이 설명되지 않았기 때문이라고 짚는다(376쪽). README는 사람이 읽는 문서고 SKILL.md는 클로드가 읽는 지시문이므로 둘이 어긋나면 그 자체가 위험 신호라는 대조 방법도 나온다.
기능 설명보다 행동 동사(읽는다, 저장한다, 수정한다, 발송한다)를 따로 모아 보라는 검토법은 공급망 점검 관점에서 봐도 말이 된다. AI 활용서에서 이 정도 밀도로 설치 전 검증을 다루는 건 흔치 않다.
만든 도구를 계속 쓰게 만드는 20장
5부는 바이브 코딩으로 작은 업무 도구를 만드는 흐름인데, 정작 인상적인 건 도구를 만드는 19장이 아니라 붙이는 20장이었다.
한 번 만든 도구가 안 쓰이게 되는 이유를 코드 문제가 아니라 주변 문서 부재로 본다. 실행 방법과 입력 조건은 README에, 검수 항목은 CHECKLIST에, 변경 내역은 CHANGELOG에. 그리고 개발팀처럼 거창하게 만들 필요 없이 실행 방법 5줄, 검수 항목 6개, 변경 기록 3줄이면 충분하다고 선을 그어준다. 사내에 스크립트 하나 던져놓고 "이거 쓰세요" 했다가 아무도 안 쓴 경험이 있다면 이 절이 제일 아플 거다.
21장은 웹 게시판에서 매출 데이터를 CSV로 가져와 HTML 대시보드로 만들고, 클로드 디자인으로 다듬고, 전달 전에 숫자와 개인정보를 검토하는 흐름을 하나로 잇는다. 앞의 20장을 다 쓴 종합 실습이라 마지막에 배치한 이유가 납득됐다.
아쉬운 점
화면 스냅샷의 유효기간. 저자도 2026년 6월 기준으로 썼다고 미리 밝혀두지만, 클로드는 그 사이에도 계속 바뀐다. 전작이 나온 지 10주 만에 이 책을 새로 썼다는 서두의 문장 자체가 그 증거다. 컴퓨터 사용이 Pro·Max 리서치 프리뷰라거나 클로드 인 크롬이 크롬 전용이라는 식의 서술은 반년 뒤에 다시 확인해야 한다. 판단 기준은 오래 가고 화면 설명은 금방 낡는 책이라, 후자는 처음부터 스냅샷으로 읽는 편이 낫다.
개발자에게는 앞부분이 느리다. 비개발자를 독자로 잡은 책이니 당연한 트레이드오프다. Claude Code를 쓰고 있다면 12부 상당 부분은 이미 아는 내용이고, 대신 7장 후반·1314장·20장에서 밀도가 확 올라간다. 순서대로 읽지 말고 목차에서 Special 절과 스킬·검증 파트를 먼저 뽑아 읽는 게 효율적이다.
실습이 예제 데이터에 기대 있다. 21.8절이 "여러분의 데이터로 바꿔 보기"로 끝나는데, 내 데이터로 옮기는 순간 생기는 문제(열 이름 불일치, 인코딩, 날짜 형식)는 대부분 독자 몫으로 남는다. 20장의 CHECKLIST 아이디어가 그 공백을 일부 메우긴 하지만, 실패 사례를 한 챕터라도 더 봤으면 좋았겠다.
구성
추천사와 들어가며, 시작하기 전에(설치·로그인)로 시작해 5부 21장, 나가면서와 더 알아보기로 닫는다. 총 540쪽으로 두께가 상당하다.
- 1부 내 일에 맞는 클로드 알아보기 (1~3장): 채팅·코워크·코드·디자인을 언제 쓰는지 구분하고, 개인정보·학습 설정과 회사 자료 사용 범위를 먼저 정한 뒤 첫 요청을 보낸다. 작업 규모에 따라 탭을 바꾸는 기준까지.
- 2부 문서와 자료 다듬기 (4~7장): 초안·공지·메일·회의록·PDF·표 데이터를 다루는 본편. 프로젝트에 자료와 지침을 모으는 법, 아티팩트로 결과물을 분리하는 법, 출처를 1차·2차로 구분하고 사실과 추정을 나누는 검토법. 7장 끝에 LLM 위키가 붙는다.
- 3부 클로드 디자인 알아보기 (8~10장): 카드 한 장짜리 시안에서 시작해 슬라이드·카드뉴스·포스터·인포그래픽까지. 한글 줄바꿈, 접근성, 비율별 검수를 따로 다루는 점이 눈에 띈다.
DESIGN.md로 톤과 규칙을 남겨 다음 작업에 이어 쓰는 방법이 10장 마지막에 있다. - 4부 스킬·커넥터로 반복 업무 줄이기 (11~16장): 플러그인·스킬·커넥터의 차이, 설치 전 권한 화면 확인,
SKILL.md작성과/weekly-review같은 명령 설계, 외부 스킬 검증, 지메일·캘린더·드라이브 연결, 예약 실행. 이 책에서 가장 두꺼운 부다. - 5부 바이브 코딩으로 업무 도구 만들기 (17~21장): 브라우저·파일 작업을 읽기 전용으로 시작하고, 요청서를 먼저 쓰고, 작은 도구를 만들고, 세 문서로 루틴에 붙이고, 마지막에 매출 대시보드로 전부 엮는다.
총평
나가면서에 이 책의 결론이 다섯 줄로 정리돼 있다. 새로운 기능이 나와도 먼저 물어볼 건 크게 달라지지 않는다면서, 무엇을 읽고 무엇을 만들고 무엇을 바꾸고 어디로 보내는지, 그리고 그냥 맡겨도 되는지를 확인하라고 한다. 이 다섯 개가 손에 붙으면 화면이 바뀌어도 덜 낯설다는 것.
읽고 나서 실제로 바꾼 건 두 가지다. 하나는 사내 문서를 모아둔 폴더를 원천 자료와 정리된 위키로 쪼개고 색인 파일을 하나 만든 것. 다른 하나는 자주 쓰는 지시를 스킬로 옮길 때 처리 순서보다 금지 사항을 먼저 적기 시작한 것. 둘 다 이 책에서 새로 배운 개념은 아니다. 개발자라면 이미 README와 린트 규칙으로 하고 있는 일이다. 다만 그걸 코드 저장소 바깥, 회의록과 보고서와 슬라이드에도 적용하라는 발상은 이 책에서 처음 만났다.
500쪽이 넘는 책인데 정작 요구하는 건 크지 않다. 거창한 자동화 프로젝트를 세우지 말고 매주 쓰는 보고서나 매일 확인하는 메일 중에 하나만 골라 가장 작은 단위로 줄이라고 한다. 도구가 계속 늘어나는 시기에, 기능을 더 배우라는 책보다 이 일을 어디에 맡길지 정하는 법을 다루는 책이 더 오래 남을 것 같다.
#한빛미디어 #나는리뷰어다 #클로드올인원