AI 결과물을 검증하는 4가지 방법

1. 만들기 전에 작업 완성 기준 정하기 => 작업 완성을 판단할 수 있는 구체적이고 정량적인 평가 기준을 작성. 평가 기준을 미리 만들어두어야한다. 작업 끝나고가 아니라(기준을 코드보다 먼저)
   ex) "코드 짜기 전에, 이게 완성되었다고 말할 수 있는 조건을 10개만 적어줘. 각 조건은 내가 직접 눌러서 확인할 수 있는 문자이어야해." => 정량적이어야한다. 애매한 말은 검사가 제대로 x. 그리고 꼭 읽어보고 도메인을 아는 내가 채워야한다. => 그리고나서 이걸 파일로 저장. 작업 완료 후, 새 세션에서 이걸 하나씩 대조해서 코드 검사

2. 코드 리뷰는 작업자에게 맡기지 않는다 => context 를 가지고 있을, 작업을 한 주체 agent가 아닌 이 코드를 처음 보는sub-agent 가능하면 아예 다른 회사 모델 AI에게 맡기기
   ex) "서브에이전트로 결과를 검토해줘"
   ex) 기획-구현-검사 나누기

3. 개발과 읽기 세션은 분리: 수정은 순차적으로, 조사 나 리뷰는 병렬로 -> 같은 파일을 동시에 수정하면 꼬일 수 있음.
   ex) codex /fork: 하던 대화를 복사해 옆 창을 여는 명령. 검사용이 아니라 찾아보기 전용

4. 요약할 때는 정확한 지침. 넘길 때는 5칸

• 그냥 /compact로만 하면 제대로 요약이 안될 수도.
  

대부분은 그 자리에서 검토해줘. 라고 하지만 안된다. 우리가 코드 리뷰를 요청하는 것처럼 개발한 에이전트도 자기가 짠 걸 코드리뷰를 외부에게 받아야한다. 처음 보는 에이전트가 문제를 훨씬 잘 찾는다. 작업자에게 물으면 맥락이 있으니 복습이 될 뿐. 같은 회사의 모델은 같은 걸 배웠다. opus5는 자기 결과물을 검증하는 하네스가 내장하긴 했지만 여전한 함정.

난이도 있는 개발을 하다보면 모델이 수렁에 빠져 탈출하기 어려운 경우가 있는데요 ㅎㅎ 이럴때는 고쳐달라는 프롬프트를 바꿔야해요. 예를 들어 ”지금까지의 이런 시도들을 했는데 모두 실패했으니 근본적인 해결책을 찾아줘. 잘 모르겠으면 리서치를 먼저해봐.“ 이런식으로요
그래도 안되면 다른 모델의 도움을 받는 것이 좋습니다

링크

개발자의 지옥

• 이전에는 튜토리얼 헬(강의만 듣고 개발 x) -> 프레임워크 헬(배우는 속도 < 나오는 속도) -> 스킬 헬(좋은 스킬 판별 불가)
• 좋은 스킬 채점표 4단

1. 트리거: 누가 부르냐(사용자 vs 모델 호출)

• 인지 부하 vs Context 부하 (설명문이 대화 context에 상주, 예측 불가능성)
• superpowers는 대부분 모델 호출
• 뭘 포기할지의 문제다.

2. 구조: 내용물은 딱 2종류

• agent가 밟아가는 순서와 참고자료 ref.
• 가끔 쓰는 자료를 밖으로
  
  
  

3. 유도: 적어왔는데 안 한다.

• 그래서 길게 설명을 늘여놓은데, leading word를 사용하자. => vertical slice
• plan 모드: 2~3개만 물어보고 목표인 계획 만들기가 되버리지않나?
  

해법: 스킬을 쪼개서, 미래를 숨긴다. 즉, 질문 skill/계획 skill 따로 두어서 질문 skill은 계획을 짜는건지를 모르도록

4. 가지치기: 거대한 스킬은 증상이다. - 지워도 결과가 같다면 지워라.

스킬 저장소
링크

grill-me: 나를 인터뷰하게하는 스킬

스킬은 확률적인 시스템에서 예측가능성을 짜내는 장치. 매번 같은 답이 아닌 방식을! 필요한 건 새 스킬이 아니라, 지워보는 눈

하네스 엔지니어링 정말 제대로 쓰고 있나?

달은 안 보고 손가락만 보고 있다.

손가락

• 어떤 모델을 쓸까
• 토큰 절약 꿀팁
• 칼퇴 필수 스킬

뭘 하고자 하는가를 잘 달성하게 해주는 게 '하네스'이다.

• Agent = model + harness
  - 모델을 바꿀 수 없으니 이를 감싸는 환경을 건드는 것
  - 모델은 확률로 움직인다. 그 한번이 장애다.

인프라를 통한 방지

• deny설정과 같이 반드시 지켜야할 요소는 개인 설정이 아니라, 프로젝트 규칙에 박아둔다. 장애를 막는 건 습관이 아니라, 인프라이다.

처음부터 완벽하지말자

• 오히려 모델이 매턴 context 증가, 안 쓰이는 규칙 잔뜩
• 가면서 최적화. 하네스는 설계도가 아니라 사고 이력으로 짓는 것.
• 통용되는 하네스는 없다. 프로젝트에 맞게 깎여나가는 것

• 하네스는 다르더라도 위 4계층을 지켜보자.

당장 적용해볼만한 것들

• deny 규칙: 최소한 위험한 명령에 대해 작성
  
  

• 검증은 자동
  

• 먼저 감싸야할 일: 반복되는 일, 사고나면 비싼 일

링크