AI 개발, 삽질만 반복했던 과거
솔직히 고백하자면, AI 개발이라는 거창한 타이틀을 달고 프로젝트에 참여했지만, 늘 결과는 만족스럽지 못했습니다. 프롬프트 몇 번 던져보고 ‘이게 다인가?’ 싶기도 했고, 뭔가 뾰족한 수가 없을까 늘 고민이었죠. 모델은 계속 발전하는데, 나는 왜 제자리걸음일까 자괴감도 들었던 것 같아요. 뭔가 체계가 필요하다고 느꼈지만, 어디서부터 시작해야 할지 막막했습니다.
AI 네이티브의 숨겨진 노력: 하네스 엔지니어링
그러다 빌더 조쉬님의 유튜브 채널에서 DIO FDE 김지운님의 영상을 보게 되었습니다.
영상의 제목부터가 심상치 않았죠. ‘상위 1% AI 네이티브들은 프롬프트 안 쓰고 ‘하네스 깎기’에 수백 시간 투자합니다.’ 라니! 프롬프트가 전부가 아니라는 사실, 그리고 그 뒤에 숨겨진 엄청난 노력이 있다는 것을 깨닫게 해주는 대목이었어요.
하네스 엔지니어링이란 무엇일까?
김지운님은 ‘하네스 엔지니어링’이라는 생소한 개념을 소개합니다. 쉽게 말해, 다양한 AI 모델(클로드, 코덱스, 제미나이 등)을 사용하더라도 마치 하나의 디자인 시스템처럼 일관된 결과물을 얻을 수 있도록 만드는 일종의 ‘틀’을 만드는 작업이라고 하더라고요. 예를 들어 배달 플랫폼 개발을 예시로 들었는데, 고객용 앱, 기사용 앱, 음식점용 앱, 어드민 이렇게 4가지 소프트웨어를 만들 때, 어떤 AI 모델을 쓰든 동일한 퀄리티와 스타일을 유지하는 거죠.
이 ‘하네스’를 만들기 위해 무려 6단계 플로우 (요구 사항 분석 -> 플랜 수립 -> 아키텍처 설계 -> 코드 레벨 디자인 설계 -> 린터 기반 코드 검토 -> 결과물 도출)를 거친다고 합니다. 단순히 코딩만 하는 게 아니라, 기획 단계부터 설계, 코드 리뷰, 평가까지 모든 과정을 꼼꼼하게 관리하는 것이죠.
CPS, PRD… 낯선 용어들의 향연
영상을 보면서 CPS(Context, Problem, Solution)나 PRD(Product Requirements Document) 같은 용어들이 계속 등장하는데요. 처음에는 ‘저게 다 뭔가…’ 싶었지만, 김지운님이 실제 프로젝트에서 어떻게 활용하는지 설명해주니 이해가 되더라고요. CPS는 문제의 맥락, 문제 자체, 그리고 해결책을 명확하게 정리하는 프레임워크이고, PRD는 제품 요구사항을 문서화하는 과정이라고 합니다. 이 두 가지 문서를 꼼꼼하게 작성하고 공유하는 것이 프로젝트의 성공에 큰 영향을 미친다고 해요.
특히 인상 깊었던 부분은 문서를 단순히 ‘보여주기’ 용도로 사용하는 것이 아니라, 고객과 함께 만들어간다는 점이었어요. 깃허브를 통해 CPS 문서를 공유하고, 업데이트된 내용을 실시간으로 확인할 수 있도록 한다고 합니다. 이런 투명한 소통 방식이 고객과의 신뢰를 쌓는 데 큰 도움이 될 것 같아요.
코드 린팅, 그 이상의 의미
코드 레벨에서는 린터를 활용해서 코드 스타일을 강제한다는 내용도 흥미로웠습니다. 예를 들어 레스토랑 목록을 보여주는 페이지는 반드시 복수형으로 이름을 짓도록 강제하고, 파일명에 “디테일”이나 “리스트” 같은 단어를 사용하지 못하도록 하는 거죠. 처음에는 ‘너무 깐깐한 거 아닌가?’ 싶었는데, 코드의 일관성을 유지하고 유지보수를 용이하게 하기 위해서는 꼭 필요한 과정이라는 생각이 들었습니다.
김지운님은 “휴먼 리더블 코드”의 중요성도 강조했는데요. AI가 생성하기 쉬운 코드보다 사람이 읽기 쉽고 이해하기 쉬운 코드를 작성해야 한다는 겁니다. 결국 AI는 도구일 뿐이고, 사람이 코드를 이해하고 수정할 수 있어야 장기적으로 유지보수가 가능하다는 거죠.
나만의 ‘하네스 깎기’를 시작해야 할 때
영상을 보면서 예전에 제가 했던 프로젝트들을 되돌아보게 됐습니다. 그때는 왜 그렇게 삽질을 많이 했을까, 왜 결과물이 들쭉날쭉했을까… 이제야 그 이유를 알 것 같아요. 저는 ‘하네스’ 없이 맨땅에 헤딩하는 식으로 개발을 했던 거죠. 뼈아픈 반성이었습니다.
김지운님은 초심자들에게 “이밸류에이션에 집중해야 한다”고 조언합니다. 하네스를 아무리 잘 만들어도, 결과물을 제대로 평가하지 못하면 의미가 없다는 거죠. 조직에 맞는 이밸류에이션 방법을 찾고, 품질 관리 대시보드를 만들어서 지속적으로 트래킹해야 합니다.
하드웨어 프로젝트 실패 경험담도 기억에 남습니다. 펌웨어 구현에 어려움을 겪다가 결국 포맷을 해야 했던 경험을 통해, “제로에서 결과물로 가는 단계가 몇등이어야 한다”는 것을 깨달았다고 합니다. 어떤 과정을 거쳐서 결과물이 나왔는지 명확하게 알아야 문제가 발생했을 때 빠르게 대처할 수 있다는 거죠. 이 말이 묘하게 위로가 되면서, 앞으로는 ‘왜’라는 질문을 더 깊이 파고들어야겠다는 생각을 했습니다.
결국, 중요한 건 ‘기본’ 아닐까?
결국, AI 개발도 결국 탄탄한 기본기를 바탕으로 끊임없이 고민하고 노력하는 과정이라는 것을 깨달았습니다. ‘하네스 깎기’는 단순히 기술적인 스킬이 아니라, 문제 해결 능력, 설계 능력, 커뮤니케이션 능력 등 다양한 역량을 요구하는 종합 예술이라는 생각도 들었고요. 지금 당장은 막막하지만, 김지운님의 영상을 보면서 용기를 얻었습니다. 저도 저만의 ‘하네스’를 만들어나가기 위해 꾸준히 노력해야겠습니다. 여러분은 어떤 ‘하네스’를 만들고 싶으신가요?