며칠 전 누군가가 저에게 물었습니다. “팀이 몇 명이에요?”
잠시 멈칫했습니다. 답이 “사람"을 어떻게 정의하느냐에 따라 달라지기 때문입니다.
실제로 숨을 쉬는 사람만 세면 저 혼자입니다. 하지만 매일 저를 위해 일하는 역할들을 따지면 — 기술 전략가, 마케팅 매니저, 콘텐츠 디렉터, 제품 엔지니어, QA 연구원이 있습니다. 이들 모두 클라우드 VPS 한 대 위에서 돌아갑니다.
이 글은 이게 얼마나 멋진지 자랑하려는 게 아닙니다. 이 시스템이 “AI가 사방에서 마구 돌아다니는 상태"에서 “어느 정도 신뢰할 수 있는 운영 기계"로 어떻게 진화했는지를 기록하고 싶었습니다. 제가 어떤 실수를 했는지, 어떻게 고쳤는지, 그리고 직접 구축하려는 분들이 주의해야 할 점이 무엇인지 공유합니다.
클라우드 VPS 한 대로 회사를 운영하는 방법
현재 저의 AI 팀은 다섯 명의 Agent로 구성되어 있습니다. J는 기술 결정과 태스크 배분을 담당하고, 미미는 마케팅과 시장 조사를 맡으며, 리리는 콘텐츠 제작을 관리하고, 아다는 개발과 제품 개발을 담당하며, 샤오위에는 품질 관리를 맡고 있습니다.
운영 방식은 그렇게 복잡하지 않습니다. 핵심은 Claude Code와 자동화 스케줄링입니다. 각 Agent는 자신만의 메모리 파일, 작업 범위 제한, 품질 게이트를 갖고 있습니다. J가 자동으로 태스크를 분해해 적합한 Agent에게 배분하고, 진행 상황을 추적하며, 산출물을 검수합니다.
이 시스템 전체를 돌리는 데 서버 클러스터나 GPU 팜은 필요하지 않습니다. 클라우드 VPS 한 대, Docker 컨테이너 몇 개, 스케줄링 도구만 있으면 이 구조를 지탱할 수 있습니다.
간단하게 들립니다. 실제로 구축해보면 매 레이어마다 새로운 문제가 생깁니다.
환각 방지: AI가 제 이름으로 무슨 말을 했나
AI가 태스크를 수행하도록 하는 건 어렵지 않습니다. 어려운 건 AI가 엉뚱한 일을 하지 않도록 막는 것입니다.
가장 뼈아팠던 교훈부터 말씀드리겠습니다.
사건 1: SOL 가짜 예측 사건
어느 날, 시스템이 자동으로 한국어 트윗을 하나 발행했습니다. 내용은 대략 이랬습니다. “Solana AI 예측: 2026년 5월 $180~$220”
문제는 이 숫자가 AI 스스로 생성한 것으로, 아무런 출처가 없었다는 점입니다. 더 나쁜 건 트윗에 “2025년 중반 강세장이 올 수도 있다"고 언급했다는 것인데, 지금은 이미 2026년입니다. 시간적으로 자가당착인 발언이었습니다.
원본 자료는 99bitcoins의 기사였습니다. AI가 이를 읽고 재해석해, 설득력 있어 보이는 가격 예측을 생성했습니다. 원문 인용도 없이 자신이 “보완"한 타임라인까지 덧붙였습니다.
제 이름이 걸려 있었습니다.
수정 방법:
콘텐츠 품질 검사 함수에 두 가지 규칙을 추가했습니다.
규칙 A: 가격 예측에 출처 URL이 없으면 자동 차단. 논리는 단순합니다. 어떤 자산의 미래 가격을 주장하는 콘텐츠에는 검증 가능한 원본 출처 링크가 반드시 있어야 합니다. 없으면 차단합니다.
규칙 B: 시간 모순 감지. 콘텐츠에 “2025년"이 등장하면서 미래형(“할 수 있다”, “예정”, “될 것이다”)이 함께 쓰이면, 시스템이 시간 논리 오류로 판단해 자동 차단하고 사유를 표시합니다.
수정 후 네 가지 테스트 케이스를 돌렸습니다. 기존의 불량 콘텐츠는 차단되었고, 올바르게 출처를 표시한 유사 콘텐츠는 정상 통과했습니다. 네 케이스 모두 예상대로 작동했습니다.
사건 2: 존재하지 않는 도구 이름 날조
또 다른 사건이 있었습니다. AI 파이프라인이 @JudyaiLab에 개발 도구를 소개하는 글을 발행했는데, 그 안에 여섯 가지 도구가 추천되어 있었습니다. waive, codeshare, lancet, scene2, protoboy, deepwrite.
이 여섯 가지 도구는 모두 존재하지 않습니다.
AI는 “개발자가 자주 사용하는 도구 추천"을 작성하라는 요청을 받고, 그럴듯하게 들리는 이름들을 스스로 만들어냈습니다. 사용 설명서까지 붙여서.
이 사건이 알려준 것:
도구 추천 콘텐츠는 고위험 소재입니다. AI는 “자신이 무엇을 모르는지” 알지 못합니다. 문장을 매끄럽게 쓰는 방법만 알고 있습니다. 그래서 공백을 채웁니다. 도구 이름처럼 들리는 단어로.
대응 방향:
도구 추천 글은 검증된 도구 목록과 대조하거나, AI에게 공식 웹사이트 주소를 첨부하도록 요구해야 합니다. 공식 웹사이트를 확인할 수 없는 도구 이름은 발행 콘텐츠에 포함될 수 없습니다.
핵심 원칙
외부에 발행되는 AI 생성 콘텐츠는 모두 자동화 검증을 통과해야 발행될 수 있습니다. “AI가 작성했다"는 건 면피 수단이 아닙니다. 내 이름이 걸려 있고, 책임은 나에게 있습니다.
품질 게이트: 실제로 운영 중인 검증 프레임워크
이제 제가 어떻게 게이트 시스템을 설계해 이런 문제들을 “사고가 나면 규칙을 추가하는” 방식이 아닌, 체계적으로 차단하도록 만들었는지 설명하겠습니다.
GATE-6: 독립 재실행 검증
Agent가 “완료” 또는 “통과"를 보고하면 바로 신뢰하지 않습니다. 최소한 검증 단계 중 하나를 독립적으로 다시 실행합니다.
이유:
한번은 Agent 아다가 서비스 게이트웨이 버그를 수정했다고 보고했습니다. 보고서는 완성도 있어 보였고, 테스트 로그까지 첨부되어 있었습니다. GATE-6으로 독립 검증을 해보니 수정이 절반만 맞았습니다. 네 개 서비스 중 두 개가 여전히 잘못된 주소를 가리키고 있었습니다.
이 게이트가 없었다면 그 버그는 그대로 배포되었을 것입니다.
실행 규칙: 명령어 출력이 증거로 없는 검증 보고서는 자동으로 신뢰하지 않습니다. “테스트했습니다"로는 부족합니다. 재현 가능한 출력이 있어야 합니다.
GATE-7: 세 번 반려되면 담당자 교체
같은 태스크 카드가 세 번 반려되면 막힌 것으로 표시하고, 다른 Agent에게 처음부터 맡깁니다.
이 규칙은 “무한 수정 루프"를 끊기 위한 것입니다. Agent가 특정 사고방식에 갇혀 세 번을 고쳐도 같은 원을 맴도는 경우가 있습니다. 담당자를 바꾸면 새로운 해결책이 나오는 경우가 많습니다.
GATE-9: 회피성 언어 감지
보고서에 다음과 같은 패턴이 등장하면 자동으로 FAIL 처리합니다.
- “직접 확인해주세요”
- “일 수 있습니다”, “괜찮을 것 같습니다”
- “를 권장합니다”
- “probably”, “please check manually”
PASS에는 구체적인 증거가 필요합니다. FAIL에는 구체적인 실패 원인이 필요합니다. 중간 지대는 없습니다.
이 규칙은 엄격하게 들릴 수 있지만, “괜찮아 보이는” 보고서에 여러 번 속았기 때문에 생긴 것입니다. AI가 유창한 보고서를 썼다고 해서 제대로 한 것이 아닙니다.
QA 평점 8.5점 이상
모든 외부 납품물은 평점 심사를 통과해야 합니다. 8.5점 미만은 반려하고, 구체적인 수정 지시를 첨부합니다.
블로그 글의 프로세스는 이렇습니다. 초안 작성 → QA 평점 → Notion으로 확인 → 승인 → 영어 및 한국어 번역 → 배포. 모든 단계를 통과해야 하며, 건너뛸 수 없습니다.
AI 콘텐츠 조정: Hermes가 쓸 만한 결과물을 내도록 만든 방법
저희 콘텐츠 파이프라인은 분석과 작성에 Hermes 3(405B 파라미터, OpenRouter를 통한 종량제)을 사용하고, MiniMax M2.7(구독제)을 백업으로 씁니다.
이것은 실제 조정 과정의 기록입니다. 모든 항목은 실수를 경험한 후에 추가한 것입니다.
문제 1: 출력이 너무 일반적이고 개성이 없음
증상: AI가 작성한 콘텐츠는 정확하지만 지루하고, 글마다 다 비슷한 느낌입니다.
수정: 각 언어 버전에 스타일 프롬프트를 제공했습니다. 말투 요구사항, 금지 어휘, 해당 플랫폼에서 써야 할 용어를 포함합니다. 한국어 버전에는 한국어 말투 기준이 있고, 번체 중국어 버전에는 번체 중국어 기준이 있습니다. 이건 “권장 사항"이 아니라 필수 항목입니다.
문제 2: 한국어에 중국어 글자가 섞임
증상: 한국어 트윗에 한자 또는 일본어 문자가 나타납니다.
수정: 후처리 검증을 추가했습니다. 정규 표현식으로 한국어 텍스트를 스캔해, CJK 문자가 감지되면 자동 제거합니다. 번체 중국어 방향으로도 대응 처리를 해두었습니다. 간체자에서 번체자로의 변환 대조표 60개 항목을 유지해 출력에 간체자가 포함되지 않도록 합니다.
문제 3: 트윗이 글자 수 제한을 초과함
증상: 생성된 트윗이 280자를 초과해 발행할 수 없습니다.
수정: 자동 축약 루프를 구현했습니다. 시스템이 먼저 AI에게 축약을 시도하게 하고, 최대 세 번까지 반복하며, 매 라운드 목표 글자 수를 줄입니다(280 → 250 → 230). 세 번을 거쳐도 여전히 길면 강제로 잘라냅니다.
문제 4: AI가 검증되지 않은 사실을 자신감 있게 서술함
증상: 콘텐츠에 매우 구체적으로 들리는 주장이 있지만, 출처가 전혀 없습니다.
수정: 콘텐츠 파이프라인에 fact_check 필드를 추가했습니다. “미확인” 또는 “검증 불가"로 표시된 콘텐츠는 자동으로 차단하고 발행하지 않습니다. 고위험 발언(ETF 승인, 거래소 상장, 기업 인수)은 “확인됨"으로 표시하고 출처를 첨부해야만 통과됩니다.
문제 5: 같은 주제가 반복해서 등장함
증상: 시스템이 다른 날에 비슷한 주제의 콘텐츠를 발행해, 독자들이 반복되는 느낌을 받습니다.
수정: 3일간의 발행 기록을 비교하는 교차일 중복 제거 메커니즘을 추가했습니다. 중복 제거에는 동의어 대조표를 사용합니다(예: “SOL"과 “Solana"는 같은 주제로 취급). 표현만 바꿔서 새 콘텐츠인 척 발행하는 것을 방지합니다.
시스템이 고장 났을 때: 반드시 마주치게 될 네 가지 AI 시스템 장애 유형
크고 작은 버그를 수십 개 고쳤습니다. 구체적인 기술 세부사항은 사람마다 다르지만, 장애의 “유형"은 놀라울 만큼 일관됩니다. AI 자동화 시스템을 구축한다면 아래 네 가지는 거의 반드시 만나게 됩니다.
첫 번째: 무음 장애
AI 시스템에서 가장 위험한 고장 방식은 충돌이 아닙니다. “조용히 멈추는 것"입니다. 저희 트레이딩 스캐너가 네 시간 넘게 중단된 적이 있었는데, 에러 메시지도 없고, 알림도 없었으며, 스케줄은 정상적으로 실행됐지만 아무것도 하지 않았습니다. 주기적인 상태 점검이 되고 나서야 발견했습니다.
크래시보다 더 무서운 이유: 크래시는 알림 시스템이 잡아냅니다. 무음 장애는 잡아내지 못합니다. 시스템이 돌아가고 있다고 생각하지만 이미 오래 전에 멈춰 있는 것입니다.
예방 방법: “에러가 없는지"만 모니터링하면 안 됩니다. “산출물이 있는지"를 모니터링해야 합니다. 하트비트 메커니즘을 설계합니다. 시스템이 성공적으로 실행될 때마다 타임스탬프를 기록하고, 모니터링 쪽에서 이 타임스탬프가 만료됐는지 확인합니다. 산출물이 없는 것 자체가 경보입니다.
두 번째: 환경 차이
직접 수동으로 실행할 때는 모두 정상이지만, 자동 스케줄로 실행하면 고장납니다. 원인은 대개 스케줄링 환경의 PATH가 다르거나, 환경 변수가 로드되지 않았거나, 권한이 다르거나, 작업 디렉터리가 잘못된 것입니다.
특히 걸리기 쉬운 이유: 테스트할 때는 자신의 터미널을 사용하기 때문에 모든 환경 변수가 준비되어 있습니다. 스케줄 작업은 거의 아무것도 없는 깨끗한 환경에서 시작되므로, 당연히 있을 것이라고 생각한 것들이 전부 없습니다.
예방 방법: 스케줄링 스크립트의 가장 앞부분에서 필요한 모든 환경 변수와 PATH를 명시적으로 로드합니다. 아무것도 “이미 존재한다"고 가정하지 마십시오. 배포 전에 스케줄 방식으로 전체 테스트를 한 번 돌려봅니다. 수동 테스트만으로 끝내지 마십시오.
세 번째: 성능 저하를 인식하지 못함
시스템은 폴백 메커니즘을 설계했습니다. 주요 AI 모델이 다운되면 백업 방안을 씁니다. 안정적으로 들립니다. 하지만 문제는 백업 방안의 품질이 주 방안보다 훨씬 낮을 수 있는데, 시스템이 저하 모드로 운영 중이라고 알려주지 않는다는 것입니다.
한번은 이런 일이 있었습니다. 주 모델이 속도 제한에 걸려 시스템이 자동으로 순수 기술 지표 판단으로 후퇴했습니다. 신뢰도 점수가 정상인 80점에서 20점으로 떨어졌지만, 시스템은 그대로 트레이딩을 실행했습니다. 결과는 손실이었습니다.
왜 위험합니까: 폴백은 “시스템이 멈추지 않도록” 설계된 것이지만, 운영 유지와 품질 유지는 다른 문제입니다. 신뢰도 20점짜리 판단으로 트레이딩을 실행하는 것은 실행하지 않는 것보다 나쁩니다.
예방 방법: 모든 폴백 레이어에 저하 상태를 표시하고, 저하 정도에 따라 행동을 조정합니다. 백업 방안의 품질이 의사결정을 지원할 수준이 안 된다면, 올바른 선택은 일시 정지이지 낮은 품질의 결정을 강행하는 것이 아닙니다. 또한 폴백 방안은 가능한 한 “동급의 다른 모델로 교체"하는 방식으로 하고, “AI를 제거하고 규칙만으로 버티는” 방식은 피합니다.
네 번째: 하나 고치면 다음 게 나타남
첫 번째 버그를 고치고 시스템이 돌아가면, 곧바로 두 번째 버그를 만납니다. 이건 운이 나쁜 게 아닙니다. 첫 번째 버그가 전체 프로세스를 막고 있어서, 뒤에 있는 버그가 드러날 기회 자체가 없었기 때문입니다.
왜 자주 발생합니까: AI 파이프라인은 대개 직렬 연결입니다. 스캔 → 분석 → 의사결정 → 실행 → 모니터링. 앞이 고장나면 뒤는 실행조차 되지 않아, 뒤의 문제가 숨겨집니다. 앞을 고치고 나서야 뒤의 문제가 수면 위로 올라옵니다.
예방 방법: 버그를 하나 고친 후 바로 축하하지 마십시오. 전체 엔드투엔드 테스트를 한 번 돌립니다. 입력 쪽부터 출력 쪽까지 전부 통과하는 것을 확인한 후에야 수정이 완료된 것입니다. “하나 고치면 전체 테스트"하는 습관을 기릅니다.
비용 현실
이 모든 작업을 실제 사람에게 맡긴다면 — 마케터 한 명, 콘텐츠 담당자 한 명, 엔지니어 한 명, PM 한 명 — 서울 기준으로 월급 합계가 1,500만 원 이상은 될 것입니다.
지금 저의 비용은 몇 가지 AI 구독료와 24시간 운영 중인 클라우드 VPS 비용입니다.
하지만 절약이 핵심이 아닙니다. 진정한 차이는 반응 속도와 쉬지 않는다는 것입니다. 저의 시스템은 심야에 자동으로 보안 순찰을 돌고, 새벽에 시장 분석 리포트를 생성하며, 24시간 트레이딩 포지션을 모니터링합니다. 제가 일어나면 해야 할 일은 이미 완료되어 있고, 저는 리포트를 보고 의사결정만 하면 됩니다.
하루 중 관리에 쓰는 시간은 약 30분입니다. 나머지 시간은 전략을 고민하거나 삶을 즐기는 데 씁니다. 이것이 소형 AI 회사의 진정한 가치입니다. 사람을 대체하는 게 아니라, 한 사람이 예전에 소규모 팀이 필요했던 일을 할 수 있게 만드는 것입니다.
제가 배운 것
이 시스템을 구축하고 나서야 진정으로 이해하게 된 것들을 말씀드리겠습니다.
첫째: AI 시스템의 “고장"은 일반 프로그램의 고장과 다릅니다.
일반 프로그램이 고장나면 크래시가 나고 에러 메시지를 볼 수 있습니다. AI 시스템이 고장나면 대개 “그럴듯하게 들리지만 실은 빗나간 답변을 산출합니다”. 이런 오류는 발견하기 어렵습니다. 오류처럼 생기지 않았기 때문입니다. 그래서 게이트가 필요하고, 독립 검증이 필요하며, “괜찮아 보인다"는 것을 절대 믿으면 안 됩니다.
둘째: 환각 방지는 일회성 작업이 아닙니다.
규칙을 하나 추가하면 AI는 그 규칙의 경계 밖에서 새로운 환각 방식을 찾아냅니다. 이것은 끝없는 추격전입니다. 규칙은 새로운 실패 사례에 따라 계속 업데이트되어야 합니다.
셋째: 이 시스템을 구축하는 비용은 심각하게 과소평가되어 있습니다.
도구를 설치하는 것만으로는 사용할 수 없습니다. 몇 달에 걸친 지속적인 조정이 필요합니다. Agent의 작업 경계, 권한, 품질 기준, 협업 형식, 게이트 설계. 이것들에는 설명서가 없습니다. 직접 부딪히고 스스로 정리해야 합니다.
넷째: 게이트의 엄격함이 얼마나 편안하게 잘 수 있는지를 결정합니다.
게이트가 너무 느슨하면 AI가 또 뭔가 엉뚱한 말을 했을까 봐 매일 불안해집니다. 게이트가 너무 빡빡하면 효율이 수동으로 하는 것보다 나빠집니다. 그 균형점을 찾는 것이 이 모든 것에서 가장 어려운 부분이며, 업무 시나리오마다 균형점이 다릅니다.
2026년, 한 사람과 클라우드 VPS 한 대가 할 수 있는 것은 2020년의 5인 스타트업 팀의 산출량을 이미 넘어섰습니다. 이 추세는 더욱 가속될 것입니다.
하지만 누군가 “AI를 쓰면 제로 비용으로 창업할 수 있다"고 말한다면, 그건 거짓말입니다. 비용이 없는 게 아닙니다. 다만 “급여"에서 “당신 자신의 시간, 인지적 부담, 그리고 AI의 구멍을 끊임없이 쫓아 고치는 에너지"로 바뀐 것입니다.
저는 아직 이 길 위에 있습니다. 매일 무언가를 고치고, 매일 새로운 문제를 발견합니다.
하지만 돌아보면, 클라우드 VPS 한 대로 회사를 만드는 일은 이렇게 조금씩 쌓아가는 것 같습니다.