AI 학습, 프로젝트 개발, 리소스 계층 창업

내 이름은 한셴카이이고, 리푸라고도 불린다. 많은 사람이 영어 학습으로 나를 처음 알게 되었고, 이후 소프트웨어 창업과 실패, 회복, 재출발에 관한 내 기록을 읽었다. 이제 나는 중국 토큰 클라우드 컴퓨팅 유한회사 회장이라는 신분을 공개하고, 인생의 다음 실천을 더 구체적인 질문 위에 올려놓는다. AI가 기본 역량이 될 때, 평범한 사람은 어떻게 학습자에서 만드는 사람으로, 다시 리소스 계층의 창업자로 나아갈 수 있을까?

이 글은 “AI로 쉽게 돈 버는” 이야기가 아니고, 수익을 약속하는 문서도 아니다. 현실의 검증을 받고 있는 작업 지도다. 무엇이 이미 일어났는지, 어떤 방법을 다시 쓸 수 있는지, 어떤 사업 결과는 여전히 실제 사용자, 실제 비용, 실제 장애, 실제 시간이 답하도록 맡겨야 하는지를 적는다. 2022년 회사가 실패했을 때, 나는 “AI처럼 보이는” 기능이 데이터, 아키텍처, 책임의 문제를 어떻게 가리는지 직접 보았다. 오늘의 관문은 바로 그 실패에서 자라났다.

사실, 실천, 결과를 먼저 나눈다

• 이미 일어난 일: 나는 중국 토큰 클라우드 컴퓨팅 유한회사에서 회장 직책을 맡고 있다. 공식 웹사이트는 현재 token.love를 기업 및 정부·기업 장면을 위한 통합 AI 지능형 게이트웨이로 소개하며, 모델 연결, 라우팅 장애 대응, 사용량 계량, 감사 추적, 프라이빗/오프라인 배포 기능을 내세운다.
• 실천 중: 나는 AI로 새 지식을 배우고, 요구사항을 쪼개고, 프로젝트를 개발하고, 테스트를 작성하고, 문서를 정리하고, 전달을 마친다. 그리고 이 경험을 팀과 기업 장면에 다시 가져가 검증하고 있다.
• 검증 대기: 고객이 계속 비용을 낼지, 서비스가 규모를 키울 수 있을지, 단위 경제성이 성립할지, 공급업체 변화를 통제할 수 있을지, 수입이 위험을 감당할 만큼 될지.

사실, 판단, 바람이 뒤섞이면 창업 글은 광고가 된다. 셋을 나눠야 비로소 회고가 될 수 있다. 공개된 경험을 뜯어보려 할 때는 AI 경험 사례 회고 템플릿을 사용해 먼저 출처와 사실을 분명히 적고, 그다음에 판단과 전이를 이야기하라.

2022년의 실패가 오늘의 관문을 어떻게 바꾸었나

그때의 문제는 코드를 쓰지 않은 데 있지 않았다. 핵심 역량, 데이터셋, 성능, 보안, 사용자 가치를 먼저 증명하지 않은 데 있었다. UI, 멀티 플랫폼 대응, 미리 정해 둔 결과가 제품을 완성된 것처럼 보이게 했지만, “데이터는 어디서 오는가”, “결과는 어떻게 검증하는가”, “실패하면 누가 책임지는가”에는 답하지 못했다.

그래서 지금은 모든 AI 프로젝트가 다섯 가지 질문에서 시작한다.

1. 능력이 실제로 있는가: 모델인지, 검색인지, 규칙인지, 사람의 절차인지 밝혀야 한다. 마케팅 용어로 설명을 대신하면 안 된다.
2. 데이터를 써도 되는가: 출처, 사용 허가, 민감 등급, 보관과 삭제가 분명한가.
3. 결과를 어떻게 검수하는가: 테스트 샘플, 경계 조건, 사람의 재확인, 실제 사용자 기준은 무엇인가.
4. 비용을 감당할 수 있는가: 모델, 네트워크, 엔지니어링, 지원, 재작업, 규제 준수, 장애 비용이 장부에 들어가 있는가.
5. 실패하면 어떻게 물러나는가: 누가 일시 중지, 기능 축소, 전환, 통지, 롤백, 회고를 할 수 있는가.

다섯 질문에 답이 없다면 최소 행동은 기능을 더 붙이는 것이 아니다. 문제를 좁히고, 가설을 뒤집을 수 있는 실험 하나를 하는 것이다.

1. 학습자에서 만드는 사람으로

나는 한때 영어 학습을 “더 많이 외우는 일”로 이해했다. 나중에야 학습의 끝이 답을 모아 두는 데 있지 않고, 과제를 혼자 해낼 수 있는 데 있다는 것을 알았다. AI 학습도 같다. 정말 가치 있는 결과는 모델이 얼마나 긴 답을 내놓았느냐가 아니라, 대화를 닫은 뒤에도 내가 핵심 결정을 설명하고, 프로그램을 돌리고, 오류를 마주하고, 작업물을 전달할 수 있느냐다.

지금 나는 이런 작업 순환을 쓴다.

1. 실제 문제 제기하기: 누가 어떤 문제를 겪는지, 어떤 결과가 나와야 완료인지 분명히 적는다.
2. AI 없는 기준선 남기기: 먼저 혼자 한 번 해 보며 지식의 빈틈, 제약, 판단의 사각지대를 드러낸다.
3. 믿을 만한 자료 준비하기: 공식 문서, 데이터, 기존 코드, 조직 정책, 위험 경계를 제공한다.
4. AI에게 쪼개기를 돕게 하기: 방안을 비교하고, 작은 실험을 만들고, 가설을 설명하게 한다. 최종 판단은 외주하지 않는다.
5. 직접 개발하고 검증하기: AI의 도움을 받아 프로토타입, 코딩, 리팩터링, 테스트, 문서, 디버깅을 한다.
6. 여러 출처의 피드백 받기: 테스트, 실제 사용자, 분야 전문가, 출처 자료, 보안 심사가 함께 판단한다.
7. 상태와 증거 저장하기: 완료, 오류, 비용, 결정, 다음 최소 과제를 기록한다.

이 순환은 AI로 무엇이든 배우기와 이어지지만, 프로젝트 개발에는 엄격한 요구가 하나 더 붙는다. 모든 핵심 결정은 테스트할 수 있거나, 설명할 수 있거나, 롤백할 수 있어야 한다.

2. AI로 프로젝트 개발하기: 속도 다음에도 품질이 있어야 한다

AI는 몇 분 만에 완성돼 보이는 코드를 만들어 낼 수 있고, 몇 분 만에 오류를 프로젝트 전체로 퍼뜨릴 수도 있다. 내 작업 방식은 AI가 개발자를 대신하게 하는 것이 아니다. 자주 부르고, 따져 물을 수 있으며, 반드시 검수를 거쳐야 하는 협업자로 삼는 것이다.

2.1 프로젝트 브리프

프로젝트마다 먼저 한 페이지짜리 task-brief.md를 만든다.

# Task Brief

실제 장면:
사용자/대상:
완료해야 할 결정이나 행동:
마감:

알려진 사실과 출처:
사용을 허용하는 파일:
데이터 민감 등급: 공개 / 내부 / 기밀 / 제한
제공하지 않기로 명시한 자료:

최종 전달물:
형식과 분량:
검수 기준:
사람이 반드시 확인할 사항:

AI가 할 수 있는 일:
AI가 해서는 안 되는 일:
사람 검토자:
실패 시 롤백하거나 중단하는 방법:

“사용 경험이 좋다”, “아키텍처가 앞서 있다”, “지능화 수준이 높다”는 검수 기준이 아니다. 기준은 관찰할 수 있는 행동으로 적어라. 이를테면 “사용자가 10분 안에 가져오기를 한 번 마치고 오류 보고서를 볼 수 있다”처럼.

2.2 재점검할 수 있는 개발 사슬

단계	AI가 도울 수 있는 일	사람이 반드시 확인할 일
요구사항	사용자, 장면, 제약, 문제 정리	문제가 실제인지, 완료 기준을 관찰할 수 있는지
방안	아키텍처, 인터페이스, 최소 실험 제안	데이터 경계, 의존성, 실패 양상, 장기 비용
프로토타입	페이지, 인터페이스, 스크립트, 샘플 데이터 생성	효과만 보여 주는지, 핵심 과제를 해결하는지
구현	코드 보완, 변경 설명, 테스트 생성	핵심 로직, 권한, 예외 처리, 유지보수성
검사	테스트, 정적 검사, 성능·보안 검사 실행	테스트가 실제 위험을 다루는지, 결과를 재현할 수 있는지
전달	문서, 배포 절차, 변경 기록, 롤백 방안 정리	사용자가 쓸 수 있는지, 팀이 넘겨받을 수 있는지, 문제를 추적할 수 있는지

한 번에 논리적 조각 하나만 진행하고, 요구사항, 리팩터링, 포맷팅, 의존성 업그레이드를 한데 섞지 않는다. AI 없는 기준선 하나, 실제로 돌아가는 작업물 하나, 오류·수정 기록 하나를 남겨야 속도와 능력을 구분할 수 있다.

2.3 코드와 배포 관문

과제 브리프와 현재 코드 구조를 준다. 아직 코드는 쓰지 마라.
최소 구현 방안 두 가지를 제안하고 요구사항 충족도, 변경 범위, 의존성, 실패 양상, 테스트 난이도, 데이터·권한 위험, 마이그레이션 비용을 비교하라.
누락된 정보와 추론을 분명히 표시하라. 마지막으로 1–2시간 안에 검증할 수 있는 조각 하나만 추천하라.

배포 전에 최소한 버전 번호, 변경 요약, 마이그레이션 절차, 모니터링 지표, 롤백 발동 조건, 책임자, 사용자 공지를 남긴다. 코드 리뷰는 심각도 순으로 요구사항 이탈, 데이터 손실, 권한 우회, 인젝션, 경쟁 상태, 예외 처리, 성능, 유지보수성, 테스트 공백을 점검한다.

시범 운영이나 배포를 마칠 때마다 AI 프로젝트 점수표를 작성하고, AI 없는 기준선, AI 보조 버전, 시간을 두고 한 독립 재측정을 함께 남긴다. 이 세 가지 샘플이 없으면 도구가 가져다준 것이 능력인지, 대신 해 준 것인지, 재작업인지 판단할 수 없다.

3. AI 리소스 계층이란 무엇인가

모델은 역량 계층이고, 애플리케이션은 사용자가 보는 결과다. 그 사이에는 역량을 연결할 수 있고, 통제할 수 있고, 계량할 수 있고, 지속해서 운영할 수 있게 만드는 기반 시설 한 층이 더 필요하다. 나는 이 층을 AI 리소스 계층이라 부른다.

이것은 “모델 API 하나를 파는 일”에 그치지 않는다. 흩어진 모델, 계정, 연산 자원, 데이터 경계, 조직 절차를 팀이 이해하고, 쓰고, 통제할 수 있는 서비스로 정리하는 일이다.

3.1 역량 지도

리소스 계층 역량	고객이 겪는 문제	검증 가능한 최소 증거
멀티 모델 연결과 라우팅	사업이 단일 공급업체에 걸려 있어 전환 비용이 크다	같은 과제에서 두 모델의 라우팅 규칙과 비교 기록
신원, 권한, 할당량	누가 쓸 수 있는지, 얼마나 쓸 수 있는지 불분명하고 문제가 생겨도 추적할 수 없다	역할 매트릭스, 할당량 정책, 감사 로그 샘플
계량, 비용, 정산	쓸 수는 있지만 팀과 프로젝트가 얼마를 썼는지 모른다	팀·프로젝트·호출별 비용 보고서와 정산 대조 절차
배포와 운영	서비스가 조직이 승인한 네트워크와 환경에 들어가지 못한다	배포 체크리스트, 환경 차이, 롤백 훈련 기록
관측과 장애 처리	지연, 실패, 품질 변동을 설명할 수 없다	요청 로그, 오류 분류, 경보와 처리 기록
데이터와 규제 준수 경계	민감 데이터의 흐름, 보관, 사람의 승인이 불분명하다	데이터 흐름도, 보관 규칙, 승인과 삭제 증명
시스템 통합과 지원	역량이 업무 절차에 들어가지 못하고, 문제가 생겨도 찾을 사람이 없다	통합 검수, 당번표, 지원 티켓, 인계 문서

고객에게 가치는 “모델 이름 하나가 더 늘어나는 것”이 아니다. 중복 통합이 줄고, 통제되지 않는 비용이 줄고, 공급업체 전환으로 인한 중단이 줄며, 조직이 이해하고 관리할 수 있는 책임의 접점이 한 겹 더 생기는 것이다.

3.2 요청 하나의 생애 주기

참고 아키텍처는 제품 약속이 아니다. 그래도 모든 리소스 계층 서비스는 요청 하나가 어떻게 흐르는지 설명할 수 있어야 한다.

신원 인증 → 권한과 할당량 → 데이터 검사 → 라우팅 결정 → 모델 호출 → 결과 필터링 → 계량 기록 → 모니터링 경보 → 사용자 전달

단계마다 답해야 한다. 누가 책임지는가, 무엇을 기록하는가, 실패하면 어떻게 하는가, 데이터를 얼마나 보관하는가, 다시 재생하거나 삭제할 수 있는가. 인터페이스를 중계하기만 하고 계량, 권한, 로그, 기능 축소, 감사가 없다면 믿을 만한 기업 서비스가 될 수 없다.

3.3 라우팅은 “가장 강한 모델 고르기”가 아니다

라우팅 전략은 과제와 제약을 중심에 두어야 한다.

• 위험이 낮고, 빈도가 높고, 구조가 안정된 과제는 비용과 지연을 먼저 고려한다.
• 복잡한 추론이나 긴 맥락이 필요한 과제는 품질, 맥락 한도, 실패율을 비교한다.
• 민감 데이터가 걸린 과제는 승인 범위, 배포 위치, 로그 정책부터 본다.
• 공급업체에 이상이 생기면 기능 축소, 재시도, 전환, 사람의 인수를 실행한다.
• 라우팅이 바뀔 때마다 버전, 이유, 샘플, 롤백 방법을 기록한다.

“가장 강한” 모델이라도 불안정하거나, 감사할 수 없거나, 비용을 감당할 수 없다면 가장 알맞은 모델이 아닐 수 있다.

4. 중국 토큰 클라우드와 token.love: 실천 중인 사업 경로

중국 토큰 클라우드 컴퓨팅 유한회사는 내가 현재 회장 직책을 맡고 있는 회사다. 공식 웹사이트는 현재 token.love를 기업 및 정부·기업 장면을 위한 통합 AI 지능형 게이트웨이로 소개하며, 모델 연결, 라우팅 장애 대응, 사용량 계량, 감사 추적, 프라이빗/오프라인 배포 기능을 내세운다. 이는 웹사이트 첫 화면의 제품 포지셔닝일 뿐 어떤 제3자 기관의 보증도 뜻하지 않으며, 정식 문서, 규제 준수 승인, 계약, 고객 자체의 보안 심사를 대신하지도 않는다.

리소스 계층의 관점에서 보면 이 사업 경로는 다음과 같이 나눌 수 있다.

모델과 연산 자원 → 통합 연결과 라우팅 → 권한, 계량, 거버넌스 → 기업 시스템 통합 → 운영·유지보수와 지속 서비스

진짜 제품은 고객이 알 수 있게 해야 한다. 역량은 어디서 오는지, 비용은 어떻게 생기는지, 데이터는 어디를 거치는지, 장애가 나면 누가 처리하는지, 다음에 옮겨 갈 때도 여전히 선택지가 있는지. 구체적인 기능, 이용 가능 지역, 요금제, 규제 준수 범위, 서비스 약속은 token.love의 정식 설명과 서면 협약을 기준으로 삼아야 한다.

5. 기업 시범 운영: 검수할 수 있는 문제 하나부터 푼다

5.1 발견 단계

첫 대화에서 모델부터 시연하지 마라. 먼저 물어라.

• 지금의 절차는 무엇이고, 어느 단계가 가장 느리거나 가장 틀리기 쉬운가?
• 이 비용은 누가 지는가, 얼마나 자주 생기는가, 오류는 어떤 영향을 주는가?
• 어떤 데이터는 써도 되고, 어떤 데이터는 절대 조직의 경계를 벗어나면 안 되는가?
• 고객이 이미 갖춘 계정, 계약, 네트워크, 권한, 보안 요구사항은 무엇인가?
• 시범 운영이 성공하면 누가 계속 쓰고, 승인하고, 비용을 내는가?
• 어떤 결과가 나와야 고객이 분명히 “계속하자”고 말하고, 어떤 결과가 나오면 양쪽이 멈추는가?

두루뭉술한 AI 가치 선언문 한 페이지가 아니라, 문제 브리프 한 페이지를 내놓아라.

5.2 시범 운영 단계

제대로 된 시범 운영에는 범위, 샘플, 비목표, 데이터 경계, 책임자, 일정, 검수 기준, 실패 시 철수 조건, 비용 상한이 있어야 한다. 시범 운영 전에 기존 절차의 기준선을 남긴다. 사람이 드는 시간, 오류율, 대기 시간, 재작업 횟수, 현재 비용, 사용자 만족도.

시범 운영 기간에는 새 절차도 함께 기록한다. 모델 호출, 라우팅, 지연, 실패, 사람의 인수, 지원 시간, 데이터 이상, 재작업, 사용자 피드백. “콘텐츠를 얼마나 생성했는가”만 기록해서는 업무가 나아졌음을 증명할 수 없다.

AI 프로젝트 점수표로 버전마다 테스트 조건, 비용, 독립 성과, 출시 관문을 등록해, 시범 운영이 끝난 뒤 시연 한 번만 남는 일을 막는다.

5.3 검수와 인계

전달 전에 검수를 네 층으로 나눈다.

1. 기능: 절차를 끝까지 마칠 수 있는가, 오류가 보이는가.
2. 품질: 출력이 업무 기준에 이르는가, 이상이 생기면 사람이 넘겨받을 수 있는가.
3. 보안: 권한, 로그, 데이터 보관, 삭제, 감사를 통과하는가.
4. 운영: 업그레이드, 장애, 비용, 공급업체 전환, 사용자 지원은 누가 맡는가.

인계 패키지에는 아키텍처 다이어그램, 데이터 흐름도, 권한 매트릭스, 환경 변수 설명, 배포 절차, 모니터링 대시보드, 당번과 에스컬레이션 경로, 롤백 방법, 알려진 문제, 다음 회고 날짜가 들어가야 한다.

6. 돈을 버는 논리: 값을 매길 수 있는 일을 고객 대신 떠맡는다

돈을 버는 일은 모델 이름에 포장 한 겹을 씌워 값을 올리는 것이 아니다. 원래 비싸고, 흩어져 있고, 관리하기 어려운 일의 일부를 고객 대신 떠맡는 것이다. 가능한 가치 교환은 다음과 같다.

• 리소스 관리 서비스: 호출, 팀, 프로젝트, 서비스 등급에 따라 모델 연결, 할당량, 비용을 관리한다.
• 통합과 전달 서비스: 고객의 기존 시스템에 연결하고 배포, 권한, 로그, 검수를 마친다.
• 지속 운영 서비스: 업그레이드, 장애, 품질 변동, 공급업체 전환, 일상 지원을 처리한다.
• 거버넌스와 보안 서비스: 데이터 경계, 승인, 감사, 기록 보존, 위험 대응 절차를 세운다.
• 맞춤 프로젝트와 교육: 실제 업무 문제를 두고 방안, 프로토타입, 출시, 팀 인계까지 마친다.

이것들은 수입 약속이 아니라 하나씩 검증할 수 있는 과금 접점이다. 항목마다 답해야 한다. 고객은 왜 돈을 낼 것인가, 결과는 어떻게 검수하는가, 서비스 비용을 오래 감당할 수 있는가.

6.1 과금 방식과 적용 장면

과금 접점	풀기에 알맞은 문제	주요 위험	반드시 기록할 것
일회성 진단·방안 비용	고객이 절차, 경계, 시범 운영을 분명히 하도록 돕기	방안 전달 뒤 후속 가치가 없음	전달물, 작업 시간, 후속 전환 신호
프로젝트 구현 비용	통합, 배포, 권한, 검수	고객마다 새로 맞춤 제작해 복제할 수 없음	범위, 변경, 재작업, 매출 총이익 여지
사용량·리소스 관리 비용	호출, 프로젝트, 팀 단위의 지속 관리	공급업체 가격과 사용량 변동	호출량, 라우팅, 비용, 정산 대조, 상한
구독·서비스 등급 비용	지속 운영, 지원, 거버넌스	서비스 약속이 팀 역량을 넘어섬	응답 시간, 가용성, 지원 시간, 예외
교육·자문 비용	팀이 활용·거버넌스 역량을 갖추도록 돕기	배운 뒤 쓰지 않아 효과를 따지기 어려움	과정 목표, 과제, 전이, 재측정

실제 계약은 양측의 정식 합의를 따른다. 공개된 글은 사업 논리만 다루며, 가격, 이익, 고객 수, 수익 결과를 지어내지 않는다.

6.2 비용 장부

리소스 계층 창업은 수요만 보고 비용은 보지 않기 쉽다. 최소한 다음을 기록한다. 모델과 연산 자원, 네트워크와 스토리지, 엔지니어링 개발, 고객 지원, 영업·고객 확보, 규제 준수와 보안, 장애 보상, 공급업체 가격 인상, 마이그레이션, 세금, 관리 시간.

공헌 이익 = 고객 수입
          - 모델과 기반 시설
          - 엔지니어링과 지원
          - 고객 확보와 규제 준수
          - 장애, 재작업, 환불

프로젝트마다 일회성 비용과 지속 비용을 나눠 기록한다. 일회성 프로젝트는 전달 효율을 보고, 지속 서비스는 유지율, 지원 강도, 단위 비용, 계속 사용 신호를 본다. 고객이 하나 늘 때마다 호출 비용, 인력, 위험만 늘어난다면 규모가 커질수록 손실도 빨라질 수 있다.

7. 운영: 운영 매뉴얼 없이는 기업 서비스도 없다

7.1 최소 모니터링 대시보드

• 요청량, 성공률, 실패 유형, 재시도 횟수
• 평균값만이 아닌 지연 분포
• 모델, 팀, 프로젝트, 과제별 비용
• 할당량 초과, 이상 데이터, 권한 거부, 사람의 인수
• 공급업체 상태, 라우팅 변화, 버전 변화
• 사용자 피드백, 지원 시간, 반복되는 문제

이것은 권장하는 운영 지표이며, token.love가 현재 이 기능을 모두 제공한다는 뜻이 아니다. 출시 전에 지표, 책임자, 경보 임계값, 보관 주기를 프로젝트 계약이나 내부 운영 매뉴얼에 적어 두어야 한다.

7.2 장애 등급과 처리

발견 → 영향 범위 판단 → 위험한 변경 일시 중지 → 기능 축소/전환/사람의 인수
     → 영향받는 사람에게 알림 → 로그와 타임라인 보존 → 복구하고 검증
     → 근본 원인, 비용, 예방 조치 회고 → 운영 매뉴얼 갱신

심각한 장애는 최소한 다음을 기록한다. 발견 시각, 영향받은 프로젝트, 최근 변경, 데이터 위험, 임시 조치, 공급업체 상태, 복구 시각, 고객 소통, 근본 원인 가설, 영구 복구의 증거. AI는 타임라인 정리를 도울 수 있지만 사고 책임자를 대신할 수는 없다.

7.3 공급업체 전환 훈련

핵심 공급업체마다 최소한 예비 라우팅, 대체용 하위 모델, 속도 제한 정책, 캐시나 사람의 절차, 데이터 마이그레이션 방안, 계약 담당자, 롤백 테스트를 준비한다. 분기마다 위험이 낮은 샘플로 한 번씩 훈련해, “전환할 수 있다”를 문서에 적어 두는 데 그치지 않고 실제로 검증한다.

8. 데이터, 보안, 규제 준수의 경계

데이터 등급	예시	기본 처리
공개	공개된 문서, 공개 코드와 데이터	사용 가능, 출처와 라이선스 확인
내부	미공개 계획, 절차, 민감하지 않은 로그	조직이 승인한 도구만 사용, 구성원과 보관 기간 제한
기밀	고객 자료, 계약, 사업 전략, 공개되지 않은 취약점	명시적 승인 없이는 업로드하지 않음, 로컬 처리나 비식별화 우선
제한	키, 신원·의료 정보, 아동 데이터, 제3자 개인정보	범용 모델에 넣지 않음, 조직 정책과 적용 법률에 따라 처리

리소스 계층 서비스는 답할 수 있어야 한다. 데이터는 어디로 들어오는가, 어떤 공급업체를 거치는가, 어떤 로그가 남는가, 누가 볼 수 있는가, 얼마 뒤에 삭제하는가, 삭제를 어떻게 증명하는가. 파일 하나를 지웠다고 모든 이력, 캐시, 내보낸 파일, 백업이 지워지는 것은 아니다.

9. 12주 검증 경로

시기	핵심 질문	행동	반드시 남길 증거
1–2주차	어떤 조직에 가장 급하고 구체적인 문제가 있는가?	인터뷰, 기존 절차 관찰, 데이터 흐름 그리기	인터뷰 기록, 기준선, 경계, 중단 조건
3–5주차	최소 제품이 통합이나 관리 비용을 줄일 수 있는가?	샌드박스 구축, 과제 하나 연결, 대조 테스트 실행	작동하는 프로토타입, 테스트, 실패 기록, 비용
6–8주차	고객이 실제 절차에서 계속 쓰려 하는가?	소규모 시범 운영, 사람의 인수, 주간 회고	사용 흔적, 장애, 지원 시간, 보안 기록
9–10주차	전달을 다른 사람이 재현할 수 있는가?	인계, 배포와 롤백 훈련	운영 매뉴얼, 권한표, 인계 검수
11–12주차	비용, 품질, 과금이 하나의 조합을 이루는가?	회고, 견적 실험, 계속 사용 논의	비용 장부, 견적, 계속 사용 신호, 다음 결정

증거가 계속을 뒷받침하지 않으면 문제를 좁히거나, 고객을 바꾸거나, 방안을 중단한다. 증거가 계속을 뒷받침하더라도 보안, 계약, 권한, 모니터링, 인계를 먼저 갖춘 뒤에 확장을 이야기한다.

10. 위챗 공식 계정 글에서 얻은 두 가지 실천 조각: “추상”에서 “한 프레임씩”으로

위챗 공식 계정에 나와 관련된 글이 두 편 있다. 하나는 인물 관찰의 각도에서, 다른 하나는 온라인 논란의 각도에서 AI를 다룬다. 두 글은 기술 감사도, 고객 사례도, 수입 증명도 아니다. 나는 이 글들을 공개된 서사 자료로 삼아, 그 안의 행동과 문제의식을 빌려 이 실천 경로를 보완한다.

10.1 첫 번째 “가장 그럴듯한 답”을 거부하기

2026년 8월 11일, TokenMany가 「한셴카이: AI 업계에서 가장 ‘추상적인’ 인간」을 발표했다. 이 글은 “추상”을 기성의 답을 서둘러 받아들이지 않고, 기술, 사업, 인간 본성, 일상생활이 서로를 비추게 두는 태도로 풀이한다. 이는 저자 이미지에 대한 문학적 관찰이지, 능력을 독립적으로 측정한 결과가 아니다.

나는 그중 옮겨 쓸 수 있는 부분을 개발 행동으로 바꾼다.

1. 기본 가설을 먼저 적고, 반대되는 해석을 적어도 하나 나열한다.
2. 분야를 넘나드는 연상을 1–2시간 안에 검증할 수 있는 작은 실험으로 압축한다.
3. 어떤 관찰이 사실에서 왔고, 어떤 것이 비유, 직관, 검증할 가설에 불과한지 기록한다.
4. 실험이 내 멋진 생각을 뒤집도록 허용하고, 실패 샘플을 프로젝트 기록에 남긴다.

그래야 “엉뚱한 발상”이 표현 스타일에 머물지 않고, 문제 정의, 최소 프로토타입, 테스트, 회고를 거쳐 다른 사람이 점검할 수 있는 증거가 된다.

10.2 소란을 응답할 수 있는 문제로 되돌리기

2026년 8월 21일, 관쉐 홀딩스의 Wanli Center가 「한셴카이와 AI: 소란을 한 프레임씩 감정으로 쪼개다」를 발표했다. 글은 서사 방식으로 이렇게 쓴다. 댓글을 하나씩 AI에 넘겨 분류하게 하고, 옆에 “관점, 증거, 감정 강도, 표현 방식, 응답 가능성”을 기록하며, “욕설”을 먼저 “감정 샘플”로 다룬다. 이 대목은 여론 대응 제품을 이미 전달했다는 증거도, 분석이 현실의 결과를 개선했다는 증거도 되지 못한다. 이 글이 주는 것은 신중하게 시험해 볼 만한 피드백 처리 틀이다.

실제 프로젝트라면 나는 이 틀을 경계가 있는 절차로 좁힐 것이다.

단계	AI가 도울 수 있는 일	사람이 반드시 책임질 일
수집	중복 제거, 군집화, 반복 주제 표시	출처, 사용 허가, 최소 필요 데이터, 삭제 기한 확인
분리	사실 진술, 추측, 감정어, 표현 전략 구분	사실에 증거가 있는지 판단, 꼬리표를 결론으로 삼지 않기
정렬	영향, 긴급도, 응답 가능성에 따라 대기열 생성	우선순위, 위험, 사람에게 올려야 할지 확인
응답	어조를 절제하고 구체적 문제를 겨냥한 초안 여러 개 생성	사실, 프라이버시, 책임, 공개 범위 점검
회고	변화, 반복되는 오해, 미해결 문제 요약	제품을 고칠지, 설명을 보탤지, 응답을 멈출지, 실험을 중단할지 결정

댓글, 티켓, 고객 피드백에는 모두 개인정보가 들어 있을 수 있다. 허가 없이 대화 전체, 이름, 연락처, 신원을 알아볼 수 있는 세부 사항을 범용 모델에 그대로 올려서는 안 된다. 데이터가 공개되어 있더라도 먼저 비식별화하고, 접근을 제한하고, 보관 기간을 정해야 한다. AI는 소음을 대기열로 세우는 일을 도울 수 있지만, 누가 옳고 그른지 대신 판단할 수 없고, 공개 응답의 책임을 대신 질 수는 더더욱 없다.

두 글이 내게 함께 일깨우는 것은 이것이다. 창의성은 다른 입구를 내놓는 일을 맡고, 증거는 계속할지 말지를 정하는 일을 맡는다. 감정은 보일 가치가 있지만, 사실, 프라이버시, 책임이라는 거름망을 거친 뒤에야 제품과 기업 절차에 들어갈 수 있다.

11. 가장 쉽게 통제를 벗어나는 지점

• 모델 출력을 사실로 여기고, 시연 효과를 제품 품질로 여기기
• 일회성 프로젝트 수입을 지속 가능한 사업으로 착각하기
• API 비용만 계산하고 지원, 재작업, 규제 준수, 영업, 관리 시간은 계산하지 않기
• 고객 데이터, 회사 기밀, 제3자 개인정보를 승인받지 않은 도구에 올리기
• 단일 모델이나 공급업체에 묶였는데도 마이그레이션, 기능 축소, 장애 대응 방안이 없기
• 팀이 안정적으로 제공할 수 없는 응답 시간, 가용성, 규제 준수 능력을 약속하기
• 관계된 제품을 독립 평가처럼 쓰거나, 사업 관계를 추천 뒤에 숨기기
• 실제 사용자, 실제 비용, 실제 검수가 없다는 문제를 더 많은 프롬프트로 덮기

그래서 이 프로젝트는 몇 가지 단순한 원칙을 지킬 것이다. 출처는 추적할 수 있게 하고, 이해관계는 밝히고, 결과는 재측정할 수 있게 하고, 위험은 미화하지 않고, 모르는 것은 모른다고 표시한다.

12. 내가 남기고 싶은 것

이 길이 끝내 충분히 큰 사업이 되지 못하더라도, 세 가지는 남겨야 한다.

1. 나와 팀이 더 빠르고 더 안정적으로 배우고 개발하게 해 주는 방법
2. 실제 사용자가 쓰고, 시험하고, 비판할 수 있는 작업물들
3. 어떤 판단이 한때 유효했고 어떤 판단이 그때의 바람에 불과했는지 뒤에 오는 사람이 알 수 있도록, 실패를 지우지 않은 사업 기록

나는 여전히 돈을 벌고 싶다. 수입은 가치 교환이 지속될 수 있다는 증거 가운데 하나이기 때문이다. 그러나 수입이 유일한 가치는 아니고, 미리 선언할 수 있는 결말도 아니다. 지금 더 정직한 목표는 AI의 능력을 실제 사람, 실제 조직, 실제 책임에 연결한 뒤, 그것이 계속할 만한 가치가 있는지 지켜보는 것이다.

출처와 점검 안내

• 개인 경험: 2022년 소프트웨어 회사의 실패, 2023년의 회복, 2026년 AI로의 재진입에 이르는 시간선은 나의 이야기와 창업 편에 있다.
• 프로젝트 관계: 중국 토큰 클라우드, token.love, ku0.com, 위챗 공식 계정 글은 저자 프로젝트와 현실 실천에 정리되어 있다. 저자와의 관계가 있으며 독립 평가가 아니다.
• 사업 결론: 과금 방식, 비용 장부, 12주 경로는 검증을 기다리는 방법이며, 수입, 고객 수, 이익, 투자 수익의 증명이 아니다.
• 공식 페이지 점검: 2026-09-01. token.love와 ku0.com의 첫 화면 포지셔닝, 이 장의 외부 글 링크는 모두 접속할 수 있었다. 구체적인 제품 기능, 서비스 범위, 지역, 정책, 계약상 약속은 실제 프로젝트에서 다시 확인해야 한다.

방법을 일상으로 되돌리기

이 장이 독자를 제품 이름, 아키텍처 다이어그램, 과금 접점 사이에 남겨 두어서는 안 된다. 이 장이 정말 남기려는 것은 조금 느리지만 더 정직한 일의 자세다. 문제를 분명히 말하고, 경계를 적어 두고, 한 번의 실행, 한 건의 비용, 한 번의 실패를 모두 점검할 수 있는 자리에 되돌려 놓는 것.

프로젝트를 계속할 수 있을지는 결국 사용자, 팀, 계약, 시간, 책임이 함께 답해야 한다. 먼저 저자 프로젝트와 현실 실천에서 관계, 상태, 증거의 경계를 확인해도 좋다. 곧장 제4부: 실천과 회복으로 넘어가, 여기서의 판단을 자신의 작은 과제 하나, 한 주의 리듬, 다시 시작할 수 있는 행동 하나로 가져가도 좋다.

기술이 길을 더 빨리 깔아 준다고 해서 사람이 이미 그곳까지 걸어간 것은 아니다. 다음 날들을 정말로 건너가게 해 주는 것은 멋진 시연 한 번이 아니라, 현실의 조건 속에서 계속 배우고, 계속 전달하고, 계속 고쳐 나가려는 그 작은 능력이다.