최근 AI 코딩 트렌드를 살펴보면 크게 3단계로 진화해 왔다는 이야기들이 많이 들린다. 처음엔 모델에게 어떻게 말을 걸지 고민하던 '프롬프트(Prompt) 엔지니어링' 시대였다. 그 다음엔 모델에게 어떤 정보를 보여줄지 고민하는 '컨텍스트(Context) 엔지니어링'의 시기를 거쳤다. 그리고 요즘엔 모델의 예측 불가능한 행동을 제어하기 위해 아예 전체 환경을 겹겹이 설계하는 이른바 '하네스(Harness) 엔지니어링'의 단계로 넘어왔다고들 한다.
나는 전문 개발자가 아니라 시스템 엔지니어(SE)다. 하지만 프롬프트와 컨텍스트 시대의 혜택을 누구보다 톡톡히 누려왔다. 복잡한 문법 때문에 골머리를 앓는 대신, 기획만 툭 던져주면 AI가 알아서 코드를 짜주는 바이브 코딩(Vibe Coding) 덕분에 사내 유틸리티나 개인 앱들을 아주 쉽고 편하게 만들고 있다.
그런데 최근 불어닥친 '하네스 엔지니어링' 트렌드를 보고 있으면 어딘가 좀 찜찜하다. 뭐, 처음에 프롬프트 엔지니어링부터 컨텍스트 엔지니어링까진 열심히 공부도 하고 테스트도 해보면서 나름대로의 규칙과 노하우가 생겼고 만족스러웠다. 하지만 하네스 엔지니어링은 뭔가 좀 묘하게 이상한 기분이 들었다.
지금의 AI는 완벽하지 않다. 큰 틀은 뚝딱 만들어 내지만, 자잘한 디테일에서 엉뚱한 라이브러리를 쓰거나 같은 수정을 반복하는 무한 루프에 빠지기도 한다. 하네스 엔지니어링은 바로 이 실수를 시스템적으로 차단하겠다는 거다. 룰을 빼곡하게 적어두고, 코드를 검사하는 린터를 덧붙이고, 심지어는 결과물을 다시 검증하는 다른 AI까지 추가로 붙여 넣는다.
그런데 이렇게까지 에러를 막으려고 하네스를 겹겹이 두르다 보면, '이게 정말 내가 편하려고 쓰는 게 맞나?' 싶은 생각이 든다. 예전에 한창 TDD(테스트 주도 개발) 열풍이 불었을 때도 이와 비슷한 느낌이었다. 버그 하나 없게 만들겠다고 개발 코드 본체보다 테스트 코드를 몇 배나 더 길게 짜다 보면, 결국 내가 본 로직을 만드는 건지 거대한 테스트 도구를 만드는 건지 헷갈리는 순간이 오곤 했다. 하네스 역시 너무 엄격하게 통제하려다 보면 금세 배보다 배꼽이 커지고 관리에만 지치는 상황이 온다.
겉으로는 엄청난 기술 발전처럼 포장되어 있지만, 근본적인 원인은 명확하다. AI 모델 자체가 아직 100% 똑똑하지 않아서 생기는 한계다. 같은 질문을 던져도 매번 결과가 달라지니까 그 틈을 어떻게든 메우려는 거다. 그런데 요즘 업계 분위기를 보면 참 묘하다. "AI가 이상한 결과물을 내는 건 네 시스템 세팅이 허술해서 그래"라며 은근슬쩍 사람 탓으로 떠넘기는 느낌을 지울 수 없다.
이런 분위기 속에서 결국 우리는 '이해 부채(Comprehension Debt)'만 떠안게 된다. AI가 뱉어낸 코드를 완벽하게 파악하지도 못했으면서, 그저 통제망에서 에러가 나지 않았으니까 대충 "통과" 하고 넘겨버리게 되는 거다. 해외 포럼에서 오죽하면 이걸 두고 AI Brain Fry(뇌가 타버렸다)라고 부를까 싶다. 내 일 좀 덜어보려고 비서 하나 뒀더니, 오히려 뒷수습하고 감시하느라 머리가 더 아파지는 기분이다.
물론, 아예 아무런 룰 없이 날것 그대로 실무에 쓰자는 말은 아니다. 최소한의 가이드라인 정도는 당연히 있어야 한다. 하지만 그 통제망을 구축하는 데 내 과도한 에너지를 쏟고 싶진 않다. 지금 그 복잡하게 짜놓은 하네스들도, 어차피 앞으로 모델 성능이 조금만 더 올라가면 싹 다 쓸모 없어질 가능성이 크다. 그래서 처음부터 '삭제를 위한 설계(Build for Deletion)'라고 마음을 비우고 접근하는 게 맞지 않나 싶다.
시간이 지나면 알아서 해결될 문제에 굳이 귀한 시간과 에너지를 갈아 넣을 필요는 없다. 내가 생각하는 바이브 코딩의 본질은 AI를 통제 시스템으로 꽁꽁 묶는 게 아니다. 도구가 불완전하면 불완전한 대로, AI가 짜준 코드를 보며 '내 기획 의도대로 잘 돌아가는지' 담담하게 확인(Audit)만 하면 그만이다. 머리 아픈 무단 타이핑은 기계에게 던져두고, 나는 중요한 뼈대랑 논리만 챙기면 된다. 그게 진짜 속 편하게 바이브 코딩을 내 도구로서 다루는 방법이다.