클로드 코드(Claude Code)로 AI 에이전트 가상 오피스를 만들면서 제가 실제로 입력한 프롬프트를 이 글에 순서 그대로 공개합니다. 저는 코드를 쓰지 못하는 마케터이고, 이 프로젝트에서 제가 한 일은 한국어로 원하는 것을 설명한 것이 전부입니다. 첫 질문부터 마지막 다듬기 요청까지, 어떤 문장이 어떤 결과를 만들었는지 따라 할 수 있는 형태로 정리했습니다.
결과물이 궁금하다면 시리즈 1편을, 이 방식의 출발점이 된 조직 구성은 직원 0명 콘텐츠 회사 만드는 법 (1인 AI 회사 EP.1)을 참고하기 바랍니다.
시작은 한 문단짜리 질문이었습니다 — 최초 프롬프트 전문
시작에 앞서 제가 사용 했던 AI 모델을 설명 드리자면, 저는 VS 코드 기반 클로드 코드- Fable 5 모델을 자주 이용하고 있습니다. 물론 이번 7월에 페이블 5 모델이 다시 배포됨에 따라
7/7 까지는 각 클로드 Max 20x 을 쓰고 있는 저는 상당 토큰을 쓸 수 있기도 했고, Fable 5와 함께라면 무엇이든 만들수 있는 엄청난 슈퍼 AI 에이전트의 역량을 맛보았기에 “이걸 할수 있을까?” 같은 그런 어렴풋한 염려, 두려움따위는 없었죠.
자연어 기반 AI , 클로드코드와 바이브 코딩을 오랫동안 해왔기에, Fable5가 다시 배포되었다고 하여서, 당장 나만의 AI 컴퍼니 가상오피스 배경의 작업 UI를 시작해보고 싶었습니다.
프로젝트의 출발점은 기술 사양서가 아니라 질문 하나였습니다. 제가 클로드 코드에 입력한 최초 프롬프트의 전문은 다음과 같습니다.
ATM SNS 폴더 내 에이전트 팀을 회사 환경 3D 시뮬레이션처럼 구성할 수 있어? 각 캐릭터별로 업무범위·권한·역할에 맞게 구분되어 수행되는 시뮬레이션. 과제가 주어지면 유관 캐릭터들이 오피스에서 움직이거나 보고하거나 책상에서 업무하는 게 keypoint. 실행 전 CEO 승인이나 auto 구조. 캐릭터는 미니어처 3D, 머리:몸통 5:5
이 프롬프트에서 눈여겨볼 지점이 세 가지 있습니다. 첫째, 구현 방법을 하나도 지정하지 않았습니다. 어떤 언어로 만들지, 어떤 라이브러리를 쓸지는 전부 클로드 코드가 판단하게 두었습니다. 둘째, 대신 핵심 동작(keypoint)을 명확히 못 박았습니다. 캐릭터가 움직이고, 보고하고, 책상에서 일하는 장면이 반드시 보여야 한다는 요구입니다. 셋째, 결재 구조와 캐릭터 비율(머리와 몸통 5:5)처럼 제가 양보할 수 없는 조건만 구체적으로 적었습니다. 방법은 맡기고 기준은 지정하는 이 배분이 비개발자 프롬프트의 핵심이라고 생각합니다.
한 가지 더, 첫 문장에서 작업 폴더를 지정한 것도 의도적이었습니다. 제 작업 폴더에는 에이전트 17명의 정의 파일이 이미 들어 있습니다. 폴더를 짚어 주자 클로드 코드는 그 파일들을 스스로 읽고 각 에이전트의 역할과 권한, 업무 범위를 파악해 시뮬레이션에 반영했습니다. 제가 조직도를 다시 설명할 필요가 없었던 이유입니다. 이미 가진 자료를 읽게 만드는 것은 설명을 잘하는 것보다 훨씬 강력한 프롬프트 기술입니다.
클로드 코드에 견적부터 물었습니다 — 3D 대신 아이소메트릭
첫 답변을 받고 바로 구현에 들어가지 않았습니다. 3D라는 단어를 제가 먼저 꺼냈지만, 정말 3D가 최선인지 확신이 없었기 때문입니다. 그래서 두 번째로 이런 질문을 던졌습니다.
3D, isometric, 2D 방식 중 토큰·공수·난이도 고려하면 뭐가 쉽고 빠를까?
클로드 코드의 답은 아이소메트릭 2.5D였습니다. 진짜 3D는 엔진 도입과 카메라, 조명 처리 때문에 공수가 크게 늘어나는 반면, 아이소메트릭은 2D 이미지를 비스듬한 시점으로 배치하는 방식이라 3D 느낌을 내면서도 공수가 3D 대비 3분의 1 수준이라는 설명이었습니다. 저는 그 자리에서 아이소메트릭으로 방향을 확정했습니다.
이 단계가 이번 프로젝트에서 가장 중요한 갈림길이었다고 봅니다. AI에게 일을 시킬 때는 만들어 달라는 말보다 선택지를 비교해 달라는 말을 먼저 하는 편이 결과적으로 빠릅니다. 토큰과 공수, 난이도라는 기준을 제가 제시하고 판단 근거를 받은 뒤 결정했기 때문에, 중간에 방식을 뒤엎는 일 없이 끝까지 갈 수 있었습니다.
주목할 점은 질문에 넣은 기준이 전부 비개발자의 언어였다는 것입니다. 프레임워크 이름이나 렌더링 방식 같은 용어를 몰라도, 돈(토큰)과 시간(공수)과 어려움(난이도)이라는 기준은 누구나 제시할 수 있습니다. 기준을 사람이 정하고 판단 재료를 AI가 채우는 이 역할 분담은 이후 모든 의사결정에서 반복해 쓴 패턴입니다.
완성도는 반복 요청에서 나왔습니다 — 개선 프롬프트 실례 4가지
첫 버전은 하루가 되기 전에 나왔지만, 화면은 어색했습니다. 이후 며칠간 제가 한 일은 어색한 지점을 말로 짚어 주는 반복이었습니다. 실제 사용한 개선 프롬프트 네 가지를 그대로 옮깁니다.
캐릭터와 책상·오피스가 이질적이야. 책상에선 앉고, 움직일 땐 서고, 보고 갈 땐 문서 들고 이동하게 해줘. 줌 인/아웃도
첫 버전은 캐릭터가 서 있는 채로 책상 위를 미끄러지듯 지나다녔습니다. 위 요청 한 번으로 앉기, 서기, 문서 들기 세 가지 포즈 체계가 생겼고 마우스 휠 줌까지 붙었습니다. 이때 만들어진 3포즈 구조는 이후 캐릭터 이미지를 51장 생성하는 물량 계획의 기준이 되었는데, 그 제작기는 다음 편에서 다룹니다. 요청 하나가 프로젝트 전체의 에셋 규격을 결정한 셈입니다.
isometric 오피스 배경은 이 이미지 스타일 반영해서 다시 제작해줘
배경이 마음에 들지 않을 때는 말로 길게 설명하는 대신 마음에 드는 레퍼런스 이미지를 첨부하고 이 한 줄을 적었습니다. 스타일을 문장으로 옮기려 애쓰는 것보다 이미지 첨부가 압도적으로 정확했습니다. 따뜻한 느낌, 아기자기한 분위기 같은 형용사는 사람마다 해석이 다르지만 이미지는 해석의 여지가 없기 때문입니다. 디자인 감각이 있는 비개발자라면 이 기법 하나로 결과물 품질을 크게 끌어올릴 수 있습니다. 저는 이후 다른 디자인 작업에서도 형용사 대신 레퍼런스 첨부를 기본 습관으로 삼게 됐습니다.
자리가 부족해 보이는데 자리를 더 그려줘
캐릭터들이 각자 자리에 정확히 매칭하여 앉아 있고 움직이도록 해줘
17명을 앉히다 보니 좌석이 모자랐고, 캐릭터가 자기 자리가 아닌 곳에 앉는 문제도 있었습니다. 두 요청 모두 전문 용어 없이 눈에 보이는 문제를 그대로 말했을 뿐이지만, 클로드 코드는 좌석 배치도를 늘리고 캐릭터와 좌석의 매칭 로직을 고쳐 왔습니다. 어색함을 느끼는 눈만 있으면 고칠 수 있다는 뜻입니다. 개선 요청은 한 번에 하나의 문제만 담는 편이 결과 확인도 빠르고, 어느 요청이 어떤 변화를 만들었는지 추적하기도 쉬웠습니다.
클로드 코드를 쓸 때 지킨 원칙 3가지
프롬프트 자체보다 중요했던 운영 원칙이 세 가지 있습니다.
첫째, 플랜 모드로 설계를 먼저 승인했습니다. 큰 작업은 바로 구현시키지 않고 플랜 모드에서 계획서를 받아 검토한 뒤 승인했습니다. 계획서는 한국어 문장으로 오기 때문에 비개발자도 충분히 읽고 판단할 수 있습니다. 방향이 틀렸을 때 코드가 아니라 계획 단계에서 바로잡는 편이 토큰과 시간 모두 절약됩니다.
둘째, 탐색은 서브에이전트에게 병렬로 맡겼습니다. 폴더 구조 파악이나 기존 에이전트 정의 조사 같은 조사 작업은 서브에이전트 여러 개를 동시에 돌려 처리하게 했습니다. 본 대화의 맥락을 어지럽히지 않으면서 조사 속도가 빨라집니다.
셋째, 만든 AI와 검수하는 AI를 분리했습니다. 디자인 결과물 검수는 별도의 QC 에이전트인 iris에게 맡겼습니다. 자기가 만든 결과물을 스스로 검사하게 하면 관대해지기 쉽기 때문입니다. 생성과 검수의 분리는 사람 조직의 원칙이지만 AI 팀에도 그대로 유효했습니다. 흥미롭게도 이 원칙은 결과물 안에도 그대로 새겨졌습니다. 완성된 가상 오피스의 파이프라인에서 제작 담당들이 만든 결과물이 iris의 QC 톨게이트를 통과해야 발행으로 넘어가는 구조 자체가, 제가 개발 과정에서 쓰던 검수 분리 원칙의 미니어처인 셈입니다.
정리하면 제 요청은 세 층으로 나뉩니다. 방향을 정하는 질문(무엇이 가능한가, 무엇이 나은가), 기준을 못 박는 지시(반드시 보여야 할 장면, 양보 못 할 조건), 어색함을 짚는 피드백(보이는 문제를 보이는 대로)입니다. 이 세 층을 오가는 것이 제가 아는 클로드 코드 활용법의 전부이고, 코드 지식은 그중 어디에도 필요하지 않았습니다.
완성된 전체 코드는 GitHub 저장소 aitrendmaster/atm-office에서 확인할 수 있습니다. 이 글의 프롬프트 흐름과 저장소의 코드를 비교하며 보면, 한국어 요청이 어떤 구현으로 번역되었는지가 보여서 클로드 코드 학습 자료로도 쓸 만할 것입니다.
마치며 — 프롬프트는 사양서가 아니라 대화였습니다
돌아보면 제가 쓴 프롬프트 중 완벽한 사양서는 하나도 없었습니다. 원하는 장면을 말하고, 선택지 비교를 요청하고, 눈에 밟히는 어색한 곳을 하나씩 짚어 주는 대화의 반복이 전부였습니다. 클로드 코드와의 협업에서 비개발자의 무기는 코드 지식이 아니라 무엇이 어색한지 알아보는 눈과 그것을 말로 옮기는 구체성이었습니다.
이전 편 EP.1에서는 이 가상 오피스가 무엇을 하는지 소개했습니다. 다음 편 EP.3에서는 캐릭터 51장을 생성하고 좌석까지 픽셀 단위로 맞춘 에셋 제작기를 공개합니다.
작성자 소개
