하네스 엔지니어링으로 제언작성하기

4월 16일 오후부터 17일까지 거의 이틀 동안 하네스 엔지니어링 방식으로 제언문을 작성해 보았다. 그 과정에서 API 비용도 적지 않게 들었고, 세션을 여러 번 다시 시작해야 했다. "이 정도면 충분하겠지"라고 생각했던 설정도 실제로는 부족했고, 원하는 결과를 얻기까지 다섯 번이나 구조를 바꾸어 시도했다.

첫 요청이 가장 중요하다

하네스 엔지니어링에서 가장 중요한 것은 시작할 때 무엇을, 왜, 어떤 방식으로 분석할 것인지 명확히 정하는 일이다.

목적이 불분명한 상태에서 구조만 먼저 만들면, 에이전트는 그럴듯한 결과를 낼 수는 있어도 내가 정말 원하는 결과에는 도달하지 못한다.

따라서 먼저 분석의 목적, 기대하는 산출물, 필요한 관점과 범위를 분명히 한 뒤에 하네스를 설계해야 한다.

페르소나 설정이 결과의 톤을 바꾼다

정책 담당자, 발행사 대표, 학습분석 전문가, 효과성 분석 전문가처럼 어떤 역할을 부여하느냐에 따라 결과물의 언어와 강조점이 달라졌다.

같은 주제를 다루더라도 누구의 시각으로 접근하느냐에 따라 보고서의 해석과 결론이 달라질 수 있다.

결국 페르소나 설정은 단순한 형식이 아니라, 연구와 분석의 톤을 결정하는 중요한 장치였다.

각 단계마다 사람의 검토가 필요하다

에이전트가 다음 단계로 넘어갈 때마다 AI가 스스로 점검하도록 만들 수도 있지만, 실제로는 사람이 중간중간 검토하는 과정이 훨씬 중요했다.

특히 처음 만드는 자동화 작업이라면, 프롬프트나 스킬에 내가 원하는 의도가 정확히 반영되었는지 반드시 확인해야 한다.

이를 쉽게 말하면 요청 전 - 진행 중 - 결과 확인 후의 세 지점에서 계속 점검하는 방식이다.

요청 전에는 무엇을 원하는지 예시와 기준을 포함해 분명히 전달해야 한다.

진행 중에는 에이전트가 엉뚱한 방향으로 가지 않는지 살펴봐야 한다.

결과가 나온 뒤에는 지금 나온 산출물이 실제 목적에 맞는지 검증해야 한다.

자료는 많다고 좋은 것이 아니다

자료가 너무 많으면 사람도 무엇부터 봐야 할지 혼란스럽고, AI도 핵심을 놓치기 쉽다.

그래서 현재 작업에 꼭 필요한 자료만 남기고, 관련 없는 자료는 과감히 제외하는 편이 더 좋은 결과로 이어졌다.

하네스 역시 하나의 프로젝트에는 하나의 분명한 목적을 갖도록 설계하는 것이 좋았다.

여러 목적을 한 구조 안에 동시에 넣으면, 에이전트가 서로 다른 요구를 섞어 처리하면서 결과의 일관성이 무너질 수 있다.

모델 선택은 성능만이 아니라 효율의 문제다

어떤 모델이 더 뛰어난가에 대한 평가는 늘 엇갈린다. 실제로 써보면 속도, 비용, 응답 길이, 안정성 사이에서 각기 다른 장단점이 있다.

중요한 것은 가장 높은 성능의 모델을 무조건 쓰는 것이 아니라, 현재 작업을 충분히 수행할 수 있는 수준의 모델을 고르는 일이다.

특히 장시간 분석 작업에서는 토큰 소모와 비용도 함께 고려해야 하므로, "최고 성능"보다 "지속 가능한 운영"이 더 중요할 때가 많다.

아직은 AI만으로 자동화하기 어렵다

적어도 지금 단계에서는, 의도가 중요한 작업을 AI만으로 완전히 자동화하는 것은 쉽지 않다고 느꼈다.

간단한 테스트 작업이나 반복 업무는 AI만으로도 상당 부분 자동화할 수 있다.

그러나 연구, 기획, 설계처럼 판단과 맥락이 중요한 작업에서는 사람의 경험과 감각이 반드시 개입되어야 한다.

우리가 가진 문제의식과 미묘한 판단 기준을 프롬프트만으로 완전히 전달하는 데에는 아직 한계가 있다.

그래서 큰 작업일수록 작은 단계로 나누고, 각 단계마다 검토와 검증을 거치는 방식이 필요하다.

작업을 잘게 나눌수록 내 의도를 더 정확하게 반영할 수 있고, 어떤 부분에서 판단이 필요한지도 더 선명하게 보인다.

결국 하네스 엔지니어링을 잘하려면 도구를 다루는 기술만이 아니라, 작업 자체를 구조화해서 이해하는 힘도 함께 길러야 한다.

목록으로 돌아가기