| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 |
- CKA 기출문제
- SRE
- CKA
- 코틀린 코루틴의 정석
- CloudWatch
- 공부
- tucker의 go 언어 프로그래밍
- Linux
- go
- 정보처리기사 실기 기출문제
- HARNESS
- MySQL
- kotlin coroutine
- Java
- kotlin
- AI
- 티스토리챌린지
- Pinpoint
- 오블완
- LLM
- Spring
- PETERICA
- Rag
- 기록으로 실력을 쌓자
- 바이브코딩
- minikube
- aws
- AWS EKS
- golang
- Kubernetes
- Today
- Total
피터의 개발이야기
AI를 잘 쓰는 게 아니라, AI를 통제해야 한다 — Harness Engineering 정리 본문
ㅁ 들어가며
요즘 AI를 활용한 개발 이야기를 들으면 늘 비슷한 고민으로 돌아온다.
“어떤 모델을 써야 더 잘 나오지?”
하지만 한 영상을 보고 나서 이 질문 자체가 틀렸을 수 있다는 생각이 들었다.
문제는 모델이 아니라, 결과를 만드는 방식에 있었다.
ㅁ 왜 AI는 항상 들쭉날쭉할까
Claude를 쓰다가 Codex를 쓰고, 다시 Gemini를 쓰면
같은 요구사항인데도 결과는 매번 달라진다.
- 어떤 날은 구조가 깔끔하고
- 어떤 날은 naming이 엉망이고
- 어떤 날은 아예 설계가 틀어진다
그래서 우리는 보통 이렇게 생각한다.
“더 좋은 모델을 써야겠다”
하지만 Harness Engineering은 정반대의 이야기를 한다.
“AI는 믿을 수 없다. 대신 시스템으로 통제해야 한다.”
ㅁ 본질 — Harness Engineering이란 무엇인가
Harness Engineering은 단순한 프롬프트 기법이 아니다.
AI를 잘 사용하는 방법이 아니라, AI가 원하는 방식으로 출력하도록 만드는 구조 설계 방법론이다.
핵심은 하나다.
모델이 바뀌어도 결과는 같아야 한다
이를 위해 다음을 통제한다:
- 문서 구조
- 설계 방식
- 코드 규칙
- 평가 기준
즉, AI를 도구로 쓰는 것이 아니라
규격화된 생산 시스템 안에 넣는 것이다.
ㅁ 구조적 해석 — CPS + 개발 파이프라인
이 방식의 중심에는 CPS 프레임워크가 있다.
- Context: 지금 상황은 무엇인가
- Problem: 해결해야 할 문제는 무엇인가
- Solution: 어떻게 풀 것인가
이건 단순 문서가 아니라
팀의 사고 방식 자체를 정렬하는 도구다.
이 CPS는 개발 전체 흐름으로 이어진다:
- 요구사항 입력 (비정형 가능)
- 회의 및 로그 정리
- CPS 구조화
- PRD 및 설계 문서 생성
- 코드 생성 + 린터 적용
- 평가(Evaluation)
여기서 중요한 포인트는 하나다.
코드가 아니라, 프로세스를 통제한다
ㅁ 핵심 메커니즘 — “선택지를 제거한다”
AI 결과가 흔들리는 이유는 단순하다.
- naming이 다르고
- 파일 구조가 다르고
- 코드 스타일이 다르기 때문이다
Harness Engineering은 이를 이렇게 해결한다.
린터로 강제한다
- 파일명 규칙 고정
- import 순서 고정
- 구조 패턴 고정
결과적으로,
- AI가 선택할 수 있는 경우의 수가 줄어들고
- 출력은 점점 하나로 수렴한다
이건 중요한 관점이다.
좋은 결과는 생성하는 것이 아니라, 제한해서 만든다
ㅁ 시스템 관점 — Evaluation이 핵심이다
AI의 결과는 항상 불확실하다.
그래서 Harness Engineering에서는 “평가”가 핵심이 된다.
평가 기준 예시:
- 문맥 적합성
- 정확성
- 데이터 근거
- 누락 여부
하지만 더 중요한 건 이것이다.
평가 기준은 조직마다 달라야 한다
- 어떤 조직은 정확성이 우선이고
- 어떤 조직은 속도가 우선이다
즉, AI 품질은 모델이 아니라
조직이 정의한 기준으로 결정된다
ㅁ 운영 관점 — 왜 이 방식이 중요한가
이 접근은 특히 조직 단위에서 강력하다.
장점:
- 유지보수 용이
- 협업 효율 증가
- 모델 교체에도 안정성 유지
- 엔터프라이즈 환경에 적합
단점:
- 초기 설계 비용 큼
- 유연성 감소
- AI 입장에서는 비효율적
하지만 실제 개발에서는 명확하다.
유연성보다 일관성이 더 중요하다
ㅁ 정리 — AI 시대의 개발 패러다임 변화
우리는 지금까지 이렇게 생각해왔다.
- 좋은 프롬프트를 만들면 된다
- 좋은 모델을 쓰면 된다
하지만 이제는 바뀌어야 한다.
- 프롬프트 중심 → X
- 모델 중심 → X
- 시스템 중심 → O
결국 핵심은 이것이다.
좋은 AI 결과는 모델이 아니라, 설계된 시스템에서 나온다
ㅁ 함께 보면 좋은 사이트
'AI > AI이론 | 공부' 카테고리의 다른 글
| AI를 다루는 방법의 진화(Prompt → Context → Harness → AIOps) (0) | 2026.03.25 |
|---|---|
| [AI] AI Agent는 모델이 아니라 Workflow다 — Claude가 말하는 Agent 설계 패턴 (0) | 2026.03.15 |
| [AI] 개발자가 직접 만드는 Agent Harness - Ralph Loop와 Agentic Workflow Harness의 차이 (0) | 2026.03.11 |
| [AI] LLM 학습 노트 공개 - Transformer부터 RAG까지, 그리고 운영 가능한 AI 시스템을 향해 (2) | 2026.02.10 |
| [AI W3] Reader(LLM) 프롬프트 설계와 Hallucination을 다루는 방법 (0) | 2026.02.10 |
