Intro

너무 똑똑해진 AI, 제대로 시키는 법 - 하네스 엔지니어링 & SDD

하네스?앗..이건 아니고오늘은 최근 한 두달동안 Scene에서 굉장한 이슈가 되고 있는하네스 엔지니어링에 대한 이야기이다."AI한테 일 시키는 것과, AI를 통제하는 것은 전혀 다른 이야기"Intro!AI..

imjaden.tistory.com

지난 글에서 하네스 엔지니어링의 4원칙(Constrain, Inform, Verify, Correct)을 정리했다.
그 이후에 든 생각이 하나 있었다.

"이거 직접 만들어봐야 체감이 되겠는데?"

그래서 만들었다.
Goodboy.ai - 하네스 구조 기반의 회의록 자동화 도구다.

회의록 자동화

단순한 AI 요약 컨텍스트 / 하네스 엔지니어링 기반 검증된 회의록

meeting-minutes-coral.vercel.app

결론부터 말하면,
같은 Claude Haiku 모델인데 하네스 유무에 따라 결과물 품질이 완전히 달랐다.
모델을 바꾼게 아니라 구조를 바꿨다.

일단.. 직접 써보세요!

글로만 읽으면 감이 잘 안올 것 같아서
그래서 이 도구를 블로그 독자분들께만 열어둔다.

사용 방법

1. 링크 들어가기 - https://meeting-minutes-coral.vercel.app

2. 회의 녹취록을 붙여넣거나, 오디오 파일을 업로드 (자동 텍스트 변환)

3. 참석자 입력 (선택)

4. 원하는 섹션 구성 선택

5. AI 설정에서 "액세스 코드로 사용하기" 선택

6. (중요) 아래 코드 입력

beta-2026

7. "생성" 클릭

위 코드를 입력하면 별도 API 키 없이 바로 사용할 수 있다.
하네스가 적용된 AI가 회의록을 생성하고, 검증하고, 필요하면 교정까지 자동으로 진행한다.

사용 전 알아두실 것

이 도구는 블로그 독자분들의 체험용으로 운영되고 있다.
개인 서버 비용으로 제공하는 거라 몇 가지 제한이 있다.

음성 파일 변환	25MB 이하 (약 20~25분 분량)
시간당 변환 가능량	총 2시간 분량 (모든 사용자 합산)
동시 변환	분당 20건
회의록 생성	별도 제한 없음 (액세스 코드 유효 시)

"요청이 많아 일시적으로 제한되었습니다" 라는 메시지가 뜨면, 다른 분이 사용 중인 것
표시된 시간만큼 기다린 뒤 다시 시도하면 된다. 보통 5~10분이면 풀린다.

음성 파일이 25MB보다 클 때

30분 이상 회의 녹음은 25MB를 넘기는 경우가 많다.
이럴 때는 두 가지 방법이 있다.
방법 1 — 클로바노트 활용 (추천)
서비스 화면 우측 상단에 클로바노트 링크가 있다.
클로바노트에서 녹음 파일을 먼저 텍스트로 변환한 뒤, 그 텍스트를 "텍스트 붙여넣기" 탭에 넣으면 된다.
클로바노트는 한국어 인식률이 매우 높고, 무료 플랜으로도 충분히 사용 가능하다.
방법 2 — 파일 나누기
녹음 앱에서 파일을 앞/뒤로 나눠서 각각 올리면 된다.
변환 결과는 자동으로 누적되니까, 두 번에 나눠 올려도 하나의 회의록으로 합쳐진다.

왜 회의록인가?

일단 내가 매주 회의록을 4개 이상 작성하는 PM이기도 하고..
또 회의록이 하네스 효과를 보기 가장 좋은 문서다.

일단 회의록을 쓴다는 행위는

반복 작업이다. 매주, 매일 한다.
품질 기준이 명확하다. 안건, 결정사항, 액션아이템이 있거나 없거나 그렇다.
할루시네이션이 치명적이다. "박 책임이 이렇게 말했다"가 사실이 아니면 큰일난다.

AI한테 "이 회의록 요약해줘"만 하면 어떻게 되는지 다들 경험해봤을 거다.

어떤 날은 완벽하고, 어떤 날은 액션아이템이 통째로 빠져 있다.
이걸 프롬프트로 해결하려고 하면? 매번 프롬프트를 새로 짜야 한다.
하네스로 해결하면? 한 번 구조를 잡아주면 매번 일정한 품질이 나온다.

하네스 4원칙을 어떻게 적용했는가

1. Constrain - "하지 마"를 먼저 정의했다

[절대 금지 사항]
- 회의록에 없는 수치, 일정, 결정사항을 추측하거나 만들어내지 마.
- 특정 참석자의 개인 의견이나 감정 해석을 넣지 마.
- 원본 발언의 의미를 임의로 확대하거나 축소하지 마.
- 결론이 없는 경우 "결론 없음"으로 명시하고, 절대 임의로 결론을 만들지 마.
- "추정", "아마도", "것 같습니다", "예상됩니다" 같은 표현을 절대 쓰지 마.

지난 글에서 말했던 그 한 줄, "하지 말아야 할 것"을 코드 레벨에서 강제했다.
매번, 예외 없이 이게 프롬프트 앞부분에 항상 들어간다.
AI는 "추정입니다"를 자연스럽게 붙이는 습관이 있다.
이걸 명시적으로 금지하지 않으면 회의록에 없는 내용을 AI가 "추정"이라는 단어 하나로 슬쩍 끼워넣는다.

2. Inform - 컨텍스트를 구조화해서 주입했다

[사용자가 입력하는 정보]

회의 날짜, 참석자, 프로젝트명
회의 녹취록 원문
원하는 섹션 구성 (개요, 회의 내용, 액션아이템, 결정사항, 다음 회의 등)

이걸 위젯 시스템으로 만들었다.
사용자가 토글로 "액션아이템은 켜고, 주요 발언은 끄고"를 선택하면,
AI에게 전달되는 출력 명세가 그에 맞게 자동 생성된다.

[출력 형식 — 마크다운으로, 반드시 아래 구조를 지킬 것]

## 회의 기본 정보
- 일시: 2026-03-25
- 참석자: 이소미, 정진협, 신형배 ...

## 회의 내용
안건별로 아래 형식으로 작성:
### 안건 N. {안건 제목}
- 논의 내용: (발언 사실만, 3~5줄)
- 결정사항: (없으면 "미결")

## 액션 아이템
| 담당자 | 할 일 | 기한 |

핵심은, AI가 "어떤 형식으로 써야 하는지"를 고민하지 않게 만든 것이다.
형식은 우리가 정해주고, AI는 내용 채우기에만 집중하게 한다.
지난 글에서 말했던 컨텍스트 엔지니어링의 원칙 그대로다.
모든 정보를 한 번에 쏟아붓는 게 아니라, AI가 필요한 정보만 구조화해서 전달한다.

3. Verify - 결과물을 코드로 검증한다

AI가 회의록을 생성하면, 사람이 보기 전에 코드가 먼저 체크한다.

검증 항목:
- 사용자가 켜놓은 섹션이 전부 포함되어 있는가?
- "추정", "아마도", "것 같습니다", "예상됩니다" 같은 할루시네이션 위험 표현이 있는가?

이게 지난 글에서 말했던 "결과물 받고 나서 체크리스트 1개 만들기"를 자동화한 것이다.
사람이 매번 눈으로 체크하는 게 아니라, 코드가 한다.
체크리스트를 통과하면 → 바로 결과 출력.
통과 못 하면 → 다음 단계로 넘어간다.

4. Correct — 검증 실패 시 자동 교정

Verify에서 문제가 발견되면, AI에게 구체적으로 뭐가 틀렸는지 알려주고 다시 시킨다.

아래 회의록에 문제가 있어:
1. 섹션 누락: 액션 아이템
2. 할루시네이션 위험 표현: "예상됩니다"

위 문제만 수정해서 전체를 다시 작성해줘.

"다시 써줘"가 아니다.
"이 부분이 틀렸으니 이것만 고쳐줘"다.
LangChain이 Terminal Bench 점수를 52.8% → 66.5%로 끌어올렸던 방식과 같은 원리다.
AI가 스스로 "잘 된 것 같다"고 판단하고 멈추는 걸 막고, 실제 검증을 강제한 것.

실제 결과

30분짜리 내부 정례 회의를 돌려봤다.
참석자 8명, 안건 5개, 액션아이템 8건.

하네스 없이 (그냥 "요약해줘")

안건 5개 중 3개만 요약됨 (2개 누락)
액션아이템 기한이 "곧", "빠른 시일 내" 같은 애매한 표현으로 변환됨
결정사항에 "~할 것으로 예상됩니다" 같은 표현 포함 (원문에 없는 내용)

하네스 적용 후

안건 5개 전부 포함
액션아이템 8건, 담당자·기한 전부 원문 기준으로 명시
할루시네이션 표현 0건
Verify 통과 → Correct 단계 미발생 (1회 호출로 완료)

모델은 같은 Claude Haiku 4.5로 했다.

배운 것들

1. 하네스는 "프롬프트를 잘 쓰는 것"의 상위 개념이다

좋은 프롬프트는 Inform에 해당한다. 4개 축 중 1개.
나머지 3개(Constrain, Verify, Correct)를 더해야 비로소 일관된 품질이 나온다.
직접 만들어보니까 이게 이론이 아니라 체감이었다.

2. Verify가 가장 가성비가 좋다

Constrain은 프롬프트에 한 줄 추가하면 된다.
Inform은 어차피 컨텍스트를 주니까 자연스럽다.
Correct는 AI를 한 번 더 호출하니까 비용이 든다.
Verify는 코드로 하기 때문에 비용이 0이다.
그런데 효과는 가장 크다. 섹션 누락, 할루시네이션 표현을 잡아주는 것만으로도 결과물 신뢰도가 확 올라간다.

3. 모델보다 구조가 중요하다

처음에 Claude Sonnet 4.6으로 만들었다가, Haiku 4.5로 내렸다.
비용은 1/3로 줄었는데 품질 차이는 거의 없었다.
왜? 하네스가 구조를 잡아주니까 모델이 할 일이 줄어든 것이다.
Constrain이 범위를 좁혀주고, Inform이 형식을 정해주고, Verify가 검증해주니까,
모델은 "내용 채우기"에만 집중하면 된다.
LangChain이 모델 안 바꾸고 하네스만 바꿔서 Top 30 → Top 5로 간 것과 같은 원리다.

마무리

지난 글의 마지막에 이렇게 썼다.

"하지 말아야 할 것" 한 줄 추가하기 — Constrain
결과물 받고 나서 체크리스트 1개 만들기 — Verify
"기준 문서" 하나 만들어두기 — SDD

이번에 만든 Goodboy.ai는 이 세 가지를 코드로 구현한 것이다.
개념을 읽는 것과 직접 써보는 건 다르다.