관리 메뉴

피터의 개발이야기

AI를 잘 쓰는 게 아니라, AI를 통제해야 한다 — Harness Engineering 정리 본문

AI/AI이론 | 공부

AI를 잘 쓰는 게 아니라, AI를 통제해야 한다 — Harness Engineering 정리

기록하는 백앤드개발자 2026. 3. 25. 08:24
반응형

[AI] Peterica의 AI공부와 비젼 정리

ㅁ 들어가며

요즘 AI를 활용한 개발 이야기를 들으면 늘 비슷한 고민으로 돌아온다.
“어떤 모델을 써야 더 잘 나오지?”

하지만 한 영상을 보고 나서 이 질문 자체가 틀렸을 수 있다는 생각이 들었다.
문제는 모델이 아니라, 결과를 만드는 방식에 있었다.

 

ㅁ 왜 AI는 항상 들쭉날쭉할까

Claude를 쓰다가 Codex를 쓰고, 다시 Gemini를 쓰면
같은 요구사항인데도 결과는 매번 달라진다.

  • 어떤 날은 구조가 깔끔하고
  • 어떤 날은 naming이 엉망이고
  • 어떤 날은 아예 설계가 틀어진다

그래서 우리는 보통 이렇게 생각한다.

“더 좋은 모델을 써야겠다”

 

하지만 Harness Engineering은 정반대의 이야기를 한다.

“AI는 믿을 수 없다. 대신 시스템으로 통제해야 한다.”

 

 

ㅁ 본질 — Harness Engineering이란 무엇인가

Harness Engineering은 단순한 프롬프트 기법이 아니다.
AI를 잘 사용하는 방법이 아니라, AI가 원하는 방식으로 출력하도록 만드는 구조 설계 방법론이다.

핵심은 하나다.

모델이 바뀌어도 결과는 같아야 한다

 

이를 위해 다음을 통제한다:

  • 문서 구조
  • 설계 방식
  • 코드 규칙
  • 평가 기준

즉, AI를 도구로 쓰는 것이 아니라
규격화된 생산 시스템 안에 넣는 것이다.

 

 

ㅁ 구조적 해석 — CPS + 개발 파이프라인

이 방식의 중심에는 CPS 프레임워크가 있다.

  • Context: 지금 상황은 무엇인가
  • Problem: 해결해야 할 문제는 무엇인가
  • Solution: 어떻게 풀 것인가

이건 단순 문서가 아니라
팀의 사고 방식 자체를 정렬하는 도구다.

이 CPS는 개발 전체 흐름으로 이어진다:

  1. 요구사항 입력 (비정형 가능)
  2. 회의 및 로그 정리
  3. CPS 구조화
  4. PRD 및 설계 문서 생성
  5. 코드 생성 + 린터 적용
  6. 평가(Evaluation)

여기서 중요한 포인트는 하나다.

코드가 아니라, 프로세스를 통제한다

 

ㅁ 핵심 메커니즘 — “선택지를 제거한다”

AI 결과가 흔들리는 이유는 단순하다.

  • naming이 다르고
  • 파일 구조가 다르고
  • 코드 스타일이 다르기 때문이다

Harness Engineering은 이를 이렇게 해결한다.

린터로 강제한다

  • 파일명 규칙 고정
  • import 순서 고정
  • 구조 패턴 고정

결과적으로,

  • AI가 선택할 수 있는 경우의 수가 줄어들고
  • 출력은 점점 하나로 수렴한다

이건 중요한 관점이다.

좋은 결과는 생성하는 것이 아니라, 제한해서 만든다

 

ㅁ 시스템 관점 — Evaluation이 핵심이다

AI의 결과는 항상 불확실하다.
그래서 Harness Engineering에서는 “평가”가 핵심이 된다.

평가 기준 예시:

  • 문맥 적합성
  • 정확성
  • 데이터 근거
  • 누락 여부

하지만 더 중요한 건 이것이다.

평가 기준은 조직마다 달라야 한다

  • 어떤 조직은 정확성이 우선이고
  • 어떤 조직은 속도가 우선이다

즉, AI 품질은 모델이 아니라
조직이 정의한 기준으로 결정된다


ㅁ 운영 관점 — 왜 이 방식이 중요한가

이 접근은 특히 조직 단위에서 강력하다.

장점:

  • 유지보수 용이
  • 협업 효율 증가
  • 모델 교체에도 안정성 유지
  • 엔터프라이즈 환경에 적합

단점:

  • 초기 설계 비용 큼
  • 유연성 감소
  • AI 입장에서는 비효율적

하지만 실제 개발에서는 명확하다.

유연성보다 일관성이 더 중요하다

 

ㅁ 정리 — AI 시대의 개발 패러다임 변화

우리는 지금까지 이렇게 생각해왔다.

  • 좋은 프롬프트를 만들면 된다
  • 좋은 모델을 쓰면 된다

하지만 이제는 바뀌어야 한다.

  • 프롬프트 중심 → X
  • 모델 중심 → X
  • 시스템 중심 → O

결국 핵심은 이것이다.

좋은 AI 결과는 모델이 아니라, 설계된 시스템에서 나온다

 

ㅁ 함께 보면 좋은 사이트

https://youtu.be/A8PMyC7W_vg?si=scSS4owIgXnZGaG1

반응형
Comments