이번 주 내내 다양한 설계 작업을 했다.

난 피드백 루프를 짧게 가져가져 계속 점진 개선하는 걸 좋아한다. 전형적인 발산형 사고방식이라 미친듯이 발산하며 머리 속에 노드들이 연결되다 어느 단계에 이르면 방향과 기준 잡고 (내 기준으로) 갑자기 크게 선회해서 빠르고 깊게 수렴하기 때문. 느리면 발산하며 노드 연결하는 게 더뎌서 오히려 내 사고방식에 잡음이 생김.

이런 내 입장에서 작업들에 대해 AI 모델들을 종합 평가하자면,

• Claude : 가장 준수함.

• ChatGPT : 겉핥는 수준으로는 괜찮음. 근데 조금만 깊어져도 그럴싸하지만 하나마나한 말을 반복하여 있어보이는 척 하는 경향이 있어서, 빠르게 키워드와 용어 파악 용도가 적당. thinking 모델은 좀 더 낫지만, 느려서 덜 쓰게 됨.

• Gemini : 희한할 정도로 거짓말을 많이 함. 지적하면 수용하는 척 말하다가 끝에 가서 굽히지 않고 우김. 가장 먼저 탈락.

이번엔 설계 주제별로 AI 모델(?)과 AI (코딩) 에이전트를 비교 평가 하자면, 용도에 따라 효용이 다르긴 하지만 전체적으로는 AI 에이전트가 나음. 코딩 거의 안 해봤거나 감 다 죽은 아키텍트가 AI 모델이라면, 실무자가 팀을 이뤄 현실적이고 실행 가능한 설계하는 모습을 AI 에이전트가 보임.

1. 플랫폼 아키텍처 설계

ai 모델이 지식 측면에선 확실히 인간을 압도하긴 함. 근데 정렬하고 연결하고, 의도를 담는 건 굉장히 못함. 인간을 대체하긴 개뿔.

AI (코딩) 에이전트는 좀 더 나음. 적어도 엔지니어링 측면에서 견적을 내어 현실성 있는 문제 정의를 하거나 근거를 제시하는 편. 하지만 역시나 뭔가 피드백을 주면 “좋은 지적입니다!”, “훌륭한 분석입니다.”, “날카로운 의견입니다”라며 뒤늦게 의도와 구조를 파악함. 즉, 기술적으로 연결성이나 연동성까지는 계획하지만, 통제해주지 않으면 아키텍처에서 요소(노드)가 계속 증식하는 상황에 빠지는 편. A 기능은 a를 쓰고, B 기능은 b를 쓰고, 계속 증식 증식. a를 쓸 거라면 그 a의 효용과 가치, 용도를 최대화해서 관리 비용을 늘린 것을 넘는 역할을 정의해야 하는데, 그런 건 역시 못함.

2. AI 에이전트 설계

흥미롭게도 AI 에이전트로 AI 에이전트를 설계하는 걸 가장 잘함. 여러 오픈소스 AI 에이전트를 클론하여 분석시키고, 그걸 기반 지식으로 삼아 설계한 효과가 큰 것같긴 하지만.

특히 Orchestration 하는 에이전트와 하위 에이전트의 협업 구조를 잘 잡았음. 에이전트 간 협업 구조에서 컨텍스트 오염이나 중첩, 지시 오염 가능성을 고려하며 설계하는 걸 보는 건 재밌었음.

정작 자신의(?) 가장 큰 적이자 한계인 메모리(context window) 부족에 대한 대비는 아예 하지 못하는 건 안타깝고 웃김.

“너 방금 compaction 해서 내 장문의 프롬프트에 대한 이해도가 확 떨어졌거든. 만약 하위 에이전트들이 긴 시간 작업하다 메모리 꽉차서 바보되고, 바보스럽게 handoff 하면 orchestrator는 어떻게 해야할까? 몰라서 의견과 답을 구하는 거 아냐. 너가 설계에 빠뜨린 주요한 작업 수행의 고려사항이 빠져서 하는 말이야. 너네 엄마 아빠가 이거 관련해서 블로그에 글도 썼더라.”

(물론 감조차 못잡길래 토큰 아까워서 안내 해줌)

3. 디자인

가장 토큰 가성비 안 나오는 설계 작업이었음.

어느 AI 에이전트든지 가장 못하는 설계. 특히 IA와 디자인 시스템에 있어서는 아직 갈 길이 매~~~~~~~~~~~~우 멀다는 걸 다시 확인함. 그러니 알록달록, 올록볼록한 디자인을 양산하고, 디자인 좀 친다는 AI 에이전트들도 시각적으로 괜찮은 걸 만들지 몰라도, semantic, IA, 디자인 의도, 역할 같은 것에 대해서는 다들 매우 멍첨함.

“목록 페이지에서 가장 중요한 기능과 주제, 역할이 뭘까? 그럴싸해 보이는 걸 잔뜩 붙여놨는데, 그 요소들과 테이블 목록, 필터 중 이 페이지는 어떤 목적 달성이 가장 중요할까?”

갑자기 급 흥분해서(?) 테이블에 외곽선 두르고 난리 쳐놓음.

“자, 넌 눈이 없어. 그리고 내겐 미감이 부족해. 그러니 우리 시각 미감으로 디자인의 행위를 개선하지 말자. 그건 나중에 팔레트나 컴포넌트 변수를 전문 디자이너가 건드려줘도 개선돼. 하지만 우리는 IA나 컴포넌트 구조와 역할 측면에서 더 나은 엔지니어링을 할 수 있지 않을까? Layout 컴포넌트는 그냥 다른 컴포넌트 wrapper가 아냐. 배경색과 외곽선 있는 컴포넌트는 더더욱 아니고. layout 컴포넌트이니 배치를 책임지지 않겠어? 반응형 디자인을 한다면 반응형 배치에 대한 역할을 맡고 책임을 져야겠지? 개발자는 배치 관련 개선을 할 땐 layout류 컴포넌트에만 집중하면 되도록. 그럼 layout 계열 컴포넌트에 필요한 props와 정책은 뭘까? 여백 등 시각적 요소를 props로 전달하면 layout 컴포넌트를 쓰는 페이지마다 여백이나 배치가 달라지니 일관성이 떨어지겠지? 목록 페이지에 기대하는 배치와 정보 인식 흐름이 있는데, 그렇다면 여백 등은 기본적으로 잡고 있어야겠지? 크기 값은 변수에서 바꾸면 되고. 그럼 여백 크기가 아니라 variant가 더 필요하지 않을까? 그게 디자인 시스템으로 정의되어야 활용 컴포넌트나 하위 구성 컴포넌트에서 배치라는 외부 관심사에 의존하지 않을 거 아냐”

또 흥분해서 variant 추가함.

빠르게 응답하면 재밌기도 하고 나도 생각 정리가 되어서 계속 할텐데, 몇 번 핑퐁하다보면 슬슬 반응이 느려지고 compaction 할 때마다 재교육(?)시켜야해서 결국 하나 하나 지시.

물론 아는 건 많아서 내 잔소리를 들으면 이론 배경을 파악하고 막 말하긴 함. 예를 들면 정보 위계 구조. 페이지별 주제와 목적, 용도를 자신이 놓쳤다며 그걸 분석해서 위계 구조를 설계하고, 분석해서 디자인 시스템 구축에 맞게 공통 컴포넌트를 구현하겠다고 말은 거창하게 하지만, 위계 구조 자체를 틀리게 짬. 그래서 결과도 틀림.

네 시간 동안 스타일 작업은 배제하고 컴포넌트 설계와 정규화, 구조화만 했는데, 한결 나아졌지만 여전히 손가락만 쳐다보며 이상한 위계를 짜는 건 어느 AI 에이전트든 마찬가지인 걸 보면, 이 부분은 확실히 개선 여지가 많아보임.

이뻐보이는, (역설적인 표현이지만) 그런 눈가리고 아웅하는 식으로 디자인 잘하는 척 하는 AI 에이전트는 있지만, 잠깐 보면 괜찮아보일 뿐, 몇 분만 만져봐도 산만하고 일관성 없고, 아무튼 구림.

“왜 너희 AI 모델과 에이전트들은 하나같이 보라색을 그렇게 선호해? 사람이 디자인한 현실 디자인들 보면 보라색이 각인될만큼 많이, 자주 쓰는 경우는 별로 없는데, 대체 어디서 뭘 줏어보고 와서 이렇게 보라색과 그라데이션을 쓰는거야?”

라고 물으니 재밌어함. (음? 재미를 느낀다고?)

---

물론 난 AI와 AI 에이전트를 매우 애용함. 코딩 자체도 이젠 거의 안 함. 틀리거나 이상하면 고쳐주고 여러 방법으로 지침화 해놓으면 되니 갈수록 손 코딩량이 줄어듬. 특히 최근엔 (claude code 기준) skills나 sub agent를 AI 에이전트가 더 활용해서(정확히는 얼마 전까지는 애초에 그런 존재를 활용할 생각조차 못하거나 까먹어서 사용 안하는 것에 가까웠지만) 만족하며 사용함.

하지만 만족한다고 해서 기대를 충족하는 건 아님. 여전히 기대에 못미치는 상황과 작업이 계속 발견됨. 일부는 AI 에이전트가 사용할 tool을 계획하고 구현하여 보완하거나 극복하지만, 디자인은 매우 잘 안 됨. 시간, 토큰 가성비가 안 나옴. 디자인(설계) 역량 있는 사람이 압도적임. 현재 내 경험에 놓고보면 디자인은 사람 대체 불가.