개인 사정으로 이번에는 텀이 길었네요.

"모델보다 구조가 경쟁력"이라는 토픽이 여러 번 보였는데, 제 생각과도 부합하는 점이 있어서 다뤄봤습니다.

피드에서는 Claude Code가 연달아 큰 기능을 내놓은 이야기, 그리고 빠른 도구가 가져온 그늘까지 짧게 정리했습니다.

포커스

모델은 바뀌지만 구조는 쌓인다는 이야기.

모델이 아니라 시스템이 당신을 잘하게 만든다

최근 제 눈에 띈 문장이 있습니다.

"프런티어 모델이 당신을 잘하게 만들지 않습니다. 당신의 시스템이 그걸 합니다. 모델은 몇 달마다 교체되지만, 워크플로우와 전술과 방법론은 복리로 쌓입니다."

kloss의 말인데요. 당연하게 느껴지는 말이기도 하죠.

도구가 빠르게 좋아지는 시대에, 많은 사람들이 어떤 모델을 쓰느냐에 집중합니다. Claude냐? GPT냐?

그런데 같은 모델을 쓰는 사람들 사이에서도 결과 차이가 납니다. 차이를 만드는 건 모델이 아니라 그 사람이 일하는 방식이라는 거에요.

Pragmatic Engineer가 900명 이상의 엔지니어를 대상으로 한 설문 결과도 비슷한 이야기를 하고 있었습니다. 결과에 따르면 AI 도구에 대한 반응은 크게 세 가지로 나뉩니다. 

품질을 중시하며 AI를 대규모 리팩토링에 활용하는 빌더.

결과 중심으로 빠르게 출시하는 쉬퍼.

AI 덕에 속도는 올라갔지만 기술 부채를 남기는 코스터.

세 그룹의 차이는 어떤 도구를 쓰느냐가 아니라 어떻게 일하느냐에서 갈렸습니다.

같은 Claude Code를 쓰는데, 누구는 50만 줄의 코드를 안정적으로 만들고 누구는 품질 저하에 좌절합니다. 90일 동안 50만 줄 이상을 작성한 사용자가 공유한 원칙은 단순했습니다. (저는 아직 거부감이 있습니다만)모노레포, 모듈화된 구조, 스킬 파일. 다 구조 이야기입니다.

하네스는 얇게, 지능은 스킬에

그렇다면 그 구조를 어떻게 만들어야 할까요.

kloss의 게시글을 또 빌려와야겠네요. "하네스는 얇게, 지능은 스킬에. 이걸 이해하면 AI 모델이 좋아질수록 네 스킬도 함께 좋아진다. 이걸 이해 못하면 에이전틱 디버깅 유지보수를 24시간 하게 된다."

이젠 ‘하네스’라는 단어도 너무 자주 들어서 식상하죠.

하지만, 반복해서 이야기할만한 이유는 있다고 생각합니다. 요리사로 비유하자면, 주방 세팅의 중요성은 아무리 강조해도 지나치지 않은것처럼요. 하네스는 레시피 카드나 요리 방법이 아니라, 어디에 어떤 재료가 있고, 어떤 순서로 일이 흐르는지 짜여진 구조를 말하는거니까요.

핵심은 이 구조를 얇게 유지하라는 겁니다. 하네스에 판단까지 집어넣으면 복잡해지고, 복잡해지면 모델이 발전해도 하네스 자체가 병목이 됩니다.

판단은 개별 스킬에 맡기고, 하네스는 그걸 연결하는 얇은 레이어로만 남겨야 한다는 말이죠.

Muratcan Koylan도 같은 날 비슷한 이야기를 했는데, 좀 더 구체적이었습니다. 하네스가 두꺼워지면 컨텍스트가 과부하되고, 루프가 커지면 프롬프트와 스킬이 아키텍처를 보상하려 한다고요. 

그리고 보정 루프를 완전히 제거해서 레이턴시를 37초에서 7.5초로 줄인 방법을 화이트페이퍼로 정리 중이라고 밝혔습니다.

Lenny's Newsletter는 이 흐름을 좀 더 실용적으로 정리했습니다. 에이전트 아키텍처를 세 가지로 분류하는 프레임워크입니다.

규칙 기반으로 정해진 흐름대로만 움직이는 결정론적 자동화.

상황을 판단해서 다음 행동을 정하는 ReAct 에이전트

여러 에이전트가 협력하는 멀티에이전트 네트워크.

이 세 가지가 완전히 다른 구조이고 다른 비용과 시간이 필요한데, 많은 팀이 이를 같은 스프레드시트에 올려놓고 우선순위를 정하다가 혼란에 빠진다는 겁니다.

그리고 기업 기회의 ...