4월 개발팀 세미나 : 우리만의 하네스 엔지니어링

안녕하세요! 코멘토 개발팀 김문범입니다.

지난 4월 세미나는 단순한 지식 공유를 넘어, 우리 팀이 AI라는 거대한 파도를 어떻게 타고 있는지 확인하는 시간이었습니다. 특히 '하네스(Harness, 고삐)'라는 개념을 통해 AI를 단순히 시키는 대로 일하는 도구가 아닌, 정교하게 설계된 시스템 안에서 협업하는 파트너로 정의하는 과정이 인상 깊었는데요.

1. "오마이는 뭐가 그렇게 다르지?” — 최수빈

최수빈님은 AI를 '10년 치 지식은 있지만 10년 차는 아닌 개발자'로 정의하며 발표를 시작했습니다. 수빈님은 처음 AI 에이전트를 접했을 때, 아무런 가이드 없이 냅다 시키기만 하면 AI가 코드 베이스의 맥락을 놓치고 길을 잃는 모습을 보며 '하네스'의 필요성을 절실히 느끼셨다고 해요.

"하네스(고삐)가 없으면 AI는 그냥 혼자 달리는 말에 불과해요. 우리 팀의 컨벤션이나 폴더 구조 같은 맥락을 하네스로 구축했을 때와 아닐 때의 성능 차이는 정말 확연했습니다."

수빈님은 '오마이(OMO, OMC)' 시리즈를 써보며 시행착오를 겪으셨는데, 처음에는 깃허브 코파일럿에 연결해 썼다가 한 달에 100달러가 넘는 비용 폭탄을 맞고 당황하기도 하셨죠. 하지만 결국 AI가 스스로 질문하며 모호함을 해소하는 '우로보로스' 방식을 접하며, 개발자의 역할이 이제 단순히 지시하는 것에서 'AI가 스스로 잘 달릴 수 있도록 설계하는 단계'로 넘어가고 있다는 확신을 얻으셨다고 합니다.

2. "Claude Code Skill 공유" — 송동훈

송동훈님은 초기 제품을 개발하면서 정책이 자꾸 바뀌는데, 그 배경이 기억나지 않아 고생했던 경험에서 해결책을 찾았습니다. "문서를 정리해도 사람도, AI도 읽기 쉬워야 한다"라는 생각에 노션을 싱글 소스 오브 트루스(SSOT)로 삼고 이를 관리하는 AI 스킬을 직접 만드셨습니다.

그리고 동훈님이 가장 만족했던 스킬은 바로 '픽셀 퍼펙트' 스킬이었습니다. 아무리 AI에게 피그마 디자인을 줘도 실제 결과물과 미묘하게 차이가 나는 것이 늘 불만이었는데, 아예 브라우저 스크린샷을 찍어 AI에게 다시 보여주는 루프를 만들었죠.

"구현된 화면을 AI가 스스로 보고 다시 디자인에 맞게 고치도록 하니까, 한두 번 만에 디자인과 똑같은 결과가 나왔어요. 그때의 만족감은 정말 대단했습니다."

이제 동훈님은 주간 보고 작성이나 복잡한 설문 분석 같은 '귀찮지만 중요한' 업무들을 AI에게 병렬로 맡기고, 더 중요한 비즈니스 설계에 집중하고 계십니다. 특히 새로운 자동화가 필요할 때마다 공식 스킬인 'Skill Creator'를 활용하여 도구 제작의 부담을 획기적으로 줄이셨습니다.

3. "AI-Driven Development Workflow" — 김민기

김민기님은 서로 다른 AI 에이전트인 '클로드 코드'와 '커서(Cursor)'를 동시에 쓰면서 겪는 '컨텍스트 단절'로 스트레스받으셨다고 합니다. 한쪽에서 한참 설명한 내용을 다른 쪽 가서 또 설명해야 하는 비효율을 해결하고 싶었다고 합니다.

민기님의 해결책은 의외로 단순하면서도 강력했습니다. 바로 마크다운(Markdown) 파일과 '옵시디언(Obsidian)'을 공통 대화 창구이자 기록 보관소로 삼는 것이었죠. 특히 작업을 시작하기 전 AI와 충분히 대화하는 '디스커션' 단계에 공을 들이셨습니다.

"내가 생각하는 결과물(End Image)과 AI가 생각하는 그림이 다를 때가 많아요. 냅다 코드를 짜기보다 미리 질문을 주고받으며 눈높이를 맞추는 게 나중에 다시 만드는 수고를 훨씬 줄여줍니다."

비용과 효율을 위해 로직 설계는 고성능 모델(Sonnet/Opus)에, 단순 UI 작업이나 자잘한 디버깅은 저비용 모델(Cursor / Haiku)에 배분하는 민기님만의 하이브리드 워크플로우는 우리 팀 모두에게 도움이 되었습니다.

4. "<내하소> 내 하네스를 소개합니다." — 남원규

남원규님은 AI가 정말 강력하지만, 실수로 DB 마이그레이션을 건드리거나 중요한 데이터를 날려버릴까 봐 늘 조마조마하셨다고 합니다. 그래서 오픈 소스인 '오마이 오픈 코드(OMO)'의 하네스 설정을 직접 가져와 응용하셨고, AI가 짠 플랜을 한 번 더 검토하는 '크리틱(Critic) 단계'와 강력한 보안 장치를 하네스에 구성했습니다.

"DB 쓰기 명령은 아예 금지해 놓았어요. AI가 위험한 시도를 하려고 할 때마다 훅(Hooks)이 작동해서 차단하는 걸 확인했을 때 비로소 안심이 되더라고요."

원규님은 '아키텍트', '크리틱', '디버거'라는 역할을 AI에게 각각 부여하고, 상황에 맞게 모델(Haiku, Opus, Sonnet)을 그레이드별로 자동 전환하는 시스템을 구축하셨습니다. "내가 일일이 지시하지 않아도 AI가 알아서 안전 가이드를 지키며 일하는 환경"을 직접 만들어낸 뿌듯함이 느껴지는 발표였습니다.

5. "포타블쿼리(POTAbleQuery)" — 강윤해

마지막으로 강윤해님은 팀 전체의 소통 비용을 줄이기 위해 발 벗고 나선 경험을 들려주셨습니다. 디자이너 세영님이 데이터를 보고 싶을 때마다 개발팀에 요청하는 것이 서로 부담이었는데, 이를 해결하기 위해 자연어로 DB를 조회하는 'PortablQuery'를 만드신 거죠.

가장 큰 난관은 AI가 우리 서비스만의 비즈니스 언어를 모른다는 점이었습니다. 윤해님은 '코호트 1' 같은 우리끼리만 통하는 개념을 시스템 프롬프트에 정성스럽게 녹여내셨습니다.

"가끔 AI가 거짓말을 하거나 엉뚱한 쿼리를 짤 때도 있지만(웃음), 동료들이 개발자 도움 없이 직접 데이터를 뽑아보고 만족해하는 모습을 볼 때 이 기능을 만든 보람을 느껴요."

단순히 기술을 구현하는 것을 넘어, 동료들의 가려운 곳을 긁어주는 도구를 만들어낸 윤해님의 경험은 기술의 진정한 가치가 어디에 있는지 다시 한번 생각하게 되었습니다.

세미나를 마치며 : 우리는 어떤 하네스를 구성할 것인가?

이번 세미나를 통해 우리가 얻은 가장 큰 수확은, AI가 단순히 타이핑을 대신해주는 도구가 아니라는 점입니다. 다섯 발표자가 공통으로 느낀 것처럼, AI는 우리가 설계한 '하네스' 안에서 비로소 모든 실력을 발휘합니다.

단순 구현을 넘어 비즈니스 가치를 설계하고, AI가 안전하고 똑똑하게 일할 수 있는 환경을 만드는 것. 그것이 바로 코멘토 개발팀이 정의하는 새로운 개발자의 모습이 아닐까 싶습니다.