Speaker A
작년 6월에 저 혼자 대규모 코드 마이그레이션을 반나절 만에 끝냈어요. 버그는 단 한 개, 그것도 소 모델 썼어요. 그날 저녁에 깨달았거든요.
모델보다 중요한 하니스의 역할과 스킬, 도메인 기반 유지보수로 AI 작업 효율을 극대화하는 방법을 소개합니다.
Key Takeaways
- 모델 자체보다 하니스 구축이 AI 작업 성과에 결정적 영향을 준다.
- 스킬과 도메인 매뉴얼을 지속적으로 관리하는 것이 장기적 경쟁력이다.
- 자동 검사 도구는 품질 유지에 필수적이며, 반복 작업의 효율을 높인다.
- 하니스는 회사 시스템뿐 아니라 개인의 자산으로도 중요하다.
- 실제 사례를 통해 하니스의 효과와 필요성을 명확히 확인할 수 있다.
What the video covers
- AI 모델보다 하니스(모델 주변 시스템)가 결과에 훨씬 큰 영향을 미친다.
- 하니스는 작업 명세, 도구 접근, 검증 등 11가지 요소로 구성된다.
- 작년 대규모 코드 마이그레이션을 반나절 만에 성공한 경험을 공유한다.
- 스킬 기반 지속적 리팩토링으로 일관된 결과를 내는 방법을 설명한다.
- 도메인 단위로 코드를 묶고 매뉴얼을 작성해 유지보수를 효율화한다.
- 자동 검사 시스템 도입으로 작업 품질을 안정적으로 관리한다.
- 좋은 하니스는 낮은 성능 모델도 높은 성능처럼 활용 가능하게 한다.
- 회사 내에서는 하니스 구축이 어렵고 개인 자산화가 중요하다는 점을 강조한다.
- 실전 적용 4단계(계획 작성, 스킬 정리, 도메인 구조화, 자동 검사)를 제안한다.
- 하니스 구축을 통해 AI 작업의 생산성과 품질을 크게 향상시킬 수 있다.
Full Transcript — Download SRT & Markdown
Speaker A
모델보다 훨씬 더 중요한 게 따로 있다는 걸요. 그리고 그 깨달음 하나 때문에 결국 저는 회사를 나오게 됐어요. 오늘은 그 이야기를 풀어 보려고 합니다. 영상이 좀 길어요.
Speaker A
근데 한 번만 끝까지 같이 봐 주시면 좋겠어요. 왜냐하면 모델 이야기는 다들 너무 많이 들으셨을 것 같거든요. 그것보다 결과에 훨씬 더 큰 영향을 주는 것들이 따로 있어요.
Speaker A
오늘 같이 볼 건요. 다섯 가지예요. 첫째, 하니스가 뭔지 정확히 짚어 드릴게요. 둘째, 작년에 제가 어떻게 마이그레이션을 반나절에 끝냈는지 그 과정을 보여 드리고요. 셋째, 스킬 기반으로 코드를 어떻게 계속 다듬어 가는지. 넷째, 도메인 단위로 어떻게 유지 보수를 굴리는지.
Speaker A
마지막에 제가 결국 회사를 나오게 된 진짜 이유까지요. 시작할게요. 요즘 다들 GPT 5.5다, 클로드 오프스 4.7이다, 어떤 모델이 더 똑똑한지 신경 많이 쓰시잖아요. 사실 저도 그랬어요. 새 모델 나오면 바로 갈아타고 벤치마크 점수 확인하고요.
Speaker A
근데 어느 순간부터 좀 이상하게 보이기 시작했어요. 같은 모델인데요, 어떤 사람은 막힘 없이 잘 쓰고 어떤 사람은 매번 AI는 아직 멀었다고 한탄해요. 분명히 같은 클로드를 쓰는데도요. 처음엔 그냥 프롬프트 차이인가 싶었거든요. 근데 그게 아니더라고요. 작년에 커서라는 회사에서 재밌는 실험을 했어요. 같은
Speaker A
클로드 모델, 같은 벤치마크인데 주변 시스템을 어떻게 짜느냐에 따라 점수가 46점에서 80점까지 왔다 갔다 했어요. 34점 차이예요. 모델은 똑같은데요. 비유하자면요, 같은 F1 드라이버한테 경운기를 주느냐, 레이싱카를 주느냐의 차이예요.
Speaker A
운전자는 그대로인데 결과는 완전히 다른 거죠. 이걸 요즘 사람들이 하니스라고 불러요. 모델 주변에 두르는 마구. 그러니까 안전 배트랑 차량 같은 거예요. 근데 F1 비유가 좀 와닿지 않을 수 있어요. 좀 더 일상적인 걸로 바꿔 볼게요. 신입 직원 한 명 뽑았다고 쳐 볼게요.
Speaker A
똑같이 똑똑한 신입이에요. 근데 A 회사는 매뉴얼도 없고 코드 리뷰도 없고 알아서 해 하고 던져 버려요.
Speaker A
B 회사는 온보딩 문서 잘 정리해 두고 작업 시작 전에 스펙부터 같이 검토하고 PR 올라오면 자동 검사기 돌고 빌드 깨지면 바로 알람이 가요.
Speaker A
같은 신입인데 6개월 뒤물이 같을 리가 없잖아요. AI도 똑같아요. 모델은 신입의 IQ고 하니스는 그 신입을 둘러싼 회사의 시스템이에요.
Speaker A
IQ가 높으면 좋긴 한데 시스템이 영광이면 어떻게 되죠? 음. IQ 200짜리도 헤매요. 그리고 사실은요, IQ 130짜리한테 좋은 시스템 깔아주면 IQ 200짜리 혼자 두는 것보다 결과가 더 잘 나와요.
Speaker A
스탠포드에서 연구한 것도 있어요. 하니를 잘 짜면 결과물 품질이 28%에서 47%까지 올라간대요. 근데 프롬프트만 다듬으면 3%도 안 올라가요. 차이가 어마어마하죠? 자, 그럼 하니스가 정확히 뭐냐? 쉽게 말해서요, AI한테 일을 시킬 때 그 주변의 모든 장치예요. 어떤 도구를 줄 건지, 어떤 매뉴얼을 줄 건지,
Speaker A
일하다가 실수하면 어떻게 잡아낼 건지, 다음에 뭘 할지를 어떻게 결정하게 할 건지 이런 거 전부요.
Speaker A
연구자들이 분석해 보니까 하니스는 크게 11가지 요소로 나뉘어요. 작업 명세, 컨텍스트 선택, 도구 접근, 프로젝트 메모리, 작업 상태, 관찰성, 실패인 분석, 검증, 권한, 엔트로픽 감사, 그리고 개입 기록. 말이 좀 어렵죠? 비유하자면요,
Speaker A
신입한테 일시킬 때 필요한 거 다 똑같아요. 무슨 일이지? 자료는 어디 있지? 뭐 만질 수 있지, 잘됐는지 어떻게 확인하지, 망쳤으면 누가 알려주지 이런 것들이요. 별로 신비한 거 아니에요. 핵심은요, 모델은 이 중에 하나일 뿐이에요. 그것도 가장 변동이 적은 부분이에요. 나머지 열
Speaker A
개를 어떻게 짜느냐가 결과에 거의 전부를 결정합니다. 자, 이제 제 이야기를 한번 해 볼게요. 작년 6월이었어요. 회사에서 큰 마이그레이션이 잡혔거든요. 코드 베이스가 꽤 컸어요. 몇 평소 같으면 며칠은 잡았어야 할 작업이에요. 그때 모델은 소네시였어요. 최신 오피스도 아니었고요. 근데 저는 그 한 달
Speaker A
전부터 하니스를 진지하게 짜고 있었어요. 뭘 짰냐면요, 먼저 작업 들어가기 전에 스펙 리뷰를 강제로 거치게 했어요. AI한테 바로 이거 고쳐가 아니라 먼저 뭘 어떻게 고칠 건지 계획부터 세우게 하고 제가 그 계획을 한 번 더 검토하는 단계예요.
Speaker A
그다음에 워크플로우를 만들었어요. 파일 읽기, 변경, 테스트, 커밋이 흐름을 매번 같은 순서로 가게요. 어디서 박히는지 바로 보이게요.
Speaker A
마지막으로 자동 검사도 깔았어요. 빌드 한번 깨지면 바로 신호가 오게요. 마이그레이션 당일이에요. 오전에 시작했어요. 점심 먹기 전에 거의 다 끝나 있었어요. 오후엔 검수만 했어요. 반나절 버그는 딱 한 개. 그것도 사소한 거였어요. 이게 모델이 잘 나서일까요? 아니에요.
Speaker A
같은 소네인데 그 전에 비슷한 일을 하다가 며칠씩 헤맸거든요. 모델은 그대로예요. 차이는 하나였습니다. 주변에 깐 시스템. 근데요, 사실 한 번의 성공은 운일 수도 있잖아요.
Speaker A
진짜 중요한 건 그다음이었거든요. 이 성공을 어떻게 한 번이 아니라 매주 매월 반복할 수 있느냐. 여기서부터 진짜 하니스 얘기가 시작돼요.
Speaker A
이제부터 다룰 두 가지가 오늘 영상의 핵심이에요. 스킬 기반의 지속적인 리팩토링과 도메인 기반의 지속적인 유지보수. 이름이 좀 어려운데요,
Speaker A
정말 쉽게 풀어 드릴게요. 이 두 개 없으면 반나절 마이그레이션은 1회성 마술쇼로 끝나거든요. 자, 첫 번째예요. 스킬 기반 리팩토링. 이게 뭐냐면요, AI한테 매번 리팩토링 해 줘 하면 매번 다른 결과가 나와요.
Speaker A
어떤 날엔 깔끔하게 잘하고 어떤 날엔 막 뜯어고치고요. 사람도 마찬가지잖아요. 매번 알아서 해라고 하면 매번 결과가 달라요. 그래서 저는 자주 하는 리팩토링 패턴을 스킬이라는 단위로 따로 정리해 뒀어요. 비교하자면요, 음식점에서 매번 셰프 기분 따라 음식이 나오는 거랑 레시피 카드 보고 만드는 거의
Speaker A
차이예요. 똑같은 셰프인데도요, 레시피가 있으면 맛이 일정해져요. 근데 효과가 정말 커요. 매번 같은 결과가 나와요. 그리고 한번 잘못된 결과가 나오면 그 스킬 문서만 고치면 다음부턴 안 그렇습니다. 사람 기억으로 관리하는 게 아니라 스킬을 관리하는 거예요. 또 하나 중요한 게요, 지속적이라는 단어가 붙은
Speaker A
이유가 있어요. 스킬은 한 번 자고 끝이 아니에요. 쓸 때마다 조금씩 다듬어 가요. AI가 어떤 케이스에서 실수하면 이런 경우엔 이렇게 해. 한 주를 스킬에 추가해요. 다음번에 그 실수가 나오지 않습니다. 이게 누적되면 1년 뒤엔 다른 회사가 흉내 내기 힘든 자산이 돼요. 저는
Speaker A
작년에 마이그레이션 끝나고 나서 이걸 본격적으로 깔기 시작했어요. 지금은 스킬이 굉장히 풍부해졌습니다. 새 모델로 갈아타도 그대로 써요. 모델은 갈아엎어도 스킬은 안 죽거든요. 이게 진짜 무서운 자산이라고 생각합니다.
Speaker A
자, 두 번째 도메인 기반 유지 보수. 이게 무슨 말이냐면요, 일반적으로 코드를 파일 종류로 나누잖아요. 컴포넌트 폴더, 훅 폴더, 유틸 폴더. 이것도 좋습니다.
Speaker A
근데 이 방식은 AI한테 일시킬 때 굉장히 좀 효율적이지 않다고 생각합니다. 왜냐하면요, 기능 하나 고치려면 컴포넌트 폴더에서 한 개, 훅 폴더에서 두 개, 유틸 폴더에서 한 개 여기저기 흩어진 걸 다 찾아와야 돼요. AI한테 관련 파일 다 가져와가 그렇게 쉽지가 않거든요.
Speaker A
사람한테도 어렵잖아요. 도메인 기반은 그렇지 않습니다. 결제하면 결제, 인증이면 인증. 한 폴더에 그 도메인하고 관련된 거 다 모아 두는 거예요. 컴포넌트, 훅, API, 타입, 테스트. 심지어 그 도메인 전용 문서까지요. 비유하자면요, 집 정리할 때 신발은 신발장, 옷은 옷장 이런 식으로 종류별로 나누는 거랑요,
Speaker A
아침에 쓰는 건 다 현관 옆에, 잘 쓰는 건 다 침대 옆에 식으로 쓰임새별로 나누는 거. 후자가 훨씬 빠르거든요. 일상이 그 단위로 굴러가니까요. 코드도 똑같아요.
Speaker A
사람이 일을 받을 때 결제 버그 고쳐 주세요지, 훅 한 개 고쳐 주세요가 아니거든요. AI한테 일시킬 때도 도메인 단위로 묶어 두면 결제 폴더 안에서만 작업해라고 범위를 좁힐 수 있어요. 컨텍스트가 깨끗해지고 실수가 줄어요. 그리고 더 중요한 게요,
Speaker A
도메인마다 그 도메인 전용 매뉴얼을 두는 거예요. 결제 폴더 안에 결제 도메인에서 지켜야 할 규칙 같은 짧은 문서가 있어요. 새 기능 추가할 때 AI가 그걸 먼저 읽고 시작해요.
Speaker A
그러니까 도메인 안에서의 일관성이 깨지질 않아요. 이걸 지속적이라고 표현한 이유가 있어요. 도메인 매뉴얼은 한 번 적고 끝이 아니에요.
Speaker A
그 도메인의 새로운 결정이 추가될 때마다 한 주씩 들어가요. 1년 지나면 그 도메인의 모든 규칙이 그 안에 다 들어 있어요. 신입 개발자한테 그 폴더만 던져 주면 이해해요. AI도 그래요. 새 모델로 바꿔도 그 매뉴얼만 읽히면 똑같이 이래요. 잠깐만요. 여기까지 따라오시느라고 고생하셨어요. 이제
Speaker A
거의 다 왔어요. 남은 챕터에서는 이걸 회사 차원에서 실제로 굴린 사례랑 그리고 제가 결국 회사를 나오게 된 이후 마지막에 여러분이 지금 할 수 있는 실전 단계를 풀어 볼게요. 사람들이 자꾸 웃거든요.
Speaker A
그래서 어떤 모델 써야 돼요? 근데 그게 사실 일순위 질문이 아닙니다. 한 연구자가 이렇게 표현했어요.
Speaker A
모델은 천장을 정하고 하니스는 그 천장에 얼마나 가까이 갈지를 정한다. 이게 진짜 정확한 말이에요. 모델이 아무리 좋아도 하니스가 엉망이면 천장 근처도 못 가요. 반대로 하니스가 잘 짜여 있으면 한 단계 낮은 모델로도 천장에 거의 다요. 실제로요.
Speaker A
오픈AI에서 자기네들 코덱스 팀이 AI로만 짠 코드를 100만 줄 넘게 프로덕션에 올렸다고 발표했고요. 스트라는 회사는 미니언즈라는 자동화된 코딩 에이전트가 매주 1,300개 넘는 PR을 머지하고 있어요. 이게 GPT가 갑자기 똑똑해져서가 아니에요. 둘 다 하니스에서 엄청난 공을 들였거든요. 엔트로픽 자체 데이터도 비슷해요. 같은 클로드
Speaker A
오프스를 그냥 쓰면 42점, 클로드 코드라는 하니스 안에서 쓰면 78점. 36점 차이가 모델이 아니라 주변 시스템에서 나오는 거예요. 여기서 진짜 무서운 게 있어요. 이런 회사들이 깐 게 뭐냐? 결국 아까 말씀드린 두 가지예요. 자주 쓰는 패턴을 스킬로 정리해 두고 도메인 단위로 코드를 묶고 매뉴얼을 붙여 둔
Speaker A
거예요. 이름만 다를 뿐 질은 같습니다. 다시 작년 6월로 가 볼게요. 마이그레이션이 끝나고 저녁이었어요. 친구들이랑 같이 밥을 먹는데 처음엔 기분이 좋았거든요. 며칠 걸릴 일을 반나절에 끝냈으니까요. 근데 갑자기 좀 무서워졌어요. 평소에 며칠 걸리는 일이 반나절에 끝났다는 거. 제가 봤던 월급의 상당 부분이 이미 자동화
Speaker A
가능한 영역이라는 뜻이거든요. 그게 머릿속에서 안 떠나더라고요. 5년 뒤를 떠올려 봤어요. 지금 사람들이 5년 동안 스킬을 쌓고 도메인 매뉴얼을 다듬고 하니스를 표준화하면요. 그때 가서 시니어 개발자라는 직업이 지금이랑 같은 모양일까요? 솔직히 자신이 없었어요.
Speaker A
강한 위기감이 왔어요. 흔히 말하는 그 포머. 근데 그게 단순히 두려움만은 아니었습니다. 동시에 굉장히 흥분되기도 했거든요.
Speaker A
왜냐하면 이 흐름을 누군가는 만들어야 하잖아요. 그리고 잘 만들면 가치가 어마어마하잖아요. 그 누군가가 내가 안 될 이유가 뭐지 싶었어요.
Speaker A
그날 이후로 한 달쯤 고민했어요. 회사 안에서 이 흐름을 더 밀어붙일까 아니면 이걸로 제 일을 만들까? 결론은 후자였어요. 이유는 단순했습니다.
Speaker A
회사 안에서는 제가 아무리 좋은 스킬을 쌓고 도메인 매뉴얼을 정리해도 그게 그 회사의 자산인지 제 자산이 되는 건 아니었거든요. 5년 뒤에 시니어 자리가 줄어들면 저는 그냥 같이 사라져요. 그리고 하나 더 있었어요. 회사 안에서는 사실 하니스를 깊이 짜기가 어려워요.
Speaker A
왜냐하면 회사는 매출과 일정이 우선이거든요. 그것 짜는데 한 달만 주세요가 잘 안 통해요. 그런데 좋은 하니스는 한 달은 깔아야 효과가 나와요. 단기 매출이 아니라 6개월 누적 생산성에 들어가거든요. 이게 회사의 한계예요. 회사는 6개월 뒤 누적치보다 다음 분기 매출이 더 급해요. 그게 잘못된 게 아니라 회사가
Speaker A
작동하는 방식이에요. 특히나 지금 현재 매출을 잘 내고 있는 회사라면 더욱 그렇고 맨파워가 부족한 회사라면 더욱 더 그렇습니다. 다만 그 안에서 제 5년이 짜이는 건 좀 다른 얘기죠. 그래서 그만뒀습니다. 그리고 제가 직접 일을 받기 시작했고 지금까지 그 일을 하고 있어요.
Speaker A
포모대문이라기보다는 솔직히 제 일이 5년 뒤에 어떤 모양이 될지 제가 직접 그리고 싶었던 겁니다. 자, 이제 실전으로 가 볼게요. 그래서 여러분이 지금부터 뭘 할 수 있냐? 4단계로 정리해 드릴게요. 거창할 거 없어요.
Speaker A
차근차근 한 달에 하나씩만 깔아도 4개월이면 완성돼요. 작업 들어가기 전에 AI한테 계획부터 쓰게 해 보세요. 바로 코드 작성이라고 하지 마시고 어떻게 고칠 건지 한번
Speaker A
그거 한 줄 추가했을 뿐인데 결과물 품질이 확 달라져요. 처음에 귀찮아 보여요. 근데 살만해 보시면 다시 안 빼게 됩니다. 2 단계로는 자주 하는 일을 스킬로 옮기기입니다. 같은 종류의 리팩토링을 세 번 이상 하셨다면 그건 스킬로 옮길 때라는 신호입니다. 한 페이지면 충분해요.
Speaker A
언제 발동하는지, 어떤 순서로 가는지, 끝나고 뭘 확인해야 되는지 이게 답니다. 처음에 어색한데 여러 개 쌓이기 시작하면 그 효과가 보이기 시작합니다. 혹은 하나의 스킬에 여러 가지 섹션으로 구분을 해 가지고 스킬을 멀티션으로 만들면 그게 자산이 됩니다. 3단계 코드를 도메인 단위로
Speaker A
묶기. 지금 코드 베이스가 파일 종류로 나누어 있다면 한 번에 다 바꾸지 마세요. 그게 부담돼서 결국 아무것도 못 하게 돼요. 새로 만드는 기능부터 도메인 폴더 하나 만들고 그 안에 다 넣어 보세요. 그리고 그 폴더 안에 도메인에서 지켜야 할 규칙
Speaker A
짧은 분석 컨텍스트를 하나 만들어 두세요. 신규 도메인부터 적용하면 부담이 적어요. 6개월 지나면 코드 베이스에 반은 도메인 구조로 바뀌어 있을 거예요. 4단계 자동 검사 깔기. 작업 끝나면 자동으로 검사 린트를 돌게 해 놓으세요. 빌드 테스트, 린트 AI가 짠 코드를 사람이 일일이 보지 마시고요. 검사
Speaker A
시스템이 먼저 거르게 하는 거예요. 이게 없으면 위 세단계 다 깔아도 결과가 흔들립니다.이 4단계가 곧 여러분만의 하니스가 될 거예요. 모델 이야기 너무 많이 들으셨을 거예요.
Speaker A
어떤게 똑똑하다, 어떤게 더 싸다. 근데 그것보다 훨씬 더 중요한게 있어요. 모델 주변에 뭘 깔아두느냐 그게 결과에 거의 전부를 결정해요.
Speaker A
요약해 드리면요. 첫째, 스펙 리뷰 워크플로우 같은 기본 하니스. 둘째, 자주 하는 일을 근로적은 스킬.
Speaker A
그리고 매번 다듬어가는 지속성. 셋째, 도메인 단위로 묶고 그 안에 매뉴얼을든 코드 구조. 그리고 그 매뉴얼이 시간 따라 쌓이는 지속성.
Speaker A
넷째, 매번 같은 결과가 나오게 하는 자동 검사.이네 이네 가지가 합쳐지면 같은 모델로 두 배 일을 할 수 있어요. 저도 작년 그 마이그레이션 이후로 일하는 방식이 완전히 바뀌었어요. 모델 비교에 쓰던 시간을 스킬이랑 도메인 매뉴얼 짜는데 쓰기 시작했거든요. 그리고 나니까 일이
Speaker A
진짜 가벼워지더라고요. 결국 회사를 나와서 제 일을 만들게 된 것도 그 깨달음 하나에서 시작된 거예요.
Speaker A
여러분도 한번 시도해 보시면 좋아요. 새 모델 기다리는 시간에 지금 쓰는 모델 옆에 스킬 한 줄 매뉴얼 한 줄 깔아보는 거예요. 결과 보시면 좀 놀라질 거예요. 오늘 영상 도움되셨다면 좋아요 한번 눌러 주시고 여러분은 지금 어떤 한이스 쓰고 계신지 어떤 스킬을 정리해 두셨는지
Speaker A
댓글로 알려 주세요. 저도 배워 가고 싶어요. 마지막으로 솔직한 고백 하나 할게요. 사실 작년 그 마이그레션 처음엔 자신 없었어요. 한 달 동안 한스 짜면서도 이거 진짜 효과가 있을까 싶었거든요. 사실 동료들한테도 이상한 취급을 받기도 했습니다. 다들 새 모델 어떤 거 좋다라고 할 때
Speaker A
저는 매뉴얼만 쓰고 앉아 있었으니까요. 근데 그날 반나절 만에 마이그레이션 끝났을 때 그제서야 알았습니다. 모델은 천장이지만 하니스는 사다리라는 거예요. 그 사다리를 직접 짜기 시작한 순간 천장은 더 이상 한계가 아니더라고요.
Speaker A
이러한 하니스 짜는 노하우들을 확인하기 위해서는 이제 스킬샵과 혹은 어 회사 도입에 있어 가지고는 저희 링크에 있는 사이트들을 한번 방문을 해 주시면 정말 감사하겠습니다. 다음 영상에서는 제가 실제로 쓰는 스킬 셋업이랑 도메인 매뉴얼 양식을 좀 더 자세히 보여 드릴게요. 그럼 다음에
Speaker A
또 봐요.
Topics:하니스AI 모델코드 마이그레이션스킬 기반 리팩토링도메인 유지보수자동 검사AI 작업 효율프롬프트 엔지니어링AI 개발Maker Evan
