같은 AI 도구를 쓰는데 누구는 10분이면 끝내고, 누구는 1시간을 쓴다. 이 차이는 실력이 아니라 ‘활용 노하우’의 차이다. 그리고 이 노하우가 개인의 머릿속에만 머무는 한, 조직의 생산성은 가장 잘 쓰는 한 명에게 종속된다.
토스 기술 블로그에서 최근 이 문제를 정면으로 다루는 글 2개가 연달아 올라왔다. 하나는 LLM을 실제 업무에 연결하는 ‘Harness(하네스)’ 개념을 정의한 글, 다른 하나는 이 하네스를 팀 단위로 확장해서 조직 생산성의 저점(Floor)을 높이자는 글이다. 두 글 모두 같은 결론을 향한다. AI 활용 역량은 더 이상 개인의 센스가 아니라, 팀이 설계하고 배포해야 할 ‘시스템’의 영역이다.
이 글에서는 토스의 두 아티클을 기반으로, 보안/IT 실무자 관점에서 이 흐름이 왜 중요한지 정리해본다.
Harness가 뭔데
Harness는 원래 ‘마구(馬具)’다. 말이 아무리 빠르고 강해도 마구 없이는 인간이 그 힘을 활용할 수 없다. LLM도 마찬가지다. ChatGPT에 “우리 서비스 버그 고쳐줘”라고 말한다고 마법처럼 해결되지 않는다. LLM은 혼자서 파일을 읽을 수도, API를 호출할 수도, 데이터베이스에 접근할 수도 없다.
토스는 Claude Code를 이 맥락에서 정의한다. Claude라는 LLM 엔진을 실제로 일할 수 있는 에이전트로 만들어주는 Harness라는 것이다. 그리고 이 하네스를 구성하는 요소들을 기존 소프트웨어 아키텍처에 대응시킨다.
| Claude Code 구성 요소 | 전통 아키텍처 대응 |
|---|---|
| CLAUDE.md | package.json, pom.xml (프로젝트 설정) |
| Slash Command | CLI 명령어, npm scripts |
| Skill | 내부 라이브러리, 유틸리티 모듈 |
| MCP (Model Context Protocol) | Adapter Pattern, Repository Pattern |
| Sub-agent | Service Layer, 마이크로서비스 |
핵심은 이거다. MCP, Skills, Sub-agent, Slash Command — 이 용어들이 새로워 보이지만, 본질은 우리가 수십 년간 해온 소프트웨어 엔지니어링의 연장선이다. MCP를 설계할 때 Adapter Pattern을 떠올리면 되고, Skill을 만들 때 단일 책임 원칙(SRP)을 적용하면 된다. 달라진 건 모듈의 내부가 ‘코드’에서 ‘프롬프트와 에이전트 로직’으로 바뀌었을 뿐이다.
문제는 개인이 아니라 팀이다
여기까지는 개발자 개인의 생산성 이야기다. 토스가 더 흥미로운 질문을 던진 건 그다음이다.
이 노하우가 개인의 머릿속에만 머물면, 조직의 생산성은 결국 가장 잘 쓰는 한 명에 의존하게 되지 않을까?
잘하는 사람의 LLM 활용 패턴을 슬래시 커맨드로 패키징하고, 팀 컨벤션을 실행 가능한 코드로 관리하고, 이걸 플러그인으로 배포한다. 토스가 실험하고 있다는 방식의 골자다.
oh-my-zsh가 터미널 생산성의 사실상 표준이 된 것처럼, oh-my-claudecode 같은 오픈소스 플러그인이 AI 코딩 에이전트의 출발점이 되고 있다. 하지만 토스는 여기서 한 발 더 나아간다. 외부에서 만든 범용 도구는 ‘코드’는 잘 알아도 우리 팀의 ‘도메인 맥락’은 모른다는 거다.
결제 팀에는 결제 팀만의, 정산 팀에는 정산 팀만의 ‘AI가 잘하는 일’과 ‘반드시 사람이 검토해야 하는 일(HITL, Human-in-the-Loop)’이 따로 있다. 이걸 구분해서 시스템에 녹여야 한다.
Executable SSOT — 문서가 곧 시스템 프롬프트
이 글에서 가장 인상적인 개념이 ‘Executable SSOT(실행 가능한 단일 진실 원천)’이다.
우리는 항상 SSOT를 갈구하지만, 위키나 노션 문서는 작성되는 순간부터 낡은 정보가 된다. 사람이 읽기 위한 문서이기 때문이다. 그런데 Claude Code의 플러그인 형태로 정의된 지식은 성격이 다르다.
- 사람이 읽으면: 업무 가이드라인이자 매뉴얼
- LLM이 읽으면: 정확한 지시사항이 담긴 시스템 프롬프트
같은 문서가 사람에게는 가이드, AI에게는 실행 명령이 된다. 문서로 전달하면 잘 읽히지 않던 컨벤션이나 프로세스가, 도구에 녹이면 자연스럽게 따르게 되는 것이다. 이건 보안 정책 배포에서도 똑같은 문제를 겪어본 사람이라면 바로 공감할 이야기다.
보안 실무자 관점에서 이게 왜 중요한가
여기서부터는 내 생각이다.
1) 보안 팀이야말로 ‘1인 전문가 종속’ 문제가 가장 심각하다
대부분의 기업에서 보안 담당자는 1~2명이다. 이 사람이 퇴사하면 ISMS-P 인증 문서부터 취약점 관리 프로세스까지 전부 블랙박스가 된다. LLM 활용 노하우가 개인에게 종속되는 것과 완전히 같은 구조다. 보안 정책 점검 패턴, 로그 분석 쿼리, 컴플라이언스 체크리스트 같은 걸 Skill이나 Slash Command로 패키징해두면, 최소한 담당자가 바뀌어도 기본적인 생산성 저점은 유지할 수 있다.
2) 보안 컨벤션이야말로 ‘Executable SSOT’가 필요하다
“개인정보 처리 시 AES-256 암호화 적용”, “외부 API 연동 시 인증토큰 만료 시간 1시간 이내” — 이런 보안 컨벤션을 노션에 적어놔도 개발자가 매번 확인하지 않는다. 그런데 이걸 Claude Code의 CLAUDE.md나 Skill에 넣어두면, AI가 코드를 작성할 때 자동으로 참조한다. 문서가 아니라 시스템이 컨벤션을 강제하는 구조가 되는 것이다.
3) HITL(Human-in-the-Loop) 설계가 보안의 핵심이다
토스가 강조한 HITL — “AI가 잘하는 일”과 “반드시 사람이 검토해야 하는 일”의 구분 — 이건 보안에서 가장 중요한 설계 원칙이기도 하다. 보안 로그 1차 분류는 AI가 해도 되지만, 실제 침해 판단은 사람이 해야 한다. 취약점 스캔 결과 정리는 AI가 해도 되지만, 위험 등급 최종 결정은 사람이 해야 한다. 이 경계를 시스템으로 명확히 정의해두는 게 결국 Harness 설계의 핵심이다.
토큰은 새로운 RAM이다
토스 글에서 짧게 언급했지만 중요한 포인트가 있다. 전통적인 서버에서는 RAM을 걱정했는데, 에이전트에서는 토큰을 걱정해야 한다는 것이다.
CLAUDE.md, Skills, 대화 히스토리, MCP 응답 — 이 모든 게 Context Window에 쌓인다. 200K 토큰이 많아 보여도 대규모 코드베이스를 다루면 순식간에 차오른다. Skill을 20개 만들면 20개의 Description이 항상 컨텍스트를 점유한다.
OOM(Out of Memory)을 예방하듯, 토큰 폭발도 설계 단계에서 미리 감지해야 한다. SRP를 맹목적으로 따르다 수백 개 클래스가 난립하는 것처럼, Skill을 잘게 쪼개다 보면 오히려 성능이 떨어질 수 있다. 보안 Skill을 설계할 때도 “인증 검토”, “암호화 검토”, “접근제어 검토”를 각각 만들 게 아니라, “보안 코드 리뷰”라는 하나의 Skill로 응집도를 높이는 게 낫다.
결론: Software 3.0 시대의 경쟁력
토스의 두 글을 관통하는 메시지는 명확하다.
Software 3.0 시대에 진짜 경쟁력은 AI를 잘 쓰는 개인이 아니라, AI 활용을 구조화할 수 있는 팀에 있다. Software 1.0 시대에 인증, 로깅, 결제 연동 같은 반복 기능을 공통 라이브러리로 만들어 바퀴를 다시 발명하는 시간을 없앤 것처럼, Software 3.0 시대에는 LLM 활용 패턴을 플러그인과 워크플로우로 패키징해서 팀 전체에 배포해야 한다.
아직은 가설이고 방향성이다. 토스도 인정한다. 마켓플레이스 위에서 팀의 워크플로우가 어떻게 진화할지, 플러그인 기반의 지식 관리가 실제로 얼마나 효과적일지는 직접 해봐야 안다.
하지만 한 가지는 분명하다. LLM 활용 능력이 개인의 센스 영역에 머물러서는 안 된다. 그것은 팀이 설계하고 배포해야 할 시스템의 영역으로 이미 넘어가고 있다. 보안 팀이든, 개발 팀이든, 이 전환을 일찍 시작하는 조직이 결국 앞서게 될 것이다.
참고 자료