Agent-Run Business From Zero: 2. Building Foundation in Hermes, Herdr & ClaudeCode

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Hermes·Herdr·Claude Code로 에이전트 운영 사업의 기반을 결제 준비 단계까지 구축했지만, 실제 서비스 연결과 전체 주문 검증은 남아 있다.

📌 핵심 요점

1. 킵세이크 스레즈는 아기 사진 속 의류 무늬를 현재 입을 옷에 재해석하는 주문형 인쇄 사업이다. AI 코딩 도구로 구축·배포하고 에이전트로 마케팅·유지보수까지 운영하려는 구상이며, 수익성은 아직 검증되지 않았다.
2. 기획용 KT 메인과 구축용 KT 빌더의 역할을 분리하고, 완료 조건이 있는 15개 단계로 구현을 진행했다. 단계마다 완료 내용과 장애물을 보고하게 해 임시 구현이나 임의의 계획 변경을 조기에 확인하도록 했다.
3. 핵심 난관은 사업 규칙과 사진 처리 사실을 저장 경계에서 보장하는 일이었다. 애플리케이션의 주장에 의존하던 구조를 바꾸고, 실제 사실을 확인할 수 있는 구성요소에 입증 권한을 배치했다. 엄격한 입력 형식만으로 실제 검사·저장을 증명할 수 없다는 점이 설계의 핵심이다.
4. 반복적인 코드 읽기와 수정·감사는 개발 시간과 모델 사용량을 늘렸다. 검증 횟수와 실패 시 중단 조건을 정하고, 다른 모델의 검토와 문서 기반 인계를 활용했다. Hermes는 Claude의 해결 경험을 권한 경계 설계 스킬로 축적했다.
5. 사진 수집·삭제 기반은 검증을 통과했고, 이후 생성 후보 관리, 프로젝트 소유권, 상품 시안과 결제 준비까지 구현이 진행됐다. 다만 현재 데모는 임시 데이터와 대체 구현에 의존하며, 실제 Shopify 스토어 연결과 AI 생성 결과 표시 등은 추가 연동이 필요하다.

🧩 배경과 문제 정의

• 킵세이크 스레즈는 오래된 아기 사진 속 의류 무늬를 추출하고 재해석해, 자란 아이에게 맞는 옷에 인쇄하는 쇼피파이 기반 주문형 인쇄 사업이다.
• AI 코딩 도구로 소프트웨어를 구축·배포하고, 에이전트로 마케팅과 유지보수까지 운영하는 것이 목표다. 수익성은 아직 검증되지 않았다.
• 기존 기획 문서를 실제 서비스로 옮기려면 사업 규칙, 데이터 저장, 고객 사진 보호를 먼저 구현해야 한다. 패턴 추출과 소비자용 화면은 이 기반 위에 올라간다.
• 에이전트의 반복 검증과 과도한 보안 강화는 개발 시간과 사용량을 소모한다. 단계별 확인과 다른 모델의 검토를 통해 보안, 단순성, 정상 작동 사이의 균형을 잡아야 한다.

🕒 시간순 섹션별 상세정리

1. 추억의 의류 무늬를 현재의 옷으로 연결하는 사업

• 부모·조부모 등 가족이 아기 사진 속 옷에서 무늬를 추출해, 현재 나이에 맞는 의류에 다시 인쇄하는 서비스를 구상한다. 세 살 아이의 아기 시절 보디슈트 무늬를 후드나 티셔츠로 재해석하는 것이 구체적인 사용 사례다. [00:40]
• 구축과 배포에는 AI 코딩 도구를, 마케팅과 유지보수에는 에이전트를 활용할 계획이다. 주문 발생 이후 매출과 비용을 공개하고, 사업 실패 가능성도 열어 둔다. [02:01]

2. 기획 에이전트와 구축 에이전트의 역할 분리

• 기존 ‘KT 메인’ 프로필에는 앞서 작성한 기획 문서가 쌓여 있다. 주요 업무마다 전용 프로필을 만들어 스킬과 모델을 다르게 구성하는 방향으로 작업을 나눈다. [03:00]
• 새 ‘KT 빌더’ 프로필은 소프트웨어, 랜딩 페이지, 데이터베이스 구축을 맡는다. 기존 킵세이크 스레즈 폴더에 연결해 기획 자료와 구현 작업의 기반을 공유한다. [03:42]

3. 문서 검토를 통한 전문 에이전트 구성

• 구축용 모델에는 프로젝트 디렉터리의 모든 문서를 검토하도록 요청한다. 각 프로필이 업무별 스킬을 축적하면 역할을 전문화하고 작업을 더 체계적으로 관리할 수 있다는 기대가 있다. [05:16]
• 향후 봇 모드의 그룹 기능으로 에이전트끼리 맥락과 보고서를 공유하고, 전문 프로필을 다른 프로젝트에도 재사용할 계획이다. 현재는 프로필을 개별적으로 운용한다. [05:40]

4. 브랜드 이름 확정과 도메인 구매

• ‘킵세이크 스레즈’의 스레즈는 의류뿐 아니라 과거와 현재, 가족 사이의 연결이라는 의미도 담는다. ‘입을 수 있는 추억의 물건’이라는 사업 구상에 맞춰 이름을 선택한다. [07:11]
• 여러 도메인 확장자를 비교한 뒤 킵세이크스레즈닷넷을 구매한다. 킵세이크 스레즈는 임시 코드명에서 공식 사업 이름으로 바뀐다. [08:23]

5. 15개 단계로 나눈 구축과 단계별 확인

• 기존 기획 문서를 바탕으로 완료 조건을 둔 15개 단계의 구축 계획이 완성된다. 각 단계를 순서대로 진행하고, 완료 내용·문제·사람의 조치가 필요한 사항을 짧게 보고하도록 작업 방식을 정한다. [08:49]
• 운영 전환 조건과 외부 의존성을 다루는 0단계를 마친 뒤 1단계로 넘어간다. 단계별 확인은 에이전트가 장애물을 임시 구현으로 덮거나 원래 계획을 임의로 타협하는 일을 조기에 발견하기 위한 장치다. [10:34]

6. 개발 기반 완성과 모델 사용량 부담

• 1단계에서는 포맷팅, 린팅, 타입 검사와 테스트 도구 설정을 진행한다. 여러 실험을 병행한 상태에서 주간 모델 사용량의 약 25%를 첫날에 소모해, 이후 모델을 바꿔야 할 가능성이 생긴다. [11:24]
• 아키텍처와 지속적 통합을 포함한 1단계 작업이 완료된다. 진행 중 발생한 문제는 수정됐으며, 이 단계에서 추가로 필요한 사용자 조치는 없다. [12:27]

7. 외부 플랫폼과 독립적인 사업 규칙 구축

• 2단계는 핵심 사업 개념, 변경 이력, 상태 전이 규칙과 데이터 저장을 다룬다. 쇼피파이 같은 외부 플랫폼에 종속되지 않는 사업 규칙을 코드로 만드는 것이 목적이다. [12:49]
• 이미 합의한 제품 규칙을 도메인 패키지와 식별자 등에 반영한다. 기획 문서를 바탕으로 기초 구조를 먼저 만드는 방식은 준비 작업이 길어지는 대신 구현 방향을 명확히 하는 효과가 기대된다. [13:20]

8. 데이터 저장 단계의 규칙 우회와 보강 지연

• 정상적인 테스트에서는 사업 규칙이 작동하지만, 데이터베이스가 해당 규칙을 건너뛴 레코드를 받아들일 수 있는 문제가 남는다. 애플리케이션 내부 검증만으로는 저장 데이터의 유효성을 보장하기 어렵다. [14:32]
• 커밋 전 한 차례의 집중 보강을 진행하기로 했지만 작업이 수 시간 계속된다. 잘못된 레코드 저장을 막는 작업이 예상보다 길어지면서 모델 사용량도 부족해진다. [15:12]

9. 저장 구조 재설계와 보안·운영성의 균형

• 서로 충돌하는 아키텍처 설계 때문에 한 문제를 고치면 다른 문제가 생기는 반복이 발생한다. 일반적인 테이블 접근 권한 대신, 권한을 좁힌 작업별 데이터베이스 명령을 사용하는 저장 구조로 재설계하기로 한다. [16:02]
• 재설계의 조건은 보안을 유지하면서도 시스템을 최대한 단순하고 작동 가능하게 만드는 것이다. 다른 사이트에서는 보안 강화 후 구독자가 로그아웃되거나 로그인하지 못한 사례가 있어, 과도한 방어가 실제 이용을 막는 위험도 고려한다. [16:40]

10. 반나절 만에 완성한 고객 프로젝트의 데이터 기반

• 2단계 완료까지 반나절이 걸렸다. 여러 하위 에이전트가 테스트 전에 코드베이스 전반을 읽는 불필요한 작업을 반복한 점이 지연 원인 중 하나였으며, 데이터베이스 설정과 마이그레이션도 진행했다. [18:32]
• 완성된 기반은 원본 의류와 사진 제공 여부를 기록하고, 디자인 후보 생성과 검토 상태를 추적한다. 정책상 차단 사유가 있는 디자인은 주문 가능한 상태로 바뀔 수 없도록 규칙을 둔다. [19:31]

11. 소비자용 디자인에 앞선 임시 랜딩 페이지

• 3단계는 공개 랜딩 페이지와 고객 신뢰에 필요한 기반을 만든다. 최종 화면에는 AI로 만든 짧은 광고 영상과 스크롤에 맞춰 프레임이 재생되는 효과를 구상하며, 소비자에게 매력적인 디자인을 별도로 제작할 계획이다. [20:20]
• 우선 서비스의 목적을 설명하는 임시 페이지와 초기 정책 페이지를 만든다. 아직 구현하지 않은 업로드·디자인·결제·주문 이행 기능을 이용 가능한 것처럼 보이게 해서는 안 된다. [21:54]

12. 고객 사진의 안전한 접수와 삭제 기반

• 4단계에서는 고객이 디자인 프로젝트를 시작하고 의류 한 벌의 사진을 안전하게 제공할 수 있는 기반을 만든다. 불필요한 정보 제거, 착용 사진 보호, 임시 저장, 삭제와 삭제 확인이 주요 요구사항이다. [24:03]
• 이 단계의 범위는 원본 사진 접수와 관리까지다. AI 연동과 평가 기반은 5단계, 실제 무늬 추출은 6단계에서 시작하도록 작업을 나눈다. [24:48]

13. 사용량 한도와 끝나지 않는 검증 반복

• 4단계 도중 모델 사용량 한도에 도달해 남아 있던 초기화 기회를 사용한다. 실행 중 한도가 소진된 하위 에이전트들은 중단됐을 가능성이 있어 재시도 상태를 확인해야 한다. [25:15]
• 수정·검증·감사가 반복되며 작업 종료가 지연된다. 새로 복제한 저장소에서 마지막 검증을 한 번만 수행하고, 실패하면 중단한 뒤 장애물을 보고하는 방식으로 반복을 제한한다. [26:06]

14. 다른 모델의 검토와 세션 간 작업 관찰

• 클로드 코드에서 다른 모델로 코드베이스와 프로젝트 상태를 검토하고, 4단계의 장애물에 대한 해결안을 요청한다. 동시에 헤르메스의 KT 빌더 세션을 열어 외부 세션의 작업을 추적하게 한다. [27:17]
• KT 빌더는 클로드 패널의 활동을 관찰하고, 제안된 수정과 실제 저장소 변경에서 교훈을 추출하도록 설정한다. 해결 성과는 아직 확인되지 않았지만, 작업 맥락을 한곳에서 유지하기 위한 모니터링은 활성화된다. [29:10]

15. 증거를 직접 확인하는 구성요소로 권한 이동

• 모든 차단 문제의 공통 원인은 웹 런타임만 증거를 보고, 저장 담당 구성요소는 런타임의 주장만 기록하는 구조다. 각 사실을 입증할 권한을 실제로 그 사실을 확인할 수 있는 구성요소로 옮겨야 한다. [30:00]
• 개별 차단 문제의 수정안과 구현 순서를 마련한 뒤 수정 작업에 착수한다. 해결의 기준은 런타임의 주장을 신뢰하는 구조 자체를 바꾸는 것이다. [30:19]

16. 해결 경험을 스킬과 독립된 작업 맥락으로 축적

• Hermes가 Claude 세션에서 배운 내용을 재사용 가능한 권한 경계 설계 스킬에 반영한다. 특정 모델의 문제 해결 경험을 이후 작업에서도 활용할 수 있는 절차로 남기는 방식이다. [31:02]
• 프로필은 모델별로 맥락과 세션을 분리하면서 스킬을 축적하는 단위다. KT builder에는 권한 경계 설계, 프로젝트 문서 검토, 범위를 제한한 검증 등의 스킬이 쌓여 있다. [32:34]

17. 입력 형식 검증보다 실제 처리 증거를 우선하는 설계

• 기존 4단계 구현은 애플리케이션 서비스를 신뢰했지만, 수정안은 독립된 자격 증명을 가진 어떤 구성요소가 사실을 직접 확인했는지부터 따진다. 이에 따라 권한 부여와 처리 증거를 분리하고, 명령 수신함은 실행 의도로만 취급한다. [34:17]
• 엄격한 스키마는 객체 참조나 검사 결과의 형식을 검증할 수 있어도 실제 검사·저장을 입증하지는 못한다. 데이터베이스 경계를 먼저 확립하고 실제 데이터베이스 역할로 위조를 재현하는 테스트와 별도 마이그레이션을 적용한다. [34:53]

18. 수정 완료 후 학습 내용을 보존하고 검증 인계

• Claude의 수정 구현은 약 32분 만에 끝난다. Hermes는 남은 제약과 추가 교훈, 공격 상황을 가정한 검증 항목을 권한 경계 설계 스킬에 반영한다. [36:04]
• 여러 차례 맥락 압축을 거쳤을 것으로 추정되는 기존 세션 대신 더 새로운 데스크톱 세션으로 작업을 넘긴다. 인계받은 에이전트는 수정 결과를 검증한 뒤 프로젝트를 계속 진행한다. [37:00]

19. 사진 처리 기반을 확정하고 AI 연결 전 검증 장치 구축

• 4단계의 안전한 원본 사진 수집·삭제 기반이 검증을 통과한다. 최종 검토에서 발견한 문제 하나도 수정되어, 추가 사용자 조치 없이 다음 단계로 넘어간다. [38:08]
• 5단계는 평가 하네스와 AI·주문형 인쇄 어댑터의 인터페이스 계약을 구축한다. 실제 AI나 Printful API를 연결하기 전에 안전성과 테스트 가능성을 확보하며, 해당 구현도 완료된다. [38:38]

20. 원본 삭제 이후의 재생성을 위한 추출 구조와 사용량 부담

• 6단계의 목표는 원본 사진에서 필요한 최소한의 근거를 추출해 영속적이고 변경 불가능한 추출 리비전으로 남기는 것이다. 원본 사진을 삭제한 뒤에도 디자인을 재생성할 수 있어야 하며, 타입이 정해진 구성요소 추출과 프로젝트 소유자 확인이 포함된다. [39:41]
• 기반 구축의 작업량이 커지면서 일상적인 에이전트 작업에도 사용하는 Codex 구독의 사용량이 부담으로 떠오른다. 이번 주 사용이 적었던 Claude 구독으로 다음 작업을 옮길 계획이다. [40:34]

21. 생성 후보·비용 관리 단계와 문서 기반 작업 전환

• 7단계는 생성 작업 조율, 할당량, 비용, 후보 검토를 다룬다. 지속적으로 보존되고 범위가 제한된 생성 세트 안에서 원본에 충실한 후보 하나와 영감을 받아 변형한 후보 0~5개를 제공하는 것이 목표다. [41:32]
• 완료한 작업·현재 상태·다음 단계를 인계 문서로 남기고, Herdr의 Claude Code가 코드베이스와 문서를 검토해 작업을 이어받는다. Hermes는 진행 상황을 관찰하고 학습하면서 이후 재인계를 위한 맥락을 유지한다. [42:00]

22. 생성 기능 완료와 프로젝트 소유권·계정 관리

• 7단계가 검증까지 완료되며, 원본에 충실한 후보 선택과 생성 요청 화면의 프로덕션 구성이 포함된다. 이어지는 8단계는 Shopify 신원 연계, 프로젝트 소유권 확보, 디자인 라이브러리를 다룬다. [43:56]
• 8단계에는 두 키를 교체하는 익명 프로젝트 소유권 확보 흐름, 로그인 계정 흐름, 미확보 프로젝트의 24시간 만료, 디자인 라이브러리와 계정 폐쇄가 포함된다. 이전 단계에서 드러난 누락 두 건도 함께 수정된다. [46:02]

23. 승인된 디자인을 실제 상품 규격에 연결

• 9단계는 상품 기능 레지스트리, 제약 조건이 있는 편집기, 제작 전 시안을 구축한다. 승인된 디자인 후보를 물리적 상품에 적용하는 단계로, Shopify와 Printful 연결이 점차 필요해진다. [46:33]
• 실제 계정 연결 전에는 합성 Printful 테스트 데이터와 결정론적 대체 구현으로 전체 흐름을 실행한다. 소프트웨어 기반을 먼저 검증하고, 운영 준비 시 실제 연동으로 교체할 계획이다. [46:59]

24. 결제 준비까지 확장된 기반과 실제 연동의 한계

• 9단계에 이어 10단계의 결제 준비와 결제 처리 기반도 구현된다. 실제 데이터베이스를 활용한 통합 검증과 애플리케이션·화면 일부도 작업 범위에 포함된다. [47:51]
• 실제 Shopify 스토어와의 연결은 아직 이루어지지 않았다. 임시 구현만 계속 늘리기보다 실제 서비스 연결이 필요한 시점에 도달했으며, 현재 결과는 임시 데이터 기반 데모로 확인할 수 있다. [48:08]

25. 업로드부터 디자인 검토·결제 준비까지의 화면 흐름

• 개발 서버의 업로드 흐름에는 사진 업로드 권한 확인과 캡처 응답 입력이 포함된다. 현재 수집 기능은 임시 구현이며, 사진 업로드 뒤에는 프로젝트와 디자인 라이브러리로 이동한다. [48:38]
• 디자인 후보 화면에서는 승인·대기 상태를 확인하고 스타일을 골라 생성 세트를 요청할 수 있다. 실제 생성 결과를 표시하려면 AI 연결이 필요하다. [49:30]

26. 실제 서비스 연결과 전체 주문 흐름 검증 계획

• 현재 기반은 10단계까지 진행되었으며, 이후에는 Printful 연동과 공유 시안·반품·보장 대상 결함·관리자 기능, 프로덕션 활성화 작업이 남아 있다. 실제 운영에는 각 구성요소의 연결이 필요하다. [50:54]
• 다음 작업은 랜딩 페이지 구축과 시각 자료 제작이며, 이후 Shopify 스토어와 Printful 계정을 설정해 남은 기능을 연결하고 배포를 준비할 계획이다. [51:30]

🧾 결론

• 이번 작업의 성과는 에이전트 운영 사업을 위한 소프트웨어 기반 구축이다. 실제 주문 이행과 수익 창출까지 확인된 상태는 아니다.
• 보안 문제를 해결하려면 검증을 반복하는 것에 더해, 어떤 구성요소가 사실을 직접 확인하고 기록할 권한을 갖는지 명확히 해야 한다.
• 모델과 세션이 바뀌어도 작업을 이어가려면 완료 상태, 다음 단계, 검증 기준을 문서로 남기고 해결 경험을 재사용 가능한 스킬로 보존해야 한다.

📈 투자·시사 포인트

• 사업성 판단에는 실제 주문 이후의 매출과 비용이 필요하다. 구축 진척만으로 수익성이나 에이전트 운영의 경제성을 판단하기 어렵다.
• AI 개발 비용은 코드 작성뿐 아니라 반복 검증, 전체 코드베이스 재독해, 세션 인계에서도 발생한다. 사용량 한도와 검증 범위가 작업 지속 가능성에 영향을 준다.
• 플랫폼과 독립적인 사업 규칙 및 어댑터 계약은 실제 연결 전 흐름을 시험할 기반이 된다. 다만 대체 구현으로 통과한 결과는 실제 Shopify·Printful 연동에서 다시 확인해야 한다.
• 출시 준비를 평가할 다음 근거는 실제 계정 연결, 처음부터 끝까지의 주문 시험, Printful 샘플의 실물 확인이다.

⚠️ 불확실하거나 확인이 필요한 부분

• 실제 Shopify 스토어 연결은 완료되지 않았고, Printful도 합성 테스트 데이터와 대체 구현으로 흐름을 시험했다. 실제 결제와 주문 이행의 정상 작동은 추가 확인이 필요하다.
• 사진 수집·삭제 기반의 검증 통과와 소비자용 업로드 기능의 운영 준비는 구분해야 한다. 시연된 수집 화면은 임시 구현이며, 실제 생성 결과를 표시하려면 AI 연결이 필요하다.
• 첫날 주간 모델 사용량의 약 25%를 소모했다는 수치는 여러 실험을 병행한 상태의 기록이다. 이를 이 사업만의 개발 비용이나 일반적인 사용량으로 해석하기 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 인계 문서에 완료 단계, 임시 구현, 미연결 서비스와 남은 장애물을 구분해 기록한다.
• 실제 데이터베이스 역할로 규칙 우회와 처리 증거 위조를 재현하는 검증 결과를 확인하고, 사진 삭제와 삭제 확인 흐름을 점검한다.
• Shopify 스토어와 Printful 계정을 설정하고, AI·인쇄 서비스의 대체 구현을 실제 연결로 교체해 인터페이스 계약을 확인한다.
• 사진 업로드부터 후보 생성·승인, 상품 시안, 결제와 주문 이행까지 전체 흐름을 직접 시험한다.

❓ 열린 질문

• 실제 AI와 Shopify·Printful을 연결했을 때 대체 구현에서 확인하지 못한 장애물은 무엇인가?
• 원본 사진 삭제 후 보존하는 최소 추출 근거만으로 디자인을 얼마나 충실하게 재생성할 수 있는가?
• 검증 범위를 제한하면서도 사진 보호와 사업 규칙 위반을 충분히 탐지할 수 있는가?