유튜브2026-02-28

기획부터 PR까지 AI 100%, 하네스 엔지니어링 실전기

플러그팀이 주 2개에서 10개로 스프린트를 늘린 7단계 AI 에이전트 워크플로우 공개

똑똑한개발자 플러그팀의 AI 하네스 엔지니어링 워크플로우 개요

• 플러그 팀은 Claude Opus·Sonnet을 역할별로 배치한 7단계 AI 하네스 워크플로우를 구축했습니다.
• 에이전트 A(Codex)와 B(Opus)가 UX 토론으로 시안 3개를 도출하고, 인간은 선택과 미세 조정만 담당합니다.
• 도입 후 주당 스프린트가 2~3개에서 10개로 약 4배 증가, 피그마 없이도 디자인 품질이 상승했습니다.

하네스 엔지니어링으로 AI 에이전트가 기획부터 PR까지 주도하는 B2B SaaS 개발 환경, 실제로 가능할까요?

똑똑한개발자의 플러그(pluuug) 팀은 하네스 엔지니어링 기반 7단계 워크플로우를 구축해 주당 스프린트를 2~3개에서 10개로 늘렸습니다. 그 실전 구조를 PO 다희님과의 인터뷰로 공유합니다.

유튜브에서도 보실 수 있습니다.

1. 프롬프트 너머의 시스템: 왜 하네스(Harness)인가?

하네스 엔지니어링(Harness Engineering)이란, LLM이 예측 가능한 범위 내에서 움직이도록 가드레일·스킬 가이드·에이전트 간 상호 검증을 설계하는 방법론입니다. 단순히 질문을 잘 던지는 프롬프트 엔지니어링을 넘어, AI의 불확실성을 구조로 통제해 실무 수준의 결과물을 얻도록 하는 시스템이죠.

단순히 질문을 잘 던지는 프롬프트 엔지니어링만으로는 실무 수준의 복잡한 SaaS를 만들 수 없습니다. LLM은 본질적으로 결과값이 불확실하고, 대화가 길어지면 맥락을 놓치거나 모순된 코드를 짜는 경우도 있거든요.

그래서 저희는 하네스를 채웠습니다. AI가 예측 가능한 범위 내에서 움직이도록 가드레일을 치고, 원하는 결과물로 유도하는 ‘깔때기’를 설계한 것이죠. 이는 단순히 유행을 따른 것이 아니라, 실제 스프린트 속도를 높이기 위해 ‘필요에 의해’ 탄생한 실전 방법론으로 봐주시면 됩니다.

2. [실전 워크플로우] AI 에이전트가 일하는 7가지 단계

플러그 팀의 하네스 시스템은 테스크의 성격에 따라 모델을 다르게 배치하고, 에이전트 간의 ‘상호 검증’을 거칩니다.

AI 에이전트 7단계 워크플로우 전체 흐름도

① 테스크 지시서와 스킬 기반 설계

사람은 백로그에 제목만 던집니다. 그러면 시스템 내부에 미리 정의된 스킬(Skill)가이드가 적용되어, 누락과 모순이 없는 완벽한 MD 형태의 테스크 지시서가 자동 생성됩니다.

② 맥락 분석과 4가지 경로 분기

AI가 현재의 코드베이스와 디자인 가이드를 분석합니다. 이 단계에서 작업의 난이도를 스스로 판단하죠.

  • 신규 설계 / 기존 개편 / 기능 추가: 복잡한 UX 토론 단계로 진입

  • 버그 수정: 복잡한 스텝을 생략하고 즉시 구현(One-mode)으로 직행

에이전트 A(Codex) vs B(Opus) UX 끝장 토론 구조

③ 에이전트 A(Codex) vs B(Opus)의 UX 끝장 토론

신규 설계의 경우, 서로 다른 페르소나를 가진 에이전트들이 호출됩니다.

에이전트 A (Codex)
• 성향: 급진적·창의적
• 역할: 새로운 아이디어 제안
• 강점: 기존 틀 밖의 UX 발굴

에이전트 B (Opus)
• 성향: 논리적·안정적
• 역할: 구조·일관성 검증
• 강점: 반론·리스크 식별

사회자 AI
• 성향: 중립적·균형
• 역할: 중재·시안 3개 도출
• 강점: A/B 의견 통합
  • 에이전트 A: 급진적이고 창의적인 아이디어 제안

  • 에이전트 B: 논리적이고 안정적인 구조 강조 이들은 서로의 기획안에 반론을 제기하며 결과물을 깎아 나갑니다. 여기에 사회자 AI가 개입해 중재안을 내놓고, 서로 다른 성격의 고퀄리티 시안 3개를 도출합니다.

모델 최적화: Sonnet 프로토타이핑 + Opus 풀 구현

④ 모델 최적화: Prototyping(Sonnet) & Implementation(Opus)

모든 과정에 가장 비싼 모델을 쓰지 않습니다!

Claude Sonnet (Prototyping)
• 용도: 프로토타이핑·초안 코드
• 비용: 저렴
• 조건: 기획 문서가 촘촘할 때

Claude Opus (Implementation)
• 용도: API 연동·차트·에러 처리
• 비용: 높음
• 조건: 실제 서비스 반영 코드

👉 Anthropic 공식 모델 비교 링크

⑤ 인간의 결정과 QA

사람은 중간에 개입해 AI가 차려놓은 3가지 시안 중 하나를 확정(A, B, C 선택)합니다. 구현이 끝난 후에는 터미널에서 텍스트를 치는 대신, AI가 만든 결과물을 확인하며 세부적인 디자인 간격(예: 12px → 8px) 정도만 피드백을 줍니다.

하네스 도입 후 주당 스프린트 2~3개 → 10개 증가 추이

⑥ 레슨런과 가이드 승격

이 시스템의 핵심은 성장입니다. 사람이 준 피드백 중 긍정적인 내용이 반복되면, 이를 아예 ‘스킬 가이드’로 승격시켜 다음 스프린트에서 AI가 자동으로 적용하게 합니다. 시간이 갈수록 팀에 맞춤화된 ‘슈퍼 개발자’가 탄생하는 구조입니다.

⑦ PR 생성 및 코드 리뷰

최종 결과물은 깃허브에 PR로 올라가며, 코드 레빗과 같은 툴을 통해 팀의 컨벤션에 맞는지 다시 한번 자동 리뷰를 거칩니다.

👉 CodeRabbit 공식 링크

3. “피그마를 버리니 디자인 퀄리티가 올라갔다?”

플러그 PO 다희님의 발언 중 가장 인상적이었던 부분입니다. 보통 디자이너들은 피그마를 필수 도구로 생각하지만, 다희님은 ‘피그마는 스티커 덩어리’라고 표현해주셨거든요.

프로덕트 구현에 있어서 피그마의 한계

  • 인터랙션이나 애니메이션의 세밀한 강조점을 전달하기 어렵고, 결국 텍스트로 설명해야 했어요.

피그마를 버리고 AI로 디자인 한 결과

  • AI에게 직접 디자인 시스템과 코드베이스를 맡기니, 텍스트 레이아웃부터 섹션 구조까지 개발 언어 위에서 훨씬 더 정교한 ‘라이브 디자인’이 가능해졌습니다.

4. 실무에 하네스 도입 결과: 주당 2~3개에서 10개의 스프린트로 전환!

이 하네스 시스템은 불과 몇 주 만에 결과로 증명되었습니다.

  • 생산성: 기존 한 주에 2~3개 처리하던 테스크를 현재 열 개 가까이 쳐내고 있습니다.

  • 안정성: “이상하다”는 생각이 들지 않을 정도로 코드 퀄리티와 디자인 만족도가 높습니다.

  • 효율: 불필요한 직무 간 커뮤니케이션 리소스를 줄이고, 오직 ‘사업적 가치’에 집중하는 환경이 구축되었습니다.

5. 여러분의 팀에도 ‘하네스’가 필요합니다.

AI가 모든 것을 대신해 주는 시대는 이미 왔습니다.

중요한 건 AI를 어떻게 다루느냐가 아니라, AI가 우리 팀의 맥락을 이해하고 스스로 사고하게 만드는 시스템을 갖췄느냐입니다.

저희 똑똑한개발자는 단순히 AI 툴을 사용하는 법을 넘어, 하네스 엔지니어링과 같은 구조적 혁신을 통해 파트너사의 비즈니스를 가속화합니다.

  • 우리 서비스에 맞는 맞춤형 AI 에이전트를 구축하고 싶으신가요?

  • 개발 프로세스 자동화로 압도적인 생산성을 경험하고 싶으신가요?

지금 바로 똑똑한개발자의 문을 두드려 주세요. 저희의 노하우를 바탕으로 여러분의 비즈니스에 딱 맞는 AI 워크플로우를 설계해 드립니다. 🙇‍♂️

자주 묻는 질문 (FAQ)

Q1. 하네스 엔지니어링과 프롬프트 엔지니어링은 무엇이 다른가요?

A1. 프롬프트 엔지니어링이 ‘한 번의 질문을 잘 던지는 기술’이라면, 하네스 엔지니어링은 ‘여러 에이전트와 모델이 상호 검증하며 움직이는 시스템을 설계하는 기술’입니다. 플러그 팀은 스킬 가이드·경로 분기·모델별 역할 분담을 구조화해 결과의 불확실성을 줄였습니다.

Q2. 작은 팀도 하네스 시스템을 도입할 수 있나요?

A2. 네. 핵심은 도구 수가 아니라 ‘스킬 가이드 승격 루프’입니다. 1인 개발자라도 반복되는 피드백을 가이드로 저장해두면 다음 스프린트에서 자동 적용됩니다. 초기에는 테스크 지시서 자동 생성부터 시작하는 것을 권장합니다.

Q3. 왜 Sonnet과 Opus를 나눠서 쓰나요? Opus만 쓰면 안 되나요?

A3. 비용 효율 때문입니다. 기획 문서가 촘촘하면 Sonnet도 프로토타입 수준의 코드를 충분히 뽑습니다. Opus는 API 연동·차트 렌더링처럼 오류 허용치가 낮은 구간에만 투입해 토큰 비용을 최적화합니다.

Q4. 피그마를 정말 완전히 버렸나요?

A4. 프로덕트 구현 단계에서의 중심 도구에서 제외했다는 의미입니다. 초기 무드보드·레퍼런스 수집은 여전히 유효하지만, 인터랙션·애니메이션이 포함된 실제 구현은 AI에게 코드베이스를 직접 맡기는 쪽이 더 빠르고 정교했습니다.

Q5. 코드 레빗 같은 리뷰 툴은 필수인가요?

A5. 필수는 아니지만 권장합니다. 팀 컨벤션을 자동 검증하는 단계가 있어야 ‘사람의 마지막 방어선’이 과부하되지 않습니다. CodeRabbit·Graphite 등 어떤 툴이든 PR 단계에서 컨벤션 체크가 자동화되는 것이 핵심입니다.

[비즈니스 협업 및 도입 문의]

[함께보면 좋은 글]

클립보드에 복사되었어요 ✓
이 글을 공유해보세요!