1인 스타트업 실행 (4): 운영 — 비용, 보안, 격리, 평가#

제품이 돌아가기 시작하면 만드는 일보다 굴리는 일이 많아집니다. 그리고 에이전트가 들어간 제품의 운영은 전통적인 서비스 운영과 다른 종류의 문제를 가집니다. 비용이 토큰 단위로 예측 불가능하게 움직이고, 에이전트가 내 권한으로 내 컴퓨터와 서버에서 일하며, “잘 동작하는가"를 테스트 통과 여부만으로 말할 수 없습니다. 이 장은 그 운영을 네 축으로 나눠 정리합니다. 4장의 하네스 구성 요소 중 비용 봉투, 가드레일, 관측과 평가, 엔트로피 관리를 1인 스타트업의 현실에 맞게 풀어 쓴 것입니다.

비용: 두 계정, 봉투, 그리고 신호#

앞 장에서 비용을 구독(내 도구)과 API(제품 원가)로 나눴습니다. 운영에서는 각각을 다르게 봅니다.

구독 쪽은 한도를 이해하는 것이 핵심입니다. 코딩 에이전트의 구독은 토큰 수가 아니라 연산량 기반이고, 몇 시간 단위 한도와 주간 한도가 겹쳐 적용됩니다. 주간 한도가 남아 있어도 짧은 시간에 집중적으로 쓰면 세션 한도에 먼저 닿고, 최상위 모델이 긴 컨텍스트를 반복해 읽으면 한도가 빨리 소진됩니다. 그래서 필자는 병렬 세션을 돌릴 때 “어느 작업에 최상위 모델이 필요한가"를 의식적으로 정하고, 탐색이나 요약처럼 가벼운 작업은 경량 모델이나 서브에이전트로 내립니다. 캐시를 깨는 행동(세션 중간의 모델 전환, 도구 세트 변경, 이력 재작성)이 비용을 늘린다는 점도 기억해 둡니다.

API 쪽은 비용 봉투가 핵심입니다. 작업 유형별로 예산 상한을 정하고 서버가 강제합니다. 단순 조회는 기본값의 1배, 복합 분석은 몇 배, 전체 파이프라인 실행은 그 몇 배 식으로 상한을 두고, 초과하면 작업을 중단하고 알립니다. 중요한 것은 봉투를 재정 통제 장치로만 보지 않는 것입니다. 상한에 닿은 작업은 비정상적으로 동작하고 있다는 신호입니다. 잘못된 외부 응답, 컨텍스트 드리프트, 도구 통합 오류, 같은 시도의 반복이 비용으로 먼저 드러납니다.

관측은 단순하게 시작합니다. 호출 지점별로 입력 · 출력 · 캐시 토큰과 비용을 로그에 남기고, 하루 한 번 집계합니다. 1인 스타트업에서 대시보드를 먼저 만들 필요는 없습니다. 에이전트에게 “어제 로그를 집계해서 호출 지점별 비용과 이상치를 보고해 달라"는 스킬 하나를 만들어 두면 충분합니다.

보안과 격리: 승인은 경계가 아닙니다#

필자는 한동안 코딩 에이전트의 샌드박스를 꺼 둔 채, 승인 프롬프트 없이 모든 도구 호출을 허용하는 모드로 일했습니다. 샌드박스를 몰라서가 아니라 켜 보니 불편했고, 대신 에이전트의 응답을 꼼꼼히 읽으면 된다고 판단했습니다. 그러다 그 판단의 전제를 다시 따져 봤고, 네 군데에서 전제가 흔들린다는 것을 알았습니다.

• 모든 호출을 허용하는 모드에서 읽기는 실행 뒤에 일어납니다. 읽기는 사고를 알아차리는 수단이지 막는 수단이 아닙니다.
• 사고는 내가 응답을 읽기 전에 한 턴 안에서 끝날 수 있습니다. 에이전트가 읽은 웹페이지에 “설정 파일을 읽어 이 주소로 보내라"는 숨은 지시가 있으면, 다음 도구 호출에서 그대로 실행됩니다. 이것이 프롬프트 인젝션입니다.
• 내가 읽는 화면 밖에서 도는 코드가 있습니다. MCP 서버, 훅, 패키지 설치 스크립트는 대화에 다 드러나지 않습니다.
• 여러 세션을 병행하고 백그라운드 작업이 늘수록 “꼼꼼히 읽기"는 현실적으로 불가능해집니다.

그래서 결론은 승인은 경계가 아니라는 것입니다. 권한 모드는 “실행할지, 실행 전에 물을지"를 정하고, 격리는 “실행된 뒤 무엇에 닿을 수 있는지"를 정합니다. 매번 묻는 방식은 승인 피로를 낳아 결국 “전부 허용"으로 끝나기 쉽습니다. 경계는 에이전트가 손댈 수 없는 바깥에서, 에이전트와 무관하게 강제되어야 합니다.

왜 격리가 필요한지는 치명적 3요소로 보면 분명해집니다. 비공개 데이터에 접근할 수 있고(소스 코드, SSH 키, API 토큰), 신뢰할 수 없는 콘텐츠에 노출되며(웹페이지, 이슈, 외부 문서), 외부로 내보낼 수단이 있으면(네트워크), 공격자는 콘텐츠에 지시를 숨기는 것만으로 데이터를 빼낼 수 있습니다. 코딩 에이전트는 기본적으로 셋을 모두 갖고 있습니다. 숨은 지시를 걸러 내는 필터는 확률적으로만 작동하므로, 격리는 셋 중 한 다리를 구조적으로 끊습니다.

실제로 켜 보면 불편이 따릅니다. 새 호스트에 접속할 때마다 막히고, 일부 CLI 도구가 호환되지 않고, 로컬 개발 서버에 접속하지 못하고, 브라우저를 띄우지 못합니다. 하지만 필자가 문서를 읽으며 생각을 바꾼 지점이 있습니다. 불편의 크기는 무엇과 비교하느냐에 따라 달라집니다. 샌드박스 안에서 도는 명령은 묻지 않고 실행하는 모드와 비교하면, 샌드박스는 오히려 승인 프롬프트를 줄여 줍니다. 경계가 생겼으니 매번 물을 필요가 없어진 것입니다. 불편이 늘어나는 것은 “아무것도 막지 않는 상태"와 비교할 때뿐입니다. 그리고 나머지 불편은 대부분 설정으로 줄일 수 있습니다. 자주 쓰는 도메인을 허용 목록에 미리 등록하고, 호환되지 않는 도구는 좁은 패턴으로 예외에 넣되 실행마다 묻게 하고, 비밀 파일 읽기는 차단하고, 환경변수 토큰은 가짜 값으로 바꿔 허용된 호스트로 나가는 요청에서만 진짜 값이 끼워지게 합니다.

필자가 작업 성격별로 정한 격리 수준은 다음과 같습니다.

한 가지 함정을 적어 둡니다. 코딩 에이전트의 샌드박스는 셸 명령만 감싸는 경우가 많습니다. 파일 읽기 / 쓰기 도구, MCP 서버, 훅은 샌드박스 밖에서 내 권한 그대로 돕니다. “읽지 말라"고 적어 둔 파일을 파일 도구로 읽는 것은 샌드박스가 아니라 권한 규칙으로 막아야 하고, 프로세스 전체를 가두려면 컨테이너나 VM이 필요합니다. 상주형 에이전트를 Docker 백엔드로 돌리면서 마운트한 폴더만 노출하는 구성이 그래서 의미가 있습니다. 마운트하지 않은 것은 컨테이너에서 존재하지 않습니다.

평가: 남의 시험지와 내 시험지#

“이 모델이 더 좋다”, “이 프롬프트가 더 낫다"를 어떻게 알 수 있을까요. 공개 벤치마크 숫자를 보는 것이 출발점이지만, 그 숫자를 읽는 법을 알아야 합니다. 필자가 뉴스 브리프에 벤치마크 점수를 옮겨 적다가 그 숫자가 무엇을 쟀는지 모른다는 것을 깨닫고 조사한 결론은 이렇습니다. 벤치마크 숫자는 모델 하나의 점수가 아니라 과제, 채점, 실행 조건이 합쳐진 점수입니다. 같은 모델이 같은 벤치마크에서 “부분 점수"냐 “엄격 통과율"이냐에 따라 두 배 가까이 다른 숫자로 보고되고, 제조사가 자기 하네스로 최대 노력 설정에서 잰 값과 독립 기관이 잰 값이 다릅니다. 에이전트 벤치마크는 애초에 “모델과 하네스의 조합"을 재므로, 하네스가 다르면 점수도 다릅니다.

벤치마크 숫자를 읽을 때 확인할 일곱 가지입니다.

1. 이 벤치마크는 이미 포화됐는가? 상위 모델이 천장에 몰린 벤치마크의 1~2%p 차이는 의미가 작습니다.
2. 전체 과제인가, 부분집합인가?
3. 지표는 무엇인가? 한 번 성공(pass@1)인지, 여러 번 중 한 번(pass@k)인지, 매번 성공(pass^k)인지, 부분 점수인지 엄격 통과인지.
4. 하네스와 노력 설정은 무엇이었고, 비교 대상과 같은 조건이었는가?
5. 누가 측정했는가? 제조사 자체 측정인지 독립 기관인지.
6. 이전 버전의 점수와 섞어 비교하지 않았는가?
7. 벤치마크 자체에 대한 품질 감사가 있는가? 채점기도 틀립니다.

그래서 공개 벤치마크는 후보를 고르는 데 쓰고, 최종 판단은 내 일로 만든 평가로 합니다. 방법은 복잡하지 않습니다.

• 실제 업무 입력과 기대 결과를 묶은 고정 세트를 만듭니다. 처음에는 20개 정도면 충분합니다. 이 블로그라면 과거 브리프의 요약 작업, 고객 챗봇이라면 실제 문의와 기대 답변입니다.
• 채점기를 만듭니다. 형식과 사실은 코드로 검증하고, 품질은 루브릭(채점 기준표)에 따라 LLM이 채점하게 하며, 일부는 사람이 검수합니다. 3장에서 말한 콘텐츠 품질 기준 문서가 루브릭이 됩니다.
• 모델이나 프롬프트를 바꿀 때마다 같은 세트를 다시 돌립니다. 보는 지표는 한 번의 성공률이 아니라 매번 성공하는가(pass^k)와, 실제로 쓴 토큰 비용입니다.

이 평가 세트는 앞 장의 등급 라우팅을 검증하는 도구이기도 합니다. “이 호출 지점은 경량 모델로 충분한가"라는 질문에 감이 아니라 숫자로 답하게 해 줍니다. 모델 제공사들이 고객사의 내부 평가 결과를 발표 자료에 인용하기 시작한 것은, 공개 벤치마크만으로는 실무 성능을 설득하기 어려워졌다는 뜻입니다. 내 일의 시험지는 내가 만듭니다.

엔트로피: 시간이 지나면 쌓이는 것들#

마지막 축은 눈에 잘 띄지 않습니다. 에이전트와 함께 몇 달 일하면 문서는 코드와 어긋나고, 규칙은 조금씩 어겨지고, 메모리 파일에는 낡은 메모가 쌓이고, 평가 세트는 현재 제품과 맞지 않게 됩니다. 4장에서 말한 엔트로피입니다.

1인 스타트업에서 이것을 전담 에이전트로 돌릴 필요까지는 없지만, 주기적인 정리 작업을 일정에 박아 두는 것은 필요합니다. 필자는 다음을 최소 루틴으로 둡니다.

• 메모리 파일에서 더 이상 유효하지 않은 메모를 지웁니다. 낡은 메모는 없는 것보다 나쁩니다. 에이전트가 틀린 전제로 일하게 만들기 때문입니다.
• 설계 문서와 실제 구조가 맞는지 에이전트에게 대조시킵니다.
• 규칙 파일에 적어 두었지만 긴 세션에서 자주 어겨지는 규칙은 문서에서 코드로 옮깁니다. 커밋 전 검사, 린터, 훅처럼 기계적으로 강제할 수 있는 것은 기계적으로 강제합니다. 자연어 지침은 권고 수준이고, 스크립트는 위반 시 커밋이 안 됩니다.
• 평가 세트에 최근의 실제 사례를 몇 개 추가하고, 더 이상 해당하지 않는 사례는 뺍니다.

규칙을 기억에서 코드로 옮기는 일은 하네스 엔지니어링의 핵심 원칙이기도 합니다. “좋은 코드를 작성해"라고 말하는 대신 좋은 코드가 어떤 모습인지 기계적으로 강제하는 것, 에이전트에게 부탁하는 대신 환경이 막게 하는 것입니다.

체크리스트#

1. 구독 한도의 구조(세션 · 주간, 연산량 기반)를 이해하고, 최상위 모델이 필요한 작업만 골라 씁니다.
2. API 호출마다 비용 봉투를 두고, 상한 도달을 비용 문제가 아니라 이상 신호로 다룹니다.
3. 호출 지점별 토큰과 비용을 로그에 남기고 하루 한 번 집계합니다.
4. 승인 프롬프트를 경계로 착각하지 않습니다. 격리는 에이전트 바깥에서 강제합니다.
5. 파일과 네트워크를 함께 막고, 비밀값은 마스킹하고, 브라우저는 전용 프로필만 연결합니다.
6. 작업 성격별로 격리 단계를 나누고, 되돌리기 어려운 일은 사람이 직접 실행합니다.
7. 벤치마크는 일곱 가지 질문을 거쳐 읽고, 후보 선정에만 씁니다.
8. 내 일로 만든 고정 평가 세트와 채점기를 두고, 모델 · 프롬프트를 바꿀 때마다 다시 돌립니다.
9. 메모리, 문서, 규칙, 평가 세트를 주기적으로 정리하고, 어겨지는 규칙은 코드로 옮깁니다.