초거대 프롬프트 시연이 부른 프롬프팅 vs 하네스 논쟁

밤 11시 5분, 한 참여자가 방에 압도적인 분량의 프롬프트 하나를 올렸다. 클로드코드에 프런트엔드 스킬을 불러오고 외부 참고 저장소까지 지정하며, 모바일에서도 잘 지원되는 웹 터미널을 만들어달라는 지시였다. 저사양 네트워크 대응과 mosh 지원, libghostty 기반 렌더링, cloudflared 배포까지 요구 사항이 한 문단에 빼곡히 담겼고, 작업이 끝날 때까지 시각적 QA 루프를 반복하라는 지시도 이어졌다.

그는 이 방식이 자신만의 원칙에서 나온다고 설명했다.

"참고로 처음에 만들때에는 밖으로 안새도록 이렇게 길게 프롬프팅하고 버그가 생기면 이거안됨저거안됨고쳐줘 ulw 로 합니다 이게 제가 말하는 뇌를 쓸때에는 확실히쓰고 뺄때에는 확실히 빼라는것"

(ulw는 이 방에서 쓰는 은어로, 반복 수정·확인을 자동으로 도는 짧은 명령을 가리킨다.)

다른 참여자는 이 정도 접근을 아무나 할 수 있는 일이 아니라고 반응했다.

"하네스는 천재들이 하는걸로..."

곧이어 또 다른 참여자가 정면으로 물었다.

"하네스 엔지니어링 하게 되는거 아닌가요?"

정말 궁금해서 묻는 것이라는 단서도 달았다.

"진짜 몰라서 여쭤봄"

이 질문에 그는 프롬프팅이 귀찮아지면 자동화하고 싶어지고, 그 자동화가 훅이나 스킬이 되며, 결국 그것이 하네스가 되는 것 아니냐는 취지로 답했다.

"그럼하네스가되지않나여"

그는 모델마다 시스템 프롬프트를 따로 다듬어야 한다는 입장도 덧붙였다.

"Opus sonnet 도 다 다르고요"

"세부버전도 다 다르고요"

"페이블도 다다름요 ㅇㅇ"

한발 더 나아가 그는 모델과 무관하게 똑같이 작동하는 하네스라는 개념 자체가 군대처럼 획일적인 환상에 가깝다는 주장까지 폈다. 정작 자신도 시스템 프롬프트를 모델별로 깎는 사람을 주변에서 보지 못했다며, 그 해석은 어디까지나 자기만의 방식이라고 선을 그었다.

질문을 던졌던 그 참여자는 진지한 반론 대신 자신의 실제 작업 방식을 소개하며 논쟁에 유머를 더했다.

"메인세션을 감시하고 줘패는 사이드 세션을 메인세션 옆에 귀엽게 깎고있습니다"

화제가 잠시 다른 코딩 에이전트의 메모리 문제로 넘어가자, 그는 소프트웨어 공학의 기본기를 다시 한번 못박았다.

"메모리는 터지지 않습니다."

그러면서 이 원칙이 여전히 사람의 몫으로 남아 있는 영역이라는 점도 덧붙였다.

"소프트웨어 개발이 아직 도메인 지식으로 불릴 수 있는 증거겠지요"

다만 곧바로 태도를 누그러뜨리며 공을 도구에도 돌렸다.

"사실 페이블이 잘 해주었습니다"

"에이전트를 잘 쓰면 버그는 안납니다"

이후 대화는 결론에 이르지 못한 채 여러 코딩 도구 이름을 빗댄 농담으로 흘러갔다. 이날 저녁 방을 달궜던 신형 관제탑 도구를 묻는 말에도 그는 시큰둥하게 답했다.

"Paseo?"

"장난감입니다"

프롬프트 엔지니어링과 하네스 엔지니어링의 경계가 어디인지에 대한 논쟁 자체는 답을 찾지 못하고 흩어졌다.

그러나 새벽 1시 반, 그는 직접 만들라고 지시했던 그 웹 터미널의 결과물을 내놓았다.

"샌각보다 잘나오네요"

그는 이를 단 한 번의 시도로 나온 결과물이라고 밝히며 만족감을 드러냈다. 실제 완성도나 버그 여부는 방에서 확인되지 않았다.

이날 흐름은 프롬프팅과 하네스의 경계가 어디인가라는 질문에 이 방이 아직 합의된 답을 갖고 있지 않다는 것을 보여준다. 프롬프트를 길게 쓰다 보면 결국 훅과 스킬을 만들게 되고, 그것이 곧 하네스라는 주장과, 모델별로 손질하지 않는 하네스는 의미가 없다는 주장, 그리고 애초에 개념 정의보다 결과가 중요하다는 태도가 한 대화 안에서 뒤섞인 채 정리되지 않았다. 그러나 개념 논쟁과는 별개로, 뇌를 쓸 때는 확실히 쓰고 뺄 때는 확실히 뺀다는 원칙이 실제 결과물로 증명됐다는 점은 눈여겨볼 만하다. 정의는 아직 흐릿해도 실전에서는 이미 작동하고 있다는 뜻으로 읽힌다.