(나의 게임 현재 데모 화면 보기만해도 촌스럽다.)
이번달은 비즈니스 미팅 관련해서 바빴다. 총 4곳과 미팅했고, 그 중 한곳과 성사됐다. 스타트업 사내 ERP 솔루션 납품으로 미팅을 했다. RAG를 추가해달라는 미팅이었다.
미팅 준비때문에 글 쓸 시간도 없고, 취미생활을 할 시간이 없었다.
한국의 명절도 끼어있고, 비즈니스 미팅도 꽤 많았다. 3곳정도 면접을 봤고 한곳에 납품관련해서 작업을 했다. 대략 450정도의 금액이다. 옛날이면 800짜리 일이 참 많이도 금액이 줄었다라는 생각이 든다. 하지만 요즘 어딜가나 AI로 만들어준다고 하니 높게 부르면 다른 업체를 가기때문에 비용을 높게 부르기 어렵다. 심리적 앵커선이 존재하는 느낌이다. 이 선은 대체로 월 450선이다.
그리고 이번에 한국 대기업업체 쪽 큰 문제가 바이브 코딩과 관련한 이야기였다는 소리를 들었다. PM들을 모아서 프롬프트 입력만으로 코딩해서 프로그램쪽 외주 없게 한다고 큰소리 쳤지만 결국 버그를 해결 못하고 있다는 이야기가 현장에서 돌았다. 그래서 향후 2~3년 정도후에 상황이 정상화 될거라고 나에게 선배가 이야기해주었다.(어느 기업인지는 알지만 말을 하지는 않을것이다.)
선배는 하네스를 개발 안해서 그렇다라고 하지만 나는 그렇게 생각하진 않는다.
어쨌건 이번에 시간이 남고 한국에서 하네스 이야기를 나눈것때문에 몇가지 생각을 써보려고 한다.
개발자가 자기 하네스 가져야한다 나는 의미가 없다 생각한다.
하네스 엔지니어링을 해서 싼 API를 존나 써서 단가를 낮춰라? 솔직히 내 시간 대비 이게 장난감 이상의 가치가 있는지 잘 모르겠다. 내가 AI 프레임워크를 개발하는 사람도 아니고, 본업은 결국 ERP나 웹사이트를 설계하고 납품하는 것이다.
그래서 내 워크플로우에 맞춰 직접 코드를 짜서 하네스를 만들어야 한다는 게 무의미하게 느껴진다. 막상 RAG니 뭐니 직접 만들어서 써봐도 그렇다. pi.dev 같은 DIY 도구들의 장점이 '내 워크플로우에 완전히 개인화할 수 있다'는 것인데, 치명적인 단점은 커뮤니티 지원을 받을 수 없다는 거다. 반면 코덱스(Codex)나 클로드 코드(Claude Code) 같은 공식 도구들은 뭔가 잘못되면 거대한 커뮤니티의 지원과 레퍼런스를 얻을 수 있다.
애초에 AI 모델 API 자체가 점점 자기네 공식 하네스에 최적화되어 발전하는 추세다. 결국 프론티어 모델은 자체 하네스와 강결합될 수밖에 없다. 커스텀 하네스를 쓰면 툴 설명이나 프롬프트를 일일이 깎아서 넣어줘야 하는데, 모델이 바뀔 때마다 그 하네스에서 잘 먹히던 도구를 빼거나 설정을 뜯어고쳐야 한다.
"API가 싸니까 장점이다!"라고들 하지만, 사실 내 시간(인건비)이 훨씬 더 비싸다. 나한테는 쳐내야 할 본업이 있다. 그렇다고 LlamaIndex나 LangGraph 써가면서 무거운 멀티 에이전트를 돌리는 것도 문제인게 모델이 바뀔때마다 새롭게 세팅해야한다. 그리고 그건 인하우스 개발팀이 있는 회사 단위에서나 할 일이지, 나 같은 솔로 프리랜서에게는 오버엔지니어링이다.
물론 여전히 일부 작업에서는 pi.dev가 좋긴 하다. 보안 관련해서 클로드 코드나 코덱스 문제가 될때, GLM 등으로 프록시 쓰기 싫으면 그냥 pi.dev를 켜서 돌리기도 하니까. 하지만 그럴 바엔 웬만한 작업은 공식 하네스에 MCP나 Skills로 도구를 붙여 쓰는 것과 큰 차이가 없다고 느낀다. 구독제를 돌린다고 가정하면 말이다.
딥시크(DeepSeek)가 코드를 코드를 잘 짠다는 건 인정하지만, 하지만 막상 거대한 코드 베이스를 판단할 때는 여전히 버벅댄다. 그 큰 코드 베이스를 모델에 이해시키려고 또 도구를 만들고 파이프라인을 짜다 보면 결국 내 '시간'을 소모하게 된다.
제일 화가나는 건, 그렇게 시간을 써서 도구를 만들어 놨는데 모델이 또 업그레이드되면 그 도구 중 일정 부분은 필요가 없어지거나 아예 걷어내야 한다는 거다. 과거에 최적화해 둔 프롬프트와 툴 설명이 오히려 새 모델의 똑똑해진 성능을 방해하는 느낌이 든다. 즉, 내가 짠 하네스의 기능 자체가 감가상각이 되어버리는 거다.
거기에 AI라는 것 자체가 비결정론적이고 확률적이다 보니, 에러가 났을 때 이게 내 커스텀 하네스의 문제인지 AI 모델의 확률적 헛소리인지 판단조차 어려운 경우가 잦다. 디버깅 지옥이다.
그래서 내가 내린 결론은 단순하다. 그냥 프론티어 모델은 공식 구독제로 운용하는 게 베스트고, 그 메이저 하네스 위에 터널을 뚫어서 커스텀 프로바이더(OpenRouter 등)를 프록시로 물려 쓰는 게 훨씬 낫다.
요즘 나는 코덱스 커스텀 프로바이더나 클로드 코드 커스텀 프로바이더를 세팅해서 다른 AI 모델들을 끌어다 쓴다. pi.dev 같은 툴은 점점 손이 안 가게 된다. 결국 취미용이나 순전히 폐쇄망에서 쓸 수 있다는 장점만 남을 뿐, 그 외에는 내 피 같은 시간을 태워서 관리 비용을 지불해야 하는 DIY 장난감 같다.
AI는 한계 이야기
최근에 현장 어딜 가도 전부 AI 워크플로우 도입과 AI 만능론이 도입되고 있는데, 사실 한국에서는 소프트웨어 엔지니어링이 제대로 정착되지 않았기에 한국쪽 이론들은 자세히 듣지 않는 편이다. 주로 소통하는 중국과 미국 개발자들과 이야기한다.(이번 미국 개발자들은 클로드에 노션 비슷한 기능이 추가될거라는 소문이 들렸다고 한다)
개인적으로 AI 만능론과는 달리 프론티어 AI 모델을 계속 사용하면서 이상한 느낌이 든다. 모델은 분명 발전하고 있는데, 개발자로서 체감하는 변화는 예전만큼 크지 않다.
특히 코딩에서는 그렇다. GPT 5.6 Sol 정도만 되어도 함수나 클래스 단위의 구현에는 이미 충분히 강했다. 이후 모델들은 더 빠르고, 더 적은 토큰으로 같은 일을 하고, 이미지나 3D 같은 다른 영역에서는 눈에 띄게 좋아졌지만 정작 코드 자체의 품질은 더 떨어졌다.
즉, 오히려 어떤 능력을 얻으면서 다른 능력이 조금씩 희생되는 것처럼 느껴질 때도 있다.
Astra는 3D 에셋 생성 같은 영역에서는 인상적이지만, 내가 실제로 사용하는 코딩에서는 5.6 Sol보다 낫다고 느끼지 못했다. 최근 OpenAI 발표 역시 개발자의 관점에서는 모델 성능의 근본적인 도약보다는 사용량 조정, 더 비싼 상위 요금제, 새로운 제품 인터페이스 같은 이야기가 더 크게 보였다.
현재 모델들은 이미 작은 단위의 코드를 상당히 정밀하게 생성할 수 있다. 여기서 정확도를 조금 더 높이는 것만으로는 큰 변화가 나오기 어렵다. 다음 단계로 가려면 결국 두 가지 방향 가운데 하나가 필요하다는 것이다.
하나는 모델이 수백만~수천만 줄짜리 거대한 코드베이스를 실제로 이해하고 작업할 수 있게 되는 것이다.
다른 하나는 매우 적은 출력만으로도 거대한 문제를 압축해서 해결할 수 있을 정도로 지능 자체가 발전하는 것이다.
후자는 통계적·계산적 한계 때문에 현실성이 낮고, 전자는 가능하지만 비용이 엄청나게 크다. 지금 AI는 둘 다 어느 것도 해결 못하고 하네스라는 임시 방편으로 해결하고 있단 생각을 한다.
이 관점은 내가 실제 코딩에서 느끼는 문제와도 어느 정도 맞아떨어진다.
지금 AI가 약한 부분은 전역적 일관성이다.
함수 구현
메서드 분리
제네릭 작성
Result/Option 체이닝
정책 테이블
lookup table
리팩토링이런 국소적인 문제는 이미 인간보다 잘한다. 전반적으로 gpt 5.2 이후로는 크게 차이가 나지 않는다.
문제는 그 함수들이 들어가는 전체 시스템의 관계를 장기간 유지하는 것이다.
코드베이스가 커질수록 중요한 것은 새로운 코드를 얼마나 잘 만드는지가 아니라,
AI는 눈앞의 코드에서는 사람보다 훨씬 빠르게 좋은 구현을 만들어내지만, 긴 작업을 맡겨 놓으면 국소적인 해결책을 계속 붙이다가 전체 구조를 흐트러뜨리는 경우가 아직 많다.
그래서 결국 AI에게 흔히 목표를 제공하는 /goal 명령어를 써서 코딩하면 코드 베이스가 엉망이 되는 경우가 잦다.
내가 AI를 사용할 때도 결국 이 문제 때문에 전체 작업을 맡기기보다는 직접 깃허브 레퍼런스를 찾아보고 그 구조를 참조해서 만든다. 대체로 마이크로소프트 깃허브와 개발 예제에서는 이러한 예제를 풍부하게 제공하는 편이다.
먼저 스펙을 확정하고 MVP와 vertical slice를 만든 뒤, 함수나 클래스 단위로 작업을 나눠 AI에게 구현을 맡긴다. 큰 코드베이스에서는 AI에게 기존 코드와 의존성을 먼저 조사하게 하고, 내가 그 결과를 검증한 뒤 정확한 작업 범위를 다시 지정한다.
이 방식에서는 사실 최신 모델과 조금 이전의 프론티어 모델 사이의 차이가 생각보다 작다.
함수 하나를 잘 작성하는 능력은 이미 상당히 높은 수준에 도달했기 때문이다.
내 생각에 AI는 이 구간에서 오래 있을 것 같다.
아마 시연 영상들도 대부분 원샷으로 얼마나 눈에 아름다운 걸 만드느냐 정도에서 유지될 것이다.
단일 함수나 화면 UI, 3D 에셋은 그 자체로 완결된 데이터(Self-contained data)이므로 AI가 패턴을 쉽게 모방할 수 있다. 하지만 시스템의 전역적 일관성은 코드라는 텍스트 바깥의 비즈니스 룰과 오프라인 회의에서 결정된다 따라서, AI는 이 '보이지 않는 맥락'을 학습한 적이 없으므로, 코드가 길어질수록 눈앞의 텍스트에만 매몰되기때문에 결론적으로 AI 시연으로 얼마나 아름다운 걸 뽑느냐의 승부가 될 것이다.
나는 이걸 데모주도 자본주의라고 부르고 싶다.
어쨌건 최근에는 일이 많아 자료 조사와 논문들을 읽을 시간이 없다. 개인에게는 좋은 일이기도 하지만, 또 한편으로는 내 제품을 만들어야 이 지옥에서 벗어난다는 생각도 한다. 늘 어렵다.