AI 워크플로우 표준화란, LLM 활용 노하우를 개인 역량에 의존하지 않고 팀 전체가 동일하게 실행할 수 있는 시스템으로 구축하는 것입니다. 2026년 3월 현재, Claude Code 마켓플레이스와 oh-my-claudecode(GitHub Star 8,300+) 같은 오케스트레이션 플러그인이 팀 단위 워크플로우 배포를 현실로 만들고 있으며, 핵심은 HITL(Human-in-the-Loop) 정책 — 즉 “AI가 알아서 할 것”과 “반드시 사람이 볼 것”의 경계를 팀이 합의하는 데 있습니다.
같은 도구, 다른 결과 — 이게 개인 차이일까?
AI가 코드를 짜는 시대에, 개발자의 가치는 어디에 있을까요?
저는 이 질문을 좀 다르게 던져보고 싶어요.
같은 LLM을 쓰는데, 왜 팀마다 결과물이 극단적으로 갈리는 걸까요?
같은 Claude Opus 4.6. 같은 Cursor IDE. 같은 회사. 같은 코드베이스.
그런데 어떤 엔지니어는 10분 만에 복잡한 리팩토링을 끝내고, 어떤 엔지니어는 할루시네이션이랑 1시간째 씨름하고 있습니다.
저도 이 경험을 직접 했어요. 제가 만든 에이전트 시스템을 옆 자리 동료한테 넘겨줬는데, 같은 도구를 쓰는데 결과물 품질이 확 달라지는 거예요. 처음엔 “코딩 실력 차이인가?” 생각했는데, 아니었어요.
차이는 단 하나였습니다.
작업 전에 컨텍스트를 설계했느냐.
Toss 기술 블로그에서 정확히 이걸 짚었어요. “이것은 코딩 실력의 차이가 아닙니다. LLM이라는 도구를 얼마나 정교하게 제어하는가에 대한 노하우의 격차입니다.” 그리고 이 격차를 개인의 센스에 맡겨두는 건, 팀 차원에서 엄청난 손실이라고.
이 말이 너무 와닿았습니다.
왜냐면 저도 Cursor랑 Claude Code로 매일 작업하는 사람인데, “내가 쓰는 방법”을 팀에 전파하는 게 이렇게 어려운 일인 줄 몰랐거든요.
Software 3.0이 뭔데, 갑자기 하네스가 왜 나오는 건지
여기서 잠깐 배경부터 깔아야 해요.
Andrej Karpathy가 2025년 6월 Y Combinator에서 발표한 프레임이 있습니다. 소프트웨어의 진화를 3단계로 나눈 거예요.
| 시대 | 프로그래밍 방식 | 프로그램의 실체 |
|---|---|---|
| Software 1.0 | 개발자가 로직을 코드로 작성 | Python, Java 코드 |
| Software 2.0 | 데이터로 모델 학습 | 신경망 가중치 |
| Software 3.0 | 자연어로 원하는 걸 말함 | 프롬프트 |
Software 3.0이란? Andrej Karpathy가 정의한 소프트웨어 진화의 세 번째 단계로, LLM에게 자연어로 “무엇을(What)” 원하는지 지시하면 되는 시대입니다. 프롬프트가 곧 프로그램이며, 2025년 6월 Y Combinator AI Startup School에서 공식 발표되었습니다.
Karpathy 말대로 “The hottest new programming language is English”인 시대가 온 거예요.
근데 현실은요?
ChatGPT한테 “우리 서비스 버그 고쳐줘” 하면 마법처럼 해결되냐? 안 됩니다.
LLM은 혼자서 파일 못 읽고, API 못 호출하고, DB 접근도 못 해요. 아무리 똑똑해도 실행 환경이 없으면 무용지물이에요.
여기서 하네스(Harness) 개념이 나옵니다.
하네스는 원래 ‘마구(馬具)’예요. 말이 아무리 빠르고 강해도, 마구 없이는 그 힘을 활용할 수가 없잖아요. LLM도 마찬가지입니다.
| LLM 한계 | 하네스가 해결 |
|---|---|
| Context window 제한 | Memory 관리 |
| 환각(Hallucination) | Fact grounding, RAG |
| 도메인 지식 부족 | Knowledge Base 주입 |
| 상태 관리 불가 | Session, Checkpoint |
| 외부 시스템 접근 불가 | Tool, MCP |
Claude Code 자체가 Claude 모델을 위한 하네스입니다. 파일 시스템 접근, 터미널 실행, MCP 연결, 슬래시 커맨드 — 이 모든 게 “LLM을 실제로 일하게 만드는 장치”예요.
근데 여기서 한 발짝 더 나가야 합니다.
Claude Code는 범용 하네스예요. 코드는 잘 알아도, 우리 팀의 도메인은 몰라요.
결제팀에는 결제팀만의 규칙이 있고, 정산팀에는 정산팀만의 “AI가 절대 혼자 하면 안 되는 일”이 있거든요.
범용 하네스 + 팀 도메인 규칙 = 팀 하네스. 이게 진짜 생산성의 저점을 끌어올리는 구조입니다.
Exception이 Question으로 바뀌는 세계 — 이게 HITL의 본질
자, 여기서 Software 3.0 시대의 결정적 차이를 하나 짚을게요.
전통적인 서비스 레이어를 떠올려보세요. 주문 처리 중 재고가 부족하면?
# Software 1.0 — 모든 케이스를 미리 정의해야 함
if inventory.check(item_id) < quantity:
raise OutOfStockException() # 정해진 예외
# 또는
return back_order_policy.apply(request) # 정해진 정책
실제로 개발하다 보면 이런 순간이 있잖아요. “이 케이스는… PM한테 물어봐야 하는데.” “스펙에 없는 상황인데 어떻게 하지?”
1.0에서는 이런 순간에 코드가 멈출 방법이 없어요. 예외를 던지거나, 개발자가 임의로 결정하거나, 일단 로그 남기고 넘어가거나.
Software 3.0 에이전트는 다릅니다. 물어볼 수 있어요.
Request → Agent → 작업 진행 중...
↓
🤔 불확실한 상황 발생
↓
"A와 B 중 어떤 걸 원하세요?"
↓
User: "A로 해줘"
↓
계속 진행 → 완료
Exception이 Question으로 바뀌는 겁니다.
이걸 HITL(Human-in-the-Loop)이라고 해요. 그리고 이게 AI 워크플로우를 팀 표준으로 만들 때 가장 중요한 설계 포인트입니다.
HITL(Human-in-the-Loop)이란? AI 에이전트가 자율적으로 작업하되, 불확실하거나 위험한 상황에서는 사람의 판단을 요청하는 시스템 설계 패턴입니다. 2026년 현재 HITL은 데이터 라벨링을 넘어 의사결정 검증, 품질 보증, 예외 처리 등 5개 범주로 확장되었습니다.
근데 HITL이 가능하다고 매번 물어보면 안 돼요. 그건 그냥 귀찮은 도구입니다.
| 질문해야 할 때 | 알아서 해야 할 때 |
|---|---|
| 프로덕션 DB 쿼리 실행 전 | 코드 포맷팅 |
| 비용 $50 초과 API 호출 전 | 테스트 실행 |
| 배포 명령 실행 전 | 로그 분석 |
| DELETE/DROP WHERE 없는 쿼리 | 초안 작성 |
| 스펙에 없는 애매한 케이스 | lint 수정 |
좋은 에이전트는 “언제 질문할지”를 아는 에이전트입니다. 그리고 좋은 팀 하네스는 이 기준을 팀이 합의해서 문서화해둔 거예요.
팀 하네스 실전 — oh-my-claudecode에서 배운 것
이론은 충분하고요. 실제로 어떻게 만드냐가 중요하잖아요.
저는 Cursor와 Claude Code를 병행하면서 나만의 하네스 시스템을 만들어 쓰고 있었어요. .claude/agents/에 14개 에이전트, .claude/skills/에 28개 스킬을 운영하면서요.
근데 이걸 혼자 쓸 때랑 팀에 전파할 때는 완전히 다른 문제더라고요.
oh-my-claudecode(OMC)가 이 문제를 잘 풀어놨어요. 2026년 3월 기준 GitHub Star 8,300개가 넘는 프로젝트인데, 핵심은 Team 모드입니다.
Team 파이프라인 구조
team-plan → team-prd → team-exec → team-verify → team-fix (loop)
이 다섯 단계가 oh-my-claudecode의 Team 워크플로우예요. 각 단계마다 역할이 나뉘어 있고, HITL 체크포인트가 명시되어 있습니다.
| 단계 | 하는 일 | HITL 여부 |
|---|---|---|
team-plan | 요구사항 분석 + 구현 방안 2-3개 제시 | ⛔ 방향 선택 사람 확인 |
team-prd | 선택된 방향으로 상세 스펙 작성 | ⛔ 스펙 승인 필요 |
team-exec | 실제 코드 구현 (TDD) | 자동 (중간 체크 가능) |
team-verify | 테스트 + 품질 검증 | ⛔ 검증 결과 사람 확인 |
team-fix | 이슈 수정 후 재검증 | 자동 (루프) |
눈에 보이시죠? 5단계 중 3곳에 HITL이 박혀 있어요. AI가 알아서 다 해주는 게 아니에요. 전략적으로 “여기서는 사람이 본다”를 정해둔 겁니다.
이게 oh-my-zsh가 터미널 생산성을 표준화한 것과 같은 원리예요. 누군가 미리 고민해둔 베스트 프랙티스를 팀원 모두가 동일하게 쓰는 거죠. 다만 차이가 있다면 — oh-my-zsh는 셸 설정이고, 팀 하네스는 AI의 행동 규범이라는 점.
팀 하네스의 실체 — 폴더 3개
{team-name}-harness/
├── context/ ← Executable SSOT 레이어
│ ├── team.md ← 팀 정체성 (도메인, 용어, 제약)
│ ├── domain-rules.md ← 도메인 특화 규칙
│ └── hitl-policy.md ← ⭐ 사람 승인 필수 단계 명시
│
├── workflows/ ← 실행 파이프라인
│ ├── team-plan.md ← /team-plan 커맨드 정의
│ ├── team-exec.md ← /team-exec 커맨드 정의
│ └── team-verify.md ← /team-verify 커맨드 정의
│
└── health/
└── harness-check.sh ← 정합성 자가 점검
이 구조에서 **가장 중요한 파일은 hitl-policy.md**입니다.
왜냐면 이게 없으면 팀원마다 “AI한테 어디까지 시켜도 되지?”의 기준이 다 달라요. 누구는 프로덕션 DB 쿼리도 AI한테 시키고, 누구는 코드 포맷팅도 직접 하고. 이 혼란이 팀 생산성의 바닥(Floor)을 깎아먹는 거예요.
Executable SSOT — 위키는 쓰는 순간 낡는다
여기서 Toss가 제시한 개념 중 제가 가장 공감했던 게 있어요.
Executable SSOT.
우리는 항상 SSOT(Single Source of Truth)를 원하잖아요. 근데 노션이나 위키에 쓴 문서는 작성되는 순간부터 낡아요. 왜냐면 사람이 읽기 위한 문서니까. 업데이트가 안 돼요. 새로 온 사람이 “이거 최신이에요?” 물어보면 아무도 모르는 그 상황.
근데 플러그인/스킬 형태로 정의된 지식은 성격이 달라요.
하나의 hitl-policy.md가: LLM이 읽으면 → 정확한 시스템 프롬프트 (에이전트 행동 규칙) 사람이 읽으면 → 업무 가이드라인 (온보딩 매뉴얼) 업데이트하면 → 팀원 전체 에이전트 행동 즉시 업데이트
문서가 “기록”에서 **”실행”**으로 바뀌는 거예요.
제가 직접 운영하면서 느낀 건, .claude/agents/ 폴더에 있는 에이전트 md 파일들이 정확히 이 역할을 한다는 거였어요. 제 에이전트 14개의 행동 규칙이 md 파일에 들어있는데, 이 파일을 수정하면 다음 세션부터 에이전트 행동이 바로 바뀌거든요.
노션에 “에이전트 이렇게 쓰세요” 문서를 따로 만들 필요가 없어요. 에이전트 설정 파일 자체가 문서이자 실행 코드입니다.
이게 진정한 SSOT예요. 문서와 실행이 분리되지 않으니까 낡을 수가 없는 거죠.
마켓플레이스 — 워크플로우를 배포하는 시대
2026년 3월 현재, Claude Code 마켓플레이스가 공식 출시되면서 이 구조가 팀을 넘어 조직 단위로 확장 가능해졌어요.
Configuration Hierarchy (설정 계층)
Organization level ← 보안 정책, 승인된 플러그인, 컴플라이언스
↓
Team level ← 팀 워크플로우, 공유 플러그인, 코딩 표준
↓
Project level ← 프로젝트 의존성, 커스텀 에이전트
↓
Individual level ← 개인 설정, API 키
이 계층 구조 어디서 많이 보지 않았나요? CSS 캐스케이딩이랑 똑같은 원리예요. 상위에서 정한 규칙이 하위로 전파되고, 하위에서 필요하면 오버라이드.
팀장이 우리 팀만의 lint 규칙, Git 브랜치 전략, 테스팅 정책을 플러그인으로 패키징해서 Private Registry에 올린다고 상상해보세요. 팀원은 명령어 하나로 이걸 내려받아요. 기존 린터가 에러를 뱉고 차단했다면, 팀 하네스 플러그인은 팀의 규율에 맞게 에이전트 행동을 교정해주는 가이드 역할을 합니다.
팀별 플러그인 번들 예시
| 팀 | 포함 플러그인 | 핵심 HITL 정책 |
|---|---|---|
| 백엔드 | code-reviewer, test-automator, security-auditor | DB 마이그레이션 전 승인 필수 |
| 프론트엔드 | UI-validator, a11y-checker, SEO-auditor | 디자인 시스템 변경 전 승인 필수 |
| DevOps | cloud-architect, k8s-optimizer, terraform-validator | 인프라 변경 전 플랜 리뷰 필수 |
| 결제팀 | payment-flow-checker, PCI-compliance | 금액 관련 로직 변경 전 승인 필수 |
이 표에서 공통점이 보이시죠? 모든 팀에 “~전 승인 필수”가 있어요. 이게 HITL이 팀 표준의 핵심인 이유입니다.
4단계 적용법 — 내일 당장 시작하는 방법
이론이 아무리 좋아도 실행 안 하면 의미 없잖아요.
제가 직접 하네스 시스템을 구축하면서 정리한 적용 순서예요.
Step 1. HITL 정책부터 합의하세요 (가장 먼저)
도구 고르기 전에 이것부터 하세요. 팀 미팅 30분이면 됩니다.
# hitl-policy.md ## AI가 알아서 해도 되는 것 - 코드 포맷팅, lint 수정 - 테스트 작성 및 실행 - 로그 분석, 에러 메시지 해석 - 코드 리뷰 초안 작성 ## 반드시 사람이 확인해야 하는 것 - 프로덕션 DB 쿼리 실행 - 외부 API 호출 (비용 발생) - 배포 명령 실행 - 보안 관련 코드 변경 - 스펙에 없는 케이스 결정 ## AI가 즉시 멈춰야 하는 상황 - DELETE/DROP WHERE 없는 쿼리 - 비용 추정 $50 초과 - 'production', 'prod', 'live' 키워드 포함 명령
이걸 팀 전체가 합의하는 게 첫 번째이자 가장 중요한 단계입니다.
Step 2. 팀 컨텍스트를 md 파일로 작성
도메인 용어, 아키텍처 제약, 코드베이스 핵심 파일 3개를 team.md에 적어요.
# 팀 컨텍스트 ## 미션 결제 트랜잭션의 안정성과 정합성 보장 ## 핵심 도메인 용어 | 용어 | 정의 | |------|------| | PG사 | Payment Gateway 사업자 (토스페이먼츠, NHN KCP 등) | | 정산 주기 | PG사가 가맹점에 매출을 입금하는 주기 (D+1~D+3) | | 부분 취소 | 결제 금액 중 일부만 취소하는 트랜잭션 | ## AI가 반드시 알아야 할 제약 - 결제 금액은 항상 원화(KRW) 기준 - 외부 PG API 응답 시간 SLA는 200ms 이내 - 테스트 시 실제 결제 발생 절대 금지 ## 코드베이스 핵심 파일 3개 1. `src/payment/PaymentService.ts` — 결제 핵심 비즈니스 로직 2. `src/settlement/SettlementBatch.ts` — 정산 배치 처리 3. `config/pg-credentials.ts` — PG사 연동 설정
이 파일이 Executable SSOT가 되는 거예요. 새 팀원이 오면 이 파일 읽으면 되고, AI도 이 파일 읽으면 우리 팀 맥락을 바로 이해합니다.
Step 3. 워크플로우 파이프라인 정의
oh-my-claudecode 스타일로 plan → exec → verify 3단계만 먼저 만드세요.
/team-plan {기능 요청}
→ context/team.md 로드
→ 요구사항 분석 + 영향 범위 파악
→ 구현 방안 2-3개 제시
→ ⛔ HITL: 방향 선택 사람 확인
/team-exec
→ 합의된 방향으로 TDD 구현
→ ⛔ HITL: 핵심 로직 완료 시 코드 리뷰
/team-verify
→ 테스트 전체 통과 확인
→ domain-rules.md 위반 없는지 대조
→ ⛔ HITL: 배포 승인
Step 4. 파일럿 1명 → 측정 → 팀 배포
처음부터 팀 전체에 뿌리지 마세요. 한 명이 2주 동안 써보면서 이 세 가지를 측정합니다:
| 측정 항목 | 측정 방법 | 기대 효과 |
|---|---|---|
| 리드타임 | 기능 요청~배포까지 시간 | 30-50% 단축 |
| 재작업률 | PR 코멘트 수 / PR 수 | 코멘트 40% 감소 |
| 의사결정 피로 | 일일 HITL 승인 횟수 | 3-5회/일 이하 |
2주 뒤 데이터로 팀에 공유하면, “이거 써볼까?” 같은 설득이 아니라 숫자로 보여주는 게 됩니다.
내가 느낀 점 — 하네스를 운영하면서 달라진 것들
저는 2026년 2월부터 개인 Obsidian 볼트에 하네스 시스템을 구축하기 시작했어요. 처음엔 binance-auto-trader라는 자동매매 봇 하나에 런타임 하네스(runtime_harness.py + harness_ctl.sh)를 붙이는 것부터 시작했는데요.
그 과정에서 깨달은 게 있어요.
런타임 하네스(프로세스 안 죽게)와 팀 하네스(워크플로우 표준화)는 층위가 다르지만 같은 원리라는 것.
둘 다 핵심은 이거예요: “매번 다시 생각하지 않아도 안정적으로 실행되는 구조를 만드는 것.”
런타임 하네스가 “이 프로세스 지금 살아있나?”를 보장한다면, 팀 하네스는 “이 노하우를 팀 전체가 쓰고 있나?”를 보장합니다.
제가 28개 스킬과 14개 에이전트를 운영하면서 가장 많이 한 실수는, HITL 없이 전부 자동화하려 했던 거예요. 블로그 글쓰기를 완전 자동화하니까 품질이 들쭉날쭉하더라고요. 결국 blog-reviewer라는 별도 검증 에이전트를 만들고, “쓰는 사람 ≠ 검증하는 사람” 원칙을 적용했더니 품질이 안정됐어요.
이게 HITL의 본질이에요. 자동화 100%가 아니라 자동화 80% + 사람 검증 20%. 이 20%가 전체 품질의 80%를 결정합니다.
앞으로 내가 할 것들
이 글을 쓰면서 정리된 제 다음 행동 3가지예요.
1. hitl-policy.md를 모든 프로젝트에 추가
지금 제 하네스 시스템에는 런타임 체크리스트는 있는데, HITL 정책이 명시적으로 없어요. 이번 주 안에 프로젝트별로 “AI가 해도 되는 것 / 사람이 봐야 하는 것” 리스트를 만들겠습니다.
2. 워크플로우 로그를 데이터 플라이휠로
Toss 아티클에서 가장 흥미로웠던 건 “워크플로우 로그가 고품질 Instruction Tuning 데이터셋이 된다”는 가설이에요. 플러그인으로 규격화된 데이터가 쌓이고 → 도메인 특화 모델 파인튜닝에 쓰이고 → 더 정확한 워크플로우가 나오는 선순환. 아직 가설이지만, 방향은 맞다고 봐요. 저도 에이전트 로그를 구조화해서 저장하기 시작하겠습니다.
3. 팀에 전파하기 전에 “마찰 비용” 먼저 줄이기
Toss가 강조한 Frictionless가 인상 깊었어요. 터미널 밖으로 나가는 순간 Context Switching 비용이 발생한다는 거. 제가 만든 하네스도 터미널 안에서 끝나게 설계되어 있는데, 팀원이 쓸 때도 그래야 해요. 설치 명령어 1개, 실행 명령어 1개. 이 두 개로 끝나지 않으면 아무도 안 씁니다.
데이터 플라이휠 가설 — 먼 미래지만 가야 할 방향
마지막으로 좀 더 먼 이야기를 해볼게요.
지금 만드는 팀 하네스는 단순히 작업을 돕는 도구가 아닐 수 있어요. 고품질 Instruction Tuning 데이터셋을 찍어내는 공장이 될 수 있습니다.
팀 하네스(플러그인)를 통해 규격화된 작업 데이터 축적
↓
도메인 특화 모델(sLLM) 파인튜닝
↓
기존 워크플로우가 평가 기준 역할
↓
더 정확한 에이전트 → 더 많은 사용 → 더 많은 데이터
↓
🔄 선순환 (Data Flywheel)
물론 이 플라이휠이 돌아가려면 전제가 있어요. 충분한 데이터 수집 기간, 품질 관리 프로세스, 조직의 지속적인 투자 의지.
하지만 한번 돌아가기 시작하면, 사용할수록 데이터가 쌓이고 → 쌓일수록 모델이 정교해지고 → 정교해질수록 더 많이 사용되는 선순환이 만들어집니다.
이건 아직 가설의 영역이에요. 하지만 방향은 분명합니다.
결국 중요한 건 이거예요
도구는 준비되었어요.
Claude Code 마켓플레이스, oh-my-claudecode Team 모드, 플러그인 생태계 — 기술적으로 팀 워크플로우를 표준화할 수 있는 인프라는 다 갖춰졌습니다.
남은 건 하나예요.
“AI가 알아서 할 것”과 “반드시 사람이 볼 것”의 경계를 팀이 합의하는 것.
hitl-policy.md 파일 하나.
거기에 팀의 도메인 규칙, 용어, 제약 조건을 담은 team.md 파일 하나.
이 두 개만 있으면, 팀에서 LLM 제일 잘 쓰는 사람의 노하우를 /team-plan 명령어 하나로 전체 팀에 배포할 수 있어요.
LLM 활용 능력이 개인의 센스 영역에 머물러 있으면, 팀 생산성은 가장 못 쓰는 사람에 맞춰져요. 하지만 팀 하네스가 있으면, 저점(Floor)이 가장 잘 쓰는 사람 수준으로 올라갑니다.
그게 Raising the Floor이고, 그게 Software 3.0 시대에 팀이 해야 할 가장 중요한 일입니다.
FAQ
Q: HITL을 너무 많이 넣으면 오히려 느려지지 않나요?
A: 맞습니다. HITL이 과도하면 “매번 물어보는 귀찮은 도구”가 됩니다. 원칙은 위험도와 복구 비용이 높은 곳에만 배치하는 것입니다. 코드 포맷팅에 승인을 요구하면 안 되고, 프로덕션 배포에는 반드시 필요합니다. 실전에서는 하루 HITL 승인 횟수가 3-5회를 넘지 않도록 설계하세요.
Q: 우리 팀은 아직 AI 도구를 거의 안 쓰는데, 하네스가 필요할까요?
A: 오히려 지금이 적기입니다. 각자 다른 방식으로 쓰기 시작한 후에 표준화하는 것보다, 처음부터 팀 기준을 잡아놓는 게 훨씬 쉽습니다. hitl-policy.md 하나만 먼저 만들어두세요.
Q: oh-my-claudecode vs oh-my-opencode 어떤 걸 써야 하나요?
A: 2026년 3월 기준, oh-my-opencode(Star 36,872)는 생태계가 더 크고 모델 중립적이며, oh-my-claudecode(Star 8,313)는 Claude Code에 최적화되어 있습니다. 팀이 Claude Code를 주로 쓴다면 OMC, 모델을 혼용한다면 oh-my-opencode를 추천합니다. 핵심은 도구 선택보다 HITL 정책을 먼저 정의하는 것입니다.
Q: Executable SSOT와 기존 위키의 차이가 뭔가요?
A: 위키 문서는 사람만 읽고, 업데이트를 까먹습니다. Executable SSOT(예: .claude/agents/ md 파일)는 AI가 매 세션 시작할 때 자동으로 읽고 실행합니다. 파일을 수정하면 다음 세션부터 행동이 바로 바뀌므로, 문서와 실행 사이에 괴리가 생기지 않습니다.
Q: 개인 개발자도 팀 하네스를 만들 의미가 있나요?
A: 있습니다. 저도 1인 운영이지만, 28개 스킬에 각각 규칙을 정의해두니 세션이 바뀌어도 일관된 품질이 나옵니다. “미래의 나”도 팀원이라고 생각하면 됩니다. 3개월 뒤의 내가 지금 설정한 hitl-policy.md를 보고 바로 작업할 수 있으면 성공입니다.
참고 자료
- Software 3.0 시대, Harness를 통한 조직 생산성 저점 높이기 — Toss Tech
- 소프트웨어 3.0 시대를 맞이하며 — Toss Tech
- Andrej Karpathy: Software Is Changing (Again) — Y Combinator
- oh-my-claudecode — GitHub
- Claude Code Marketplace — Anthropic
🏷️ #AI워크플로우 #하네스 #HITL #마켓플레이스 #Software3.0 #팀생산성 #ClaudeCode #컨텍스트엔지니어링