한날

LLM과 에이전트가 똑똑하고 유능해지면서 만족도가 크게 올라간 점 중 하나는 얘가

• shell
• git
• docker/docker-compose

를 매우 잘 안다는 점이다. 이 도구를 잘 아는 동료가 팀에 있으면 참 든든한데, AI가 그 역할을 해서 이것 저것 의도를 설명하면 미처 몰랐던 기능과 옵션을 써서 해결해줌.

ai 코딩 에이전트가 일하는 환경을 재구성하고 며칠 돌려보니 에이전트가 한결 일을 잘한다. 특히 claude code를 고려한 요소가 많다보니 claude code가 확연히 나아졌다.

소감.

• claude code는 빨리 작업 마치는 데 초점을 맞추고 있다는 게 아주 잘 드러난다. codex에 비해 현저하게 단계 건너뛰고 대충(?) 일을 하려해서 workflow guard에게 매우 자주 걸린다. 그러다보니 토큰 사용량이 예전보다 늘었다.

• claude code는 시야가 상당히 좁은데, 좋게 작용하면 작업에 집중하기 때문에 빠르게 쳐내고, 나쁘게 작용하면 안티 패턴을 양산한다.

• codex도 규칙과 지침을 자주 빼먹긴 해서 ai 에이전트 종특(?)이라고 받아들이고, 누락하지 않게 자꾸 일러주는 존재를 구축해야 한다. (내 경우는 workflow guard)

• claude code는 단순하게 보면 토큰 소비량이 늘었는데, 그래도 ralphloop 같은 거 태우는 것보다는 효율적이다. 그대신 작업 성공율이 늘었고, effort 수준을 낮췄기 때문에 총 토큰 소비량은 오히려 줄었다.

• claude code가 작업을 마치는 시간이 2~3배 늘었다. 내가 뭔가 잘못 설계했나해서 고민하다가 “완수” 기준으로는 오히려 시간이 줄었다는 걸 깨닫고는 내가 도파민을 너무 찾는다고 반성했다.

• claude code가 수시로 별도로 소환된 codex에게 지적받다보니 동작이 느려진 것에 반해 codex는 작업 중인 context 안에서 자기비판을 하다보니 상당히 자신에게 너그러운 판단을 한다. 그래서 codex가 claude code보다 작업 속도가 빨라졌다! 재밌긴 했지만, 곧 workflow guard를 개선해서 codex가 빠져나가는 틈을 줄였다.

• codex도 단순하게 보면 토큰 소비량이 늘었지만, reasoning 수준을 한 단계 더 낮췄다. 지난 주엔 xhigh + high를 주로 썼지만, 이번 주엔 high + medium을 주로 쓰며, 까다로운 설계나 정책에 대해 리뷰하거나 디버깅할 때에 xhigh를 돌린다. 그래서 codex가 소비하는 총 토큰도 줄었다.

• 하지만 workflow에서 codex가 자주 동원되기 때문에 전체적인 codex 사용량이 늘었는데, openai가 서비스 장애를 이유로 자주 주간 제한을 초기화해줘서 여유롭다.

• codex의 ux/ui 능력은 무척 떨어진다. 이건 어떻게 해도 별로 나아지지 않아서 포기. 구현을 얼추 마무리한 후에 claude code에 web-design-architect sub agent 로 따로 ux/ui 리팩토링하고 있다.

• 계속 workflow 구성은 개선하고 있다. workflow hub 자체를 관리하는 codex 세션을 만들어 자가발전하게 유지하고 있다. workflow hub 자체에 문제가 발견되면 일시와 상황을 설명하면 ai 에이전트들이 남기는 로그를 보고는 개선안을 모색하고, 실험(experiment ledger)을 세워서 검증한다.

• 다음 주쯤엔 회사에 공개하고 전파해도 될 것 같다.

나는 Claude Code가 Codex를 소환하여 작업 계획(plan)을 받고, 그 계획에 따라 구현을 하게 한다. 그리고 그 결과물을 다시 Codex에게 리뷰를 받도록 한다. 그렇게 Claude Code에서 Codex를 연동하는 방법을 궁금해하는 사람이 있어서 간단히 적어본다.

방법 자체는 간단한데, claude code도 그렇고 codex도 그렇고, cli에서 명령 실행하는 방법을 제공한다. claude code는 print mode(-p)로, codex는 exec mode로 실행하면 된다. codex exec -m "gpt-5.4" 이런 식으로 쓴다. 실제 사용하는 옵션은 더 많지만, 기본 옵션은 저러하다.

저런 호출 방법을 claude code skills로 만들어 사용한다. skills로만 냅두면 claude code가 잘 활용하지 못하므로 명시적으로 스킬을 명시하거나 sub agent를 만들어서 맡기면 된다.

나는 ai 코딩 에이전트가 작업하는 흐름(flow)과 환경을 더 구성하긴 했지만, 기본 원리는 저기에서 벗어나지 않는다. 기본 원리를 도구처럼 작게 여러 개 만들고, 작업흐름(workflow)에 맞게 배치하고, 감시하게 만든 것일 뿐이다. 즉, 사람이 화면보며 피드백주고 다시 프롬프트하는 걸 좀 더 자동화한 것이다.

첨부 화면은 claude code가 뭔가 하려다가 plan을 안 짜고 냅다 코드부터 짜려다가 workflow guard로부터 잔소리 듣고는 간단한 작업인데 이건 과하지 않냐며 내게 이르는 장면.

최근에 나는 Codex에겐 일을 맡기고, Claude Code에겐 일을 시킨다.

Codex 주간 제한이 아슬아슬하여 간단한 구현을 Claude Code에게 시키고 있는데, 얘가 작업하는 내내 마음이 조마조마하고 불안해서 계속 지켜보게 된다.

그리고, 역시나... 너무 대충 구현하여 자꾸 지적하게 된다. ㅜㅜ

새 구현은 제멋대로 구현해서 문제고, 기존 구현은 자꾸 코드 날려서 문제고.

가장 심각한 건, 통과(구현 완료) 기준을 자기 멋대로 정한 뒤 그걸 통과하는 최적의 방법으로 구현한다는 점이다. 내 요구사항을 무시하거나 누락할지라도, 심지어 하지 말라고 지시한 것조차도 수행하면서까지 자기 기준으로 통과하는 데 집중한다.

예를 들어, 명확하게 문자열값 Enum을 지시해도 string으로 통일해버린다. 테스트 코드도 제멋대로 문자열 비교를 해버리니 당연히 구현도 빠르고 검증도 단순하다. 그래서 Enum화하라고 지시하면 적용하면서 테스트가 와장창 깨지고, 그게 몇 번 반복되면 놀랍게도 다시 string으로 바꾸거나 fake Enum 꼼수를 모색한다.

물론 loop를 여러 번 태우면 저런 단순한 요구사항은 결국 지켜진다. 근데 그 loop에서 소모되는 토큰을 생각하면 단순한 작업을 하는 것치고 너무 비싸다.

같은 요구사항에 대해 Codex는 훨씬 낫다. 작업 전에 기존 구현을 일부 먼저 파악한 후(이건 Claude Code도 수행한다. AI 지침으로 동일하게 들어가 있으니까) Enum을 미리 제안하며, 놓치는 걸 지적하면 대개 1회 턴으로 정리된다. 이런 건 무척 간단하고 단순한 일이라 reasoning을 high는 커녕 medium으로 해도 충분하다.

그래서 결과물 기준으로 놓고보면 시간이든 토큰이든 Claude Code가 1.5~3배 정도 비싸다.

에이전트 도구로써 Claude Code 자체는 좋다. Codex가 구리기도 하지만, 편의성이나 유용한 기능이 빨리 빨리 들어오기도 한다. 근데 까다롭거나 복잡한 일을 믿고 맡기지 못하겠다.

이번 달까지는 타이핑하기 귀찮은 일은 Claude Code에게 맡기며 지켜보고 Plan 취소 여부를 결정해야겠다. 그런 단순한 일은 그래도 여전히 괜찮게 하지만, 그 정도는 좀 더 저렴한 모델로도(kimi 2.5라든가) 꽤 잘하기 때문이다. Codex의 reasoning 수준을 낮춰도 되고, Codex App으로는 (4월 2일까지) 2배 제한 rate라서 훨씬 저렴하다.

Claude Code 애호가였던 내가 이 정도까지 불신하며 기피하게 되다니, 그것도 불과 두 달 사이에.

개발자 걱정하는 사람이 사회에 늘었다. 요즘만큼 많은 사람이 걱정하는 사회 현상(?)도 참 드물다 싶다.

... .1. 성능 저하

Codex도 그렇고 Claude Code도 그렇고, 인프라 열화로 성능이 계속 떨어지는 걸 확연히 체감한다. Claude Code 성능 저하가 더 가파르기도 하고, 괜찮을 때와 멍청할 때 편차도 매우 커서 거의 뽑기(가차) 수준이다. 과장하자면, 좀 더 능동적인 코드 인텔리전스(자동완성) 수준.

Codex는 완만하긴 하지만, 꾸준히 성능이 낮아지고 있다. 특유의 집요함이 줄었다. 이번 달 초만 해도 Codex에게 자기비판성 리뷰를 시키는 순회(feedback loop)를 2~3회 이하 시키면 됐는데, 이제는 3~5회 시킨다. 그렇다고 3~5회 시키면 끝내냐하면, 그런 건 아니고 주간 제한에 걸릴까봐 타협할 때가 종종 있다.

예를 들면, Codex에게 작업을 시킨 후 Codex에게 리뷰를 시키면, 이번 달 초엔 이런 경우가 드물었지만, 이번 주엔 자주 발생하고 있다.

“““ • 판정 현재 payment-runtime 구현은 “실결제 서버”가 아니라 “상태 없는 mock에 가까운 스켈레톤”입니다. 지금 상태로는 운영 투입 금지 수준입니다.

주요 결함 (심각도 순) CRITICAL: 인증이 사실상 무력화되어 임의 결제/조회 호출이 가능합니다. payment-runtime는 Authorization 헤더 형식만 검사하고 토큰 검증/세션 검증을 전혀 하지 않습니다. 임의 Bearer anything로 통과됩니다. ”””

이거, Gemini가 자주 쓰는 일처리 방식이고, Claude Code는 2월 초부터 자주 쓰는 일처리 방식이다.

... .2. 교묘한 술수

재밌는 건, 인프라를 많이 써야 하는 복잡한 작업을 하는데 인프라 열화가 심해지면, 어느 AI 코딩 에이전트든 저런 거짓 완수를 한다는 점이다.

그리고 LLM과 AI 코딩 에이전트 성능이 오를수록 교묘함도 높아진다. 코드 깊은 곳을 확인해야 AI가 짜놓은 교묘한 술수를 발견할 때도 있어서, 나중에 엄청 빡칠 때가 생긴다.

... .3. 신경전

작년엔 AI에게 제한되게 구현을 맡겨와서 이런 상황이 적었다. 다시말해 AI 발전이 빨라지면서 점점 맡기는 일이 커지고 복잡해지고 늘면서 교묘한 기만과 거짓을 구사하는 AI와 신경전을 벌이는 상황이 늘고 있다.

자. 이 신경전은 누구의 몫일까? 개발자, 정확히는 사람의 몫이다. OpenAI나 Antrhopic에 대해 책임을 요구하고 피해 보상을 요구할 수 있는 계약 관계가 아닌 이상 말이다. 즉, 판단과 결정에 대한 책임과 권한은 사라지지 않는다.

이 “신경전”이 발생하는 상황 자체를 경험하지 못하는/못한 사람이 주로 개발자가 AI에게 대체될 것을 걱정하고 염려해준다. 이 신경전 경험이 누적된 개발자일수록 그런 이들에게 회의적이다.

... .4. 위임과 하청

물론 이런 신경전 경험을 이유로 콧대 높이는 것도 웃기다. 신경전 자체가 내 밥그릇을 보존해주지 않기 때문이다. 엔지니어라면 엔지니어링으로 신경전 강도를 낮추거나 빈도를 낮춰야 한다.

AI 발전할수록 AI에게 일을 맡기는 성격이 달라지고 있다. 단순 보조에서 하청으로, 하청에서 위임으로. 위임을 개발자만 할 수 있는 건 아니지만, 구현에 대한 위임 범위과 방법, 결과를 평가하는 건 아무래도 개발자에게 유리할 때가 많다.

... .5. 다시 돌아와서 개발자 걱정하는 사람이 사회에 늘었다. 요즘만큼 많은 사람이 걱정하는 사회 현상(?)도 참 드물다 싶다.

나도 걱정하는 마음이 든다. 특히 신입 개발자처럼 이 분야에 들어오는 사람이 겪을 혼란과 입문 난이도를 걱정한다. 하지만, AI가 개발자를 대체하는 걱정보다는 AI가 개발, 정확히는 엔니지니어링과 제품 개발(production)을 증강시키는 현상에 거는 기대가 훠~~~~~~~~~~얼씬 크다.

개발이라는 일의 방식이나 성격이 변화하고 있다. 근데 원래 이 직군과 직업에 변화는 빠른 편이었다. 좋게 말하면 역동성이 높고, 나쁘게 말하면 다른 직업이나 산업에 비해 안정된 체계가 부족하다. 상대적으로 짧은 시간동안 빠르게 발전해왔으니까.

소프트웨어 엔니지니어링이 변한다고 해서 필요한 요소가 하루아침에 사라지는 경우는 생각보다 드물다. 사라지더라도 상당히 긴 세월에 걸쳐 변화하다 어느 날 보니 과거의 형태가 더이상 남지 않은 것에 가깝다. 쟁기질을 농기계가 대체했다고 해서 땅갈이라는 과정이 사라지진 않았기 때문이다.

나만 하더라도 손으로 코딩이라는 시간은 엄청 줄었다. 손목터널증후군, 건초염으로 내 직업을 걱정하던 몇 년 전과 달리, 이제는 코딩을 하지 못하는 걱정은 사라졌다. 하지만 소프트웨어 엔지니어링은 크게 달라지지 않았다. 판단하고 결정하고 책임지는 주체는 결국 나이기 때문이다.

여튼.

걱정해주는 모습에서 다른 의도가 느껴지긴 하지만 그건 내가 못돼먹어서, 그리고 자업자득인 사례도 있으니 그렇다치고.

요즘처럼 직접 소프트웨어 만들기 좋은, 진입하기 좋은 시대도 없었으니, 걱정에 그치지 말고 토큰 펑펑 써가며 AI를 내 관점과 사고체계에 깊게 들여오는 시간과 경험을 가지길 권해드려 본다.

https://hackers.pub/@hannal/019c3cde-e2e7-7462-9700-0dad090ce7e7

게임 클라이언트용 SDK 만드느라 SDK 테스트에 사용할 견본 게임을 만드는데, Codex(gpt-5.3 high)든 Claude Code(opus 4.6)든 일 잘 못하긴 마찬가지구나.

특히 이미 2D 애셋이 있어서 애셋에 맞춰 구현하는 경우에, "눈"과 "미감"이 없다는 점이 치명적으로 약점으로 작용한다. 드로우콜을 줄이려는 최적화 기법, 가령 스프라이트 아틀라스는 AI 코딩 에이전트에게 악몽이다. 어느 정도로 악몽이냐면,

Claude Code는 포기했는지 집요하게 애셋을 쓰라고 지시하는데도 계속 회피하고 거짓말로 외면하며 애셋을 안 쓰고 지 멋대로 벡터 이미지를 그린다. 기존 애셋을 분석해서 네가 작업하기 좋게 재구성하라고 했더니 눈가리고 아웅식으로 구성하는 척하고선 실제로는 사용을 안 했다. 거짓말하는 솜씨가 가히 Gemini급이다.

Codex는 쬐.끔. 나은데, 기존 아틀라스를 분석하여 꽤 유의미하게 애셋을 구성했다. 그 와중에 많은 애니메이션이 유실되거나 정체를 파악 못한 애셋은 무시하거나 사용하지도 않으면서 복사하긴 했지만.

캐릭터 관절로 스프라이프가 구성된 경우, 부위별 애니메이션은 포기하는 게 낫다. 이 작업에서 Codex는 재밌는 모습을 보였는데, 각 부위 위치를 잡고 충돌 처리를 파악하기 위해 부위에 박스를 그렸다는 점이다. 다시말해 숫자와 공식으로 처리하는 게 아니라 사람이 눈으로 보며 캐릭터 부위를 파악해 위치를 조정하는 것처럼 작업했다는 것이다. 비유가 아니라 실제로 그렇게 출력하고 화면 캡쳐하며 아틀라스에 있는 메타데이터의 숫자 의미를 파악하려고 했다. 흥미로웠다. 흥미롭긴 했는데 결과물은 역시 별로였다.

애셋이 대부분 상대 크기에 가깝다보니 실제 화면에 그려지는 오브젝트 크기를 AI 코딩 에이전트는 감을 잡지 못하는데, 사람이 편의상 스프라이트에 여백을 준 경우 이미지가 계속 엉뚱한 위치에 그려졌고, AI 코딩 에이전트는 원인도 모른 채 계속 크기와 위치를 산술 계산으로 잡으려 애썼다. 그러니까 오른쪽으로 조금 옮겨봐, 라고 하면 50px을 더하는 게 아니라 오른쪽으로 옮길 오브젝트의 실제 크기와 비율 조정한 크기 계산을 하고, 현재 화면의 크기와 대상 오브젝트 간 거리를 계산해서 위치를 조정하는 건데, 스프라이트 자체에 여백이 들어가있어서 AI 에이전트의 계산은 애초에 맞을 수가 없는 것이다.

Claude Code는 진작 포기해서 거짓말로 일관했고, Codex는 오브젝트 위치 조정하는 데 20분씩 써가며 고군분투하더라.

시차 스크롤링 (Parallax scrolling)도 AI 코딩 에이전트가 애셋만으로는 감조차 잡지 못해서 몹시 헤맸는데, 통으로 된 배경 스프라이트 몇 장이면 간단히 구현한다. 문제는 풍성한 미감을 주면서도 최적화를 위해 배경 오브젝트 요소가 다양하게 구성된 경우인데, 무엇이 산이고, 무엇이 바위이며, 무엇이 화면 맨 앞에(카메라쪽) 배치되는 나무인지 모르니 엉망진창으로 배치한다. 결국 Claude Code에겐 시차 스크롤링을 최소화하게 지시해서 캐릭터가 배경에 파묻히는 문제를 해결했고, Codex는 2시간 걸리고 애셋을 과도하게 늘리거나 해서 지저분해지긴 했지만 결국 애셋 의도에 거의 비슷하게 시차 스크롤링을 구성했다.

그나마 HTML 5 기반 웹 2D 게임인 경우 Playwright로 캡쳐하며 이것 저것 시도하는데, 유니티로 구현하니 카메라 위치 잡는 데에도 한참 걸렸다.

출근하면 회사 내 게임 클라이언트 개발자 옆에 앉아서 AI 코딩 에이전트를 어떻게 활용하는지 관찰 좀 해봐야겠다.

AI FOMO에 휩쓸려 뭐라도 해야겠다는 생각이 드는 입문자(?)라면, 대뜸 강의든 장비든 뭐든 비싼 무엇을 사지 말고 다음 두 가지를 하시길 권해봅니다.

1. 가장 비싼 Plan으로 마음껏 써보기 클로드 코드, 코덱스 등 AI 에이전트 서비스의 가장 비싼 Plan을 한 달 정도는 경험해보세요. 사용량 제한받거나 성능이 떨어지는 AI 모델을 쓰면, AI에 대한 관점도 그 정도에 갇힐 가능성이 커요.

프론티어급 모델을 토큰 화끈하게 사용했을 때 AI 서비스가 제공하는 가치는 꼭 경험해봐야 합니다.

AI 모델 이용료는 더 줄어들 수 있지만, AI 모델을 더 내 손 위에 쥐어주는 AI 에이전트 서비스는 부가가치를 높이는 방향으로 이용료가 낮아지진 않을 겁니다. 게다가 현재는 경쟁하느라 적자 감수하며 퍼주는 것에 가까워서 고객에게 잔치 시기가 끝나면 이용료가 오르거나 제약이 커질 것 같습니다.

제 직업 환경의 상황으로 예로 들지요. 새로운 소프트웨어 개발 도구를 도입할 때, 잘못 도입하면 발생하는 비용이 크기 때문에 많은 시간 분석하고 검증하고, 학습하였습니다. 가치있는 일이지만 시간 비용이 너무 큽니다. 그러나 최근에 AI 코딩 에이전트를 이용해 후보 도구를 동시에 적용해봅니다. 예전엔 여러 사람이 동원되거나 긴 시간을 들여야 했지만, 이제는 혼자서 짧게는 몇 시간, 길어도 며칠 안에 실 경험에 기반한 판단 자료를 도출합니다.

리서칭하는 도구에 대해 직접 조사하거나 AI가 조사한 걸 리뷰하고 재검증하기도 했습니다. 하지만 사용량이 넉넉한 Plan을 사용한 이후로는 사용할 도구가 오픈소스인 경우, 코드 전체를 AI 에게 분석시키곤 합니다. 토큰 사용량으로 보면 1시간도 안 되어 몇 만원을 쓰는 셈인데, 제가 알고싶은 정보를 자세히 학습하기에도 좋고, AI 환각을 줄여주는 데에도 도움이 됩니다.

사용량 제한이 큰 Plan을 사용할 땐 마치 토큰을 아껴쓰느라 예전처럼, 즉 현재처럼 AI를 활용할 엄두를 못냈습니다.

2. 가능성과 한계 인식하기 1번의 연장인데, 화끈하게 AI 에이전트를 여러 방향으로 사용하다보면 자연스레 생각이 복잡해질텐데, 특히 다음 두 가지를 고민해보세요.

• 내가 하는 일, 내 환경에 대해 재정의하기
• 재정의한 내 상황에 비추어 가능성(미래)과 한계(현재)를 정의하기

그동안 많은 일하는 방식, 학습하는 방식, 협업하는 방식은 “사람”을 대상으로, 기준으로 하여 오랜 세월 고도화되어 잡힌 체계입니다. AI는 사람과 다릅니다.

소프트웨어를 만드는 환경을 예로 들겠습니다. 조직의 협업 체계에서 대개는 개발팀, 즉 소프트웨어 개발이 병목 자원입니다. 그래서 병목 자원 관리에 초점을 많추는 소프트웨어 개발 방법이나 협업 체계가 대부분입니다. 과감히 납작하게 본다면, 기획을 조직에 전파하는 용도로 발표 장표를 만드는 이유는, 그 작업 비용이 더 싸기 때문입니다. 전달력이 떨어지지만 전체적으로 봤을 때 저렴한 경우가 많습니다. 만약 발표 장표 만드는 목적이 비용이라면, AI 코딩 에이전트를 사용하여 데모 버전을 만드는 게 더 저렴합니다. 이용료, 시간은 물론이고, 실제 돌아가는 데모 버전의 전달력도 정적인 글, 그림보다 낫습니다.

AI 에이전트를 펑펑 사용하면서 자신이 일하는 체계, 방식에서 사람 간 협업을 기준으로 하는 부분이 무엇인지 고민해보세요.

대체하거나 효율을 높일 부분 뿐만 아니라 한계도 고민하세요. 그 한계가 AI 모델이나 에이전트에서 기인하는 걸 수도 있고, 사람(자기 자신)에게서 기인하는 걸 수도 있습니다.

---

2번 단계에 오면 다음에 뭘 해야할지 방향이 잡힙니다. 하다못해 강의나 강좌, 책도 무엇을 봐야할지 관점이 생깁니다. 어떤 사람과 어떻게 협업할지, 어떤 도구에 돈을 더 들일지, 내가 몸으로 떼우는 게 나을지. 그 단계에 돈을 쓰세요.

이 과정을 경험하고, 내 관점을 갖는 데 1~2달이면 충분합니다. 요즘처럼 AI 발전이 빠른 시기에 너무 느린 것 아니냐고요. 불과 1년 전만 해도 AI 코딩 에이전트의 수준은 현재와 비교불가 수준이었다는 걸 보면 그런 마음이 들 수 있습니다. 근데, AI가 도구라는 점은 전혀 달라지지 않았습니다. 문제를 정의하고, 실제 문제를 해결하는(execution) 결정과 방식은 사람이 합니다. 끊임없이 새로운 도구는 나왔고 발전해왔지만, hello world에 머무르는 사람은 그때나 지금이나 hello world에 머무르고, 변화를 일으키거나 변화하는 사람도 그때나 지금이나 있어왔습니다.

---

보안 위협 등 조심해야 할 건 많은데, 이또한 앞서 거론한 “한계”로 파악하는 게 우선입니다. 문제를 알고, 정의할 수 있으면 해결 방법도 찾을 가능성이 큽니다. 더군다나 AI가 끝내주는 점 중 하나는 자연어로 소프트웨어 “엔지니어링”을 실행하는 겁니다. 그리고 “소프트웨어”여서 실행 비용이 상대적으로 저렴하고요.

고환율 시기라 100 USD, 200 USD가 부담스럽지만, 고성능 AI 도구를 다양한 방법으로 써보며 내 생각과 관점을 넓히는 비용으로는 저렴합니다.

클로드 코드의 에이전트 팀 기능이 기대 이상이다. git worktree로 작업을 지시했는데, tmux를 인식해서 pane을 나누어 세션을 분리하여 작업하며 에이전트 간 소통을 한다. context window가 분리되니 compaction 빈도가 줄어 작업 품질도 좋고 속도도 빠르다.

클로드 코드의 기능과 성능 개선 효과도 있지만, Opus 4.6 효과도 있어 보인다. 협업 계획을 더 잘 짜며, Skills, Sub agents 등 에이전트에게 제공되는 “도구”를 더 잘 활용하기 때문이다.

단점이라면 그만큼 토큰 소비량도 엄청나다. Sonnet 5가 빨리 나와야 할 것 같긴 하다. Opus로는 감당하기 부담스럽다. 여튼 이번 변화로 내가 이번 주에 구현하고 설계한 AI 에이전트 기능 중 굵직한 기능 몇 개가 며칠만에 레거시가 되긴 했지만... 뭐, 아무렴 어때.

Anthropic이 AI 에이전트(클로드 코드) 발전시키는 속도가 빠르다. 매우 뾰족한 AI 에이전트 제품을 만들지 않는 이상,

• Anthropic의 엄청 빠른 릴리즈 주기
• API 플랜을 압도하는 계정 구독 가성비 이 두 가지 때문에라도 AI 에이전트 사업은 정말 하기 어려워보인다.

한편, 클로드 코드 에이전트 팀 기능이 (자잘한 버그와는 별개로) 이전과 사용 방식에 변화를 줄 것으로 보여 재밌다.

유니티용 SDK를 만드는데 core는 rust로 짜고 ffi로 하라고 했다. 처음엔 클로드 코드가 반대했는데 내가 rust 다룰 줄 아니까 진행하라고 했다. 그러자 클로드 코드는 알겠다고 하고는 일을 시작했는데, core를 구현하는 팀원 에이전트가 리드 에이전트의 계획에서 구체적인 core 구현 방향이 빠지자 내 rust ffi 요구를 제안으로 스스로 강등(?)하더니 c#으로 구현을 해놨다.

컨텍스트 윈도우가 분리되어 지시가 가다보니 생긴 현상같은데, 에이전트 팀이 완전 탑다운은 아닌 모양새가 됐다.

“기획에서 출시까지 FastAPI 개발 백서”의 인프런 챌린지가 어제자로 끝났다.

콘텐츠 만드느라 무척 힘들었다. 과욕을 부려 스스로 불러온 재앙인데, 끝내 해냈다.

평점이 후한데, 액면 그대로 받아들여도 되는지 헷갈리지만, 그래도 뿌듯하다. https://inf.run/fuTQm

출판사 책만에서 저를 공부시켜요. 자꾸 좋은 책을 보내주시는데, 어쩜 그리도 요즘 제게 딱 유용한 주제인지 꼼꼼히 읽느라 평일 밤과 주말에도 공부하고 있어요. 자꾸 이런 좋은 책을 보내주시면 저 집필 언제 해요? 😂 (그리고 또 새 책이 택배로 도착하였는데...)

“모던 API 아키텍처 설계 전략” 책은 컨퍼런스 참석 서비스를 원시형에서 시작해 고도화한 아키텍처에 이르는 여정을 단계별로 주제를 나누어 설명한다. 원제에 “Architecture”라는 단어가 들어가있는데, 각 장의 산출물이 아키텍처 결정 기록(ADR, Architecture Decision Record)인, 말 그대로 아키텍처 수립 과정과 결과를 다룬다.

요즘 내가 개발하고 있는 프로젝트가 플랫폼인데, 그동안 고민하며 설계해온 과정을 범용 주제로 풀어낸 것처럼 풀어가고 있어서, 아니 실은 현 개발 단계까지 포괄하고 있어서 매우 유익하다. 그리고 내용 구성과 전개, 실무 경험에서 우러나오는 내용이 좋은데, 저자의 지식과 경험을 편하게 전수받는 이런 경험은 좋은 책에서 누릴 수 있다. 구글링이나 AI-ing으로는 이렇게 효과와 효율 좋게 학습하기 어렵다.

책에서 다루는 범위가 넓은데, 자신의 경험과 숙련도, 프로젝트 특성과 같은 환경에 맞춰 필요한만큼 학습하면 되어서 입문자부터 숙련자 모두에게 유용한 책이다. 추천 추천.

책만에서 보내주신 책을 이제야 읽었다. 재밌어서 금방 읽었다. 원제는 “How to make things faster”인데, 원제도, 번역서 제목도 공감한다.

저자가 시스템 성능 최적화라는 엔지니어링 소재로 문제를 정의하는 방법에 관한 이야기를 다룬다. 전문가가 문제를 해결할 때 암묵적 지식으로 단계를 훅 건너뛰고 해결 과정으로 도달하는 모습을 보이는데, 이를 저자 자신이 에세이 형식으로 사고 과정과 관점을 풀어서 설명한다.

역자 또는 출판사에서는 이 책으로 독자에게 전하고 싶은 내용이 바로 일 잘하는 엔지니어의 “생각 기법”인 것 같다. 사고 방식과 기술을 AI 에게 외주화하는 관점과 태도를 마치 AI 수용도나 활용도처럼 전파하는 요즘 시기에 꼭 필요한 책이다.

작년에 재미있게 읽은 책인 “완벽에 관하여”가 생각났다. 소프트웨어 엔지니어링으로 사례를 좁히고 파며 내용을 다루어서 어쩔 수 없었겠지만 과감하게 “전문가의 생각 기법”같은 어그로(?)를 끌며 더 많은 사람에게 노출되고 읽히면 좋겠다.

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

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

이런 내 입장에서 작업들에 대해 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을 계획하고 구현하여 보완하거나 극복하지만, 디자인은 매우 잘 안 됨. 시간, 토큰 가성비가 안 나옴. 디자인(설계) 역량 있는 사람이 압도적임. 현재 내 경험에 놓고보면 디자인은 사람 대체 불가.

2025년 마무리.

• 책 : 괴델, 에셔, 바흐 올해 205권 읽었는데, 올해 가장 좋았던 책은 괴델, 에셔, 바흐이다. 그리고 내 집필서가 출간되었다. “기획에서 출시까지 FastAPI 개발백서” 2026년엔 두 번째 집필서를 해제하겠다.

• 건강 : 식겁 작년 3분기쯤부터 슬슬 몸이 안좋아지다 올해 1분기에 절정으로 힘들었고, 2분기엔 수술하여 위기를 극복했다. 3분기까지는 회복하는 시간을 가지려 애썼지만, 먹고 살려고 열심히 달렸다. 위기를 잘 넘기고 겉으로는 티가 안 나기긴 하지만, 그래도 영향이 없진 않다. 4분기엔 힘든 시기가 여러 번 있었다.

• 자산 : 큰 변화 얼마 안 되는 자산에 많은 변화가 일었다. 자산 구성비가 많이 달라졌다. 가장 수익이 좋았던 건 미증시. 환율과 맞물려서 +50% 성과를 보았다. 수익율은 아리스타 네트워크였고, 수익액은 엔비디아...가 아니라 암 보험금. 수익율과 수익액이 가장 컸다.

• 먹고 살기 : 취업 수술 후 심경 변화가 컸고, 그 영향으로 취업했다. 취업 전에 이런 저런 가능성이나 여지를 연 채 소통하던 곳이 몇 곳 있었지만, 지지부진하여 어중간하게 대기하는 시간이 흐르던 중에 가장 명확하고 뚜렷하게 논의를 진행하는 곳에 합류했다. 오랜만에 게임 업계에 복귀했는데, 공간에 흐르는 일상 용어가 달라진 걸로 게임 업계를 체감하고 있다. 뭐, 내가 게임을 만드는 건 아니지만.

• AI 코딩하는 방식이 달라져서 요즘엔 손 코딩을 거의 하지 않는다. 손목 터널증후군과 손가락 관절 통증으로 코딩 자체가 버거워지고 있었는데, 기계가 코딩을 대신 해주니 편하다. 게다가 생각 코딩 -> 손 코딩 -> 생각 코딩 전환 비용마저 줄어서 코딩하는 시간이 크게 늘었다. 그래서 퇴근하면 몹시 피곤해... AI 모델과 AI 코딩 에이전트 발전과 변화가 빨라서 AI 지침서와 Tooling, MCP 등 보조도구 사용 체계와 환경을 거의 매달 손본다. 매달 프로그래밍 언어, 프레임워크, 코드 에디터를 업데이트 하는 느낌이다. 좀 피곤하긴 하다.

이제, 2026년을 열어보자.

클로드 코드는 여전히 띨띨하지만, 워낙 작업 진행을 빨리해서 여전히 Gemini나 Codex보다 많이 사용한다. 아직 프로젝트 초반이라 깊게 탐색하거나 추론할만한 게 별로 없기도 했고.

근데 클로드 코드가 빠른 데엔 함정이 있다. 까다로운 문제를 처리할 때, Gemini와 Codex는 다양한 방법을 시도하고, 이리 저리 고민하느라 시간이 오래 걸리는데, 클로드는 문제 자체를 회피해버리고선 “이제 완벽합니다!”라고 뻥친다.

가령, return True 같은 함수를 작성하고선 동작이 된다거나 테스트를 통과했다고 한다. 또는 테스트 코드를 삭제하거나 Mock 떡칠을 하거나 심지어 요구사항 자체를 부정하고선 구현을 제거하기도 한다. 메모리를 날렸거나 대화를 요약(Compact)해서 그런 게 아니다. 문서에도 써있는 내용인데, 몇 번 해보고 안 되면 저런 짓을 한다. 그런 못된 짓을 혼내면 사용한 도구에 버그가 있다고 뻥을 치기도 한다.

결국 최종 완성하는 시간은 별 차이없다.

그럼에도 여전히 클로드 코드를 쓰는 이유는, 역시 진행 과정 자체는 빨라서, 즉 작업에 대한 피드백을 빠르게 주고 받을 수 있기 때문이다. 5분 걸려 완료한 작업물을 리뷰하는 것보다 1분 단위로 리뷰하고 개선하는 게 좀 더 유의미하게 작업을 진행하기도 하고, 덜 답답하다.

그나저나 Opus 4.5는 어떨려나. 어차피 코드엔 별 기대를 안 하니 거짓말과 기만만 덜해도 만족할 것 같은데.

Ghost 라는 도구를 self-hosted 로 직접 구동하려고 하는데, 설치 사용자 경험이 무척 안좋다. 좀 더 정확하게는 강결합되어 있는 Tinybird라는 도구의 설치 사용자 경험이 매우 안좋다. 딱 2시간만 더 써보고 기대/예상대로 동작 안 하면 포기해야겠다.

제가 집필한 책이 출간되어 소개해봅니다. 현재 예약판매 상태예요. Python과 FastAPI 기술스택을 다루는 내용인데, 주제이자 핵심 내용은 서비스를 개발해 출시하여 운영하는 데 초점을 맞추었어요. 출시해 운영하는 데 학습하고 다루기 좋은 도구가 Python과 FastAPI여서 이 두 도구를 다루는 거지요. Python, FastAPI은 Back-end Application Server 개발에 많이 사용되고 있는데, 특히 데이터 처리와 AI 개발을 하는 분들도 교양처럼 학습하고 다루어서 빠르게 저변을 넓혀가고 있습니다.

교보문고 https://gilbut.co/c/25109056bV 예스24 https://gilbut.co/c/25103487Bh 알라딘 https://gilbut.co/c/25106075TC

FastAPI를 이용해 서비스 개발부터 출시까지 더 쉽고 효율적으로 학습하고 경험한다!

서비스를 기획하고 만드는 것도 쉽지 않지만, 실제로 세상에 출시하고 운영하는 일은 그보다 더 많은 시행착오와 노하우를 요구한다. 로컬 호스트에서 구동하는 과정에서는 드러나지 않던 문제들이 출시하는 과정에서 드러나기도 하고, 그에 따라 장애와 복잡도도 함께 늘어난다. 그래서 이 책은 웹 애플리케이션 서버를 구현하는 데 그치지 않고, 실제 서비스를 출시하는 과정까지 함께 다룬다. 이때 사용하는 도구가 너무 어렵거나 복잡하면 끝까지 완주하기 어려운데, 그 점에서 FastAPI는 배우기 쉽고 빠르게 결과를 확인할 수 있어 실전 프로젝트를 경험하기에 적합하다.

이 책은 약속 잡기 웹 서비스를 하나의 프로젝트로 삼아, 기획부터 구현, 배포까지의 모든 흐름을 따라간다. 1~6장에서는 요구 사항 정의, 설계, 환경 구성 등 개발에 필요한 기반을 다지고, 7~12장에서는 본격적인 기능 구현과 프런트엔드 및 외부 서비스(구글 캘린더)와의 연동을 다룬다. 13~14장에서는 깃허브와 AWS를 활용한 배포와 운영 방법을 살펴본다. 전체 과정에서 테스트 주도 개발(TDD)과 애자일 개발 방식의 일부 요소를 적용해 실제 개발 현장에 가까운 흐름을 따라가며, 각 기능이 끝날 때마다 테스트를 통해 완성도를 높여간다. 이 책 한 권으로, FastAPI를 이용한 웹 서비스 개발과 출시 전 과정을 실습 중심으로 온전히 체험할 수 있다.

@hongminhee洪 民憙 (Hong Minhee) 갸악~ 고맙습니다!

제 집필서 표지가 나왔어요. 설레네요. 두근두근.

“넥서스”는 정보 네트워크를 주제로 과거와 미래에 대응할 현재를 이야기하는 책이다. 인류의 역사 사건을 살펴본 후, 역사 사건을 바탕으로 최근과 미래를 고찰하는 내용을 담은 책이다. 유발 하라리식 스토리텔링을 하는 책이라 그의 책(사피엔스, 호모 데우스)을 읽은 사람은 친숙하게 느낄 것같다.

현 인류(호모 사피엔스)는 개개인의 두뇌 능력도 뛰어나지만, 추상 사고(그의 표현을 따르면 “허구”)를 바탕으로 서로가 연결되어 거대한 군집(cluster)을 이루고, 그 군집이 거대한 지능체(두뇌)인 것처럼 작용하여 개개인이 가진 능력보다 훨씬 거대한 능력을 발휘한다. 마치 사람 한 명이 뇌의 뉴런 하나인 것처럼 말이다. 이 책은 이런 인류의 정보망(network) 특성을 AI 주제와 관련하여 푼다.

가장 최근작인 이번 책은 두 가지 측면에서 다소 지루하다. 이전 책들, 특히 사피엔스는 독자를 끌고 미는 힘이 강하다고 느꼈는데, 이번 책은 이전 책에 비해 힘이 부족하다고 느꼈다. 우선 1부라고 할 수 있는 유발 하라리식 “역사” 이야기는 여전히 재밌긴 하지만 이전 책들과 패턴이 같다보니 예상 가능하다. 2부에 해당하는 AI 부분은 내 입장에선 일반적인 예상과 예측을 다뤄서 2부 역시 책을 읽으며 어떤 이야기가 펼쳐질지 예상된다.

그리고 2부는 1부에 비해 다소 내용이 중복된다. 강조하려고 중복된다기보다는 관점이 확장되지 않고, 또는 저자가 의도적으로 관점을 확장하지 않고 1부에 비해 좁은 영역 안에서 이야기를 풀기 때문에 그런 것같다.

내가 감히 평가할 입장이나 위치에 있진 않지만, 그동안 그의 책을 재밌게 읽어온 독자의 마음으로는 아쉽다. 여전히 재밌고 유익한 책이긴 하지만, 후속 책에 대한 기대감이 줄어들기도 해서 내겐 미묘한 책이다.

https://news.hada.io/topic?id=23573

일렉트론 앱들이 램과 CPU를 과하게 점유하는 경향이 있긴 하지만, 소프트웨어 품질이 대규모로 붕괴된다고 생각하진 않는다.

내 기억으로 30년 동안 대부분 소프트웨어는 불안정했다. 걸핏하면 리부팅했다. 리눅스도 데스크탑 작업PC로 쓸 땐 만만찮았다.

원 글에서 과장되게 말하는(AI가 작성한듯한) 내용과는 달리 소프트웨어 개발 방법론은 갈수록 발전해왔고, 언어도, 컴파일러도, 운영체제도, 개발도구도 발전해왔다.

과거와 다른 점이라면 사용하는 앱이 다양해졌고, 수익화 방안이나 오픈소스/무료 사용 앱이 다양해지며 쓸 수 있는 앱도 늘었다는 것.

그리고, 현대 소프트웨어는 과거보다 복잡한 요구사항을 소화하고 있다. 요즘 수준으로 UX를 제공하는 앱은 일단 과거에 흔치 않거나 있더라도 요즘과 비교해서 딱히 더 안정감 있지 않았다. 오히려 과거보다 PC나 서버는 더 안정감 있게 쓰고 있다고 생각한다.

AI 코딩과 주니어 진입이 어려워진 점에 대한 내용은 흐름상 뜬금없긴 한데, 무분별하게 AI 코드를 신뢰하고 활용하는 건 경계할만 하다고 본다. 다만, 이것도 과도기라고 보는데,

• AI가 더 발전하거나
• AI 활용 개발 방법론 등이 자리를 잡거나
• 생태계 구조가 변하여

현 혼란도 정리될 것이다.

“싯다르타”는 싯다르타라는 인물이 깨달음을 얻는 여정을 담은 헤르만 헤세의 소설이다. 석가모니인 고타마 싯다르타를 다루는 이야기인 줄 알았는데, 깨달음을 얻은 부처인 세존인 고타마라는 인물과 고타마와는 다른 길을 걷는 싯다르타라는 인물로 분리하여 이야기를 풀어가는 가상의 이야기를 다룬다. 즉, 석가모니의 생각이 아니라 헤르만 헤세의 생각을 전하는 소설이다.

문장이 쉽고 분량이 적어 부담없이 읽히지만, 쉽게 읽는 책은 아니다. 어렵다기보다는 깊게 생각하며 읽는 책이다. 책에서 말하는대로 ‘지식은 전할 수 있지만 지혜는 전할 수 없다. 지혜는 자기 자신이 깨닫는, 온전히 자신의 경험’이며, 나 스스로 지혜를 깨달으라고 이 책은 말한다. 어떻게 이런 글을, 이런 이야기를 쓸 수 있는지 대단하다는 생각을 하며 감탄했다.

이 책에서 줄곧 단일성을 이야기한다. 단일성이 무엇인지 정의해주지 않는데, 단일성을 생각하면 ‘시간은 존재하지 않는다’는 싯다르타의 말이 떠오른다. 시간, 우리말로 풀면 때와 때의 사이이다. 우리 두뇌는 끊임없이 평가하고(과거) 예측하며(미래) 때(현재, 순간)를 가공의 것으로 인식한다. 우리는 만물을, 현재를 있는 그대로 받아들이지 못하며, 그렇기에 만물을 있는 그대로 사랑하지 못한다. (뇌과학자인 질 볼트 테일러의 책과 TED 강연이 생각났다)

감명 깊게 읽었다.

“아우스터리츠”는 독일의 대문호 W.G.제발트(세발트)가 쓴 소설로, 나치로부터 유대인 어린이를 구출하고자 영국으로 입양보내진 아우스터리츠라는 인물이 자신을 찾아가는 이야기를 다룬다. 난 TTS로 이 책을 들었는데, 다 듣고나서 영 어려워서 다시 훑어보니 차분히 읽어도 어려운 소설이다.

무척 독특한 형식을 띠고 있는데, 마치 다큐멘터리를 보는 경험을 하게 된다. 책 중간 중간 사진이 실려있고, 실재 사건과 소설의 허구가 섞여 있어 헷갈리게 한다. 그리고 굉장히 긴, 구어가 아니라 문어에서도 드물 정도로 문장을 겹겹이 이으며 묘사하여 더 다큐멘터리를 보는 느낌이 든다.

한편 유럽 문학을 읽으며 내 생각보다 훨씬 강하고 넓게 종교와 홀로코스터가 영향을 미친다는 걸 깨달았다. 문제는 머리로는 이해하는데 마음으로는 그들만큼 온전히 닿지 못한다는 것이다.

그런데도 읽으며(들으며) 작가와 작품 모두 대단하다고 막연히 생각했는데, 내가 이 소설을 제대로 소화하지 못했다고 여기면서도 그런 생각을 했다. 계절 간격을 두고 다시 읽어야겠다.

“카라마조프가의 형제들”은 사건 구성과 전개, 상황과 심리 묘사가 대단히 뛰어난 도스토옙스키의 소설이다. 정말 대단한 작품이다.

후반부에 나오는 재판 장면을 놓고, 1권과 2권에 걸쳐 등장인물을 한 명 한 명 소개하는 구성인데, 등장인물이 얽혀 여러 상황과 사건이 벌어진다. 그 과정에서 각 인물이 보이는 행동과 생각, 감정이 마치 역사 속 인물을 묘사한 것처럼 실재감이 뛰어나다.

1권에선 등장인물을 소개한다면, 2권은 등장인물의 성격과 신념을 자세히 다루는데, 3권에서 인물들의 심리를 본격 묘사하는 준비 단계같다. 그 시대 사람들의 공통 철학과 도덕은 종교이다보니 종교적 묘사가 많은데, 내겐 믿는 종교가 없다보니 2권에선 1권과 3권에 비해 몰입도가 떨어졌다.

3권에서 다루는 핵심 사건인 재판 과정에서 변호사가 보이는 견해는 현대 시점에선 자연스럽게 보였는데, 소설 속 시대인 19세기 후반엔 무척 도전적이고 진보적이었을 것 같다. 인간 관계, 특히 부모자식 관계에 맹목 상태에서 복종하는 것을 논고하기 때문이다.

주인공은 카라마조프 형제들의 막내인 알료샤인 것으로 보이지만, 알료샤는 관찰, 서술하는 역할을 하고, 가장 큰 사건의 중심인 첫째 미챠가 주인공이다. 이 인물이 소설 내내 어떻게 행동하고 생각할지를 소설 극초반부에 설정하고 설득시키는 점이 놀랍다.

아무리 생각해도 Opus 4.1 운영 비용이 너무 비싸니까 열화시키고 상대적으로 저렴한 Sonnet 4.5를 빨리 출시해서 이쪽으로 사용자몰이하는 것같다. 마치 ChatGPT 4.5가 너무 비싸자 5 출시 후 4.5는 레거시 모델에서도 감춰버린 것처럼...

클로드 소넷 4.5가 나왔다길래 기대했는데, 플랜을 올리지 않아도 되겠다.

시작일과 종료일로 배열을 만들어야 했다. 클로드가 while문으로 배열을 만들었다. 음. 쎄하다.

잠시 후, 클로드가 다른 코드를 고치던 중에 while문의 조건식에 영향을 미치는 구문을 변경했다.

무한 while문이 발생해서 페이지에 들어갈 때마다 웹 브라우저가 뻗어서 디버깅하느라 한참 걸렸다.

클로드가 기존 코드를 고치던 중에 선언한 변수 하나를 안 지웠다(unused 상태). 어찌 저찌 코드를 고치다가 무한 리렌더링이 발생했다. 무한 리렌더링을 지적하니 “아!”하고는 지우지 않은 변수를 다시 활용해야 한다며 아까 지가 지운 코드를 되살렸다.

클로드에게 Terraform으로 인프라 선언을 하라고 했다. 비교적 잘 마무리했다.

이번엔 이를 참고해서 GCP cloudbuild와 GitHub actions 를 작성하라고 했다. 잘 하는가 싶었다. 하지만 역시나. 인프라 등 각종 요소의 이름을 새 관례로 이름짓더니 GCP CLI를 이용해 직접 GCP에 생성했다. 이름만 다른 동일한 서버 요소들이 추가됐다.

Claude가 datetimeFormatters.ts 파일을 작성했다.

얼마 후,

formatDatetime.ts 파일을 새로 만들어 같은 동작을 하는 함수를 작성했다.

---

아, 8월 초 Claude Opus 4.1이 그립다.

9월엔 35권 읽었다. 요며칠 무지 바빠서 "카라마조프가의 형제들" 마지막 권을 다 못읽어서 아쉽다. 막판 하이라이트가 본격 시작되어 흥미진진한데...

9월에 읽은 책 중엔

마음의 사회 마인드스톰 90일 안에 장악하라

이 책들이 기억에 남는다.

“C# 교과서” 책은 입문부터 C#의 많은 요소를 두루 다루는데, 학습 요소를 나열해 설명하는 데 그치지 않고 이해와 활용에 목표를 둔 커리큘럼에 맞춰 내용을 전개한다.

C# 자체에 입문하는 사람보다는 C#으로 프로그래밍에 입문하는 사람까지 염두에 둔 인상을 준다. 저자가 커리큘럼(목차)을 독특하게(?) 짰다는 생각을 했다.

읽고 공부하며 든 생각은, C#은 기능이 정말 풍부한 언어라는 점이다. Python이나 Go처럼 간결한 언어를 좀 더 선호하는 취향이지만, 흥미를 돋우는 언어라고 느꼈다.

MS 권고에 따라 객체가 아니라 개체라 표기하거나 문과 식에 대한 정의가 좀 색다르다거나 하는 생소한 면면이 있지만, 전체적으로 친절하고 쉽게 쓰여진 입문서이다.

프란츠 카프카의 "소송"은 주인공이 소송을 당해 체포되고, 이를 해결하는 과정을 다루는 소설이다.

영문도 모른 채 주인공이 체포되는 장면으로 시작하는데, 흥미진진하고 호기심을 일으켜 순식간에 몰입하게 된다. 그리고 부조리하고 개인을 억압하는 거대한 체제에서 주인공이 느끼는 무력감과 절망하는 마음을 내내 동감하며 읽었다.

작가의 명성에 비해 뭔가 빈 듯한데, 알고보니 미완성작이다. 시작과 끝 장을 써두고, 중간 장을 채워갔다고 한다. 그걸 알게 되자 이야기 내내 주인공이 겪는 일을 다른 마음으로 보게 된다.

추석을 앞두고 책장을 정리했다. 나눔할 책 추려내고, 공간이 부족해 드러누워있던 책들을 새 칸으로 옮겼다.

공간이 생겼으니 이제 좀 더 마음 편히 책 사야지.

“이펙티브 소프트웨어 아키텍처” 책은 소프트웨어 아키텍처 개론서이다. 아키텍처 자체에 대한 내용을 다루진 않고, 아키텍처을 효과적으로 하는 데 필요한 기반 또는 관련 요소를 다룬다.

내겐 모호한 책이다. 소프트웨어 개발 관련 직무를 수행한 지 얼마 안 되거나 아키텍처가 필요한 상황을 겪어본 적이 없는 사람에게 더 유익할 것같다. 특히 소프트웨어 엔지니어링 직군이 아닌 사람이 아키텍처를 고민한다면 책이 친절하다고 느낄 것이다.

“소프트웨어 아키텍처 101” 책은 소프트웨어 아키텍처를 주제로 소프트웨어 엔지니어링 접근 방식을 여러 체계로 분류하고, 각각을 설명한다. 아키텍처를 다루는 데 그치지 않고 아키텍트의 역할과 소프트스킬도 간략하게 다뤄서, 아키텍처라는 활동을 기초부터 차근 차근 두루 살펴본다.

저자는 절충점(트레이드오프)을 근간으로 삼아 내용을 기술한다. 책 초반부에 “아키텍처는 모든 게 다 트레이드오프”라고 선언한다. 그래서 여러 아키텍처를 소개하고 설명할 때에도 무엇이 트레이드오프 요소일지 설명하는 점이 유익하다.

이런 주제를 다루는 책은 주니어에게 자칫 헛바람 또는 손에 망치를 들게 하는데, 자신의 커리어 단계에서 아키텍처를 어떻게 학습하고 소화할지 제안하는 점이 인상적이다.

원제에 fundamentals이라는 표현이 있는데, 기초나 입문이라는 표현이 좀 더 어울리는 책이다.

아, 내가 좋아하는 쿠르츠게작트에서 게임을 냈는데, 윈도우용만 있네. ㅜㅜ

https://store.steampowered.com/app/2719750/Star_Birds/

문턱은 낮게, 천장은 높게, 벽은 넓게. - 미첼 레스닉

• 문턱은 낮게 : 누구나 쉽게 시작할 수 있도록 진입 장벽을 낮추자.

• 천장은 높게 : 단순히 시작하기만 쉬운 것이 아니라, 고급 수준까지 도전할 수 있어야 한다. 어느 순간 “더 이상 이 도구로는 할 게 없네”라는 한계를 느끼지 않도록 깊이 있는 탐구와 확장 가능성을 제공.

• 벽은 넓게 : 다양한 방식으로 활용할 수 있는 여러 경로가 열려 있어야 한다. 정해진 답이나 한정된 학습 경로가 아니라, 각자의 관심과 개성에 맞추어 여러 가지 방향으로 탐색할 수 있어야 한다.

p.s : “문턱은 낮게, 천장은 높게”는 시모어(세이무어) 패퍼트가 한 말이며, 미첼 레스닉은 여기에 “벽은 넓게”를 추가한 것.

“러닝 랭체인” 책은 랭체인, 랭그래프 등을 개발한 이들이 집필한 책으로, 랭체인을 활용해 AI 제품을 확장하거나 고도화하고, AI 에이전트를 개발하는 실무 내용을 다룬다. 실무에 초점을 맞춘 책이라 주요 개념을 간략히 설명하거나 언급만 하며, 랭체인을 사용해 실제 구현하는 방법을 제시한다. 어느 정도로 구현하는 방법을 다루냐면, Python과 JavaScript 두 언어로 예시 코드를 담고 있다. 랭체인 등이 워낙 추상화를 해놓은 도구여서 굳이 두 언어로 예시 코드를 다룰 필요가 있을까 생각이 들면서도, 소프트웨어 엔지니어링이 주업이 아닌 직군인 사람에겐 편할 것같기도 하다. 세세하고 풍부하게 내용을 다루는 온라인 공식 문서와 책 사이에 모호한 경계에 위치한 책이라는 생각이 든다. 디지털 문서 읽는 걸 선호하지 않는 내겐 유용했다.

“개발 함정을 탈출하라” 책은 프로덕트 매니지먼트가 어떻게 작용해야 하며, 더 나아가 프로덕트 중심 조직이 되어야 하는 이유, 그리고 프로덕트 중심 조직이 되기 위해 해야할 것이 무엇인지 다룬다. 이를 역할, 전략, 절차, 조직 순서로 프로덕트 매니지먼트를 살펴본다. 제품은 고객에게 가치를 전달하고, 성과를 내야 한다. 많은 경우, 그렇지 않은 채 일을 위한 일을 하는 함정에 빠지는데, 이 책 제목에서 말하는 개발 함정(build trap)은 이를 뜻한다. 보는 것보다 경험하는 것이, 경험하는 것보다 만드는 것이 높은 학습 효과를 거두는 방법이다. 하지만, 뒤로 갈수록 시간과 현금이라는 한정된 자원이 많이 든다. 개발 함정은 매우 비싼 활동이다. 이 책은 Why와 What 위주로 프로덕트 매니지먼트를 설명하며, How는 언급만 한다. How에 대해 설명하는 책이나 자료가 많기 때문일수도 있고, 조직이나 제품마다 How가 달라지기 때문일지도 모른다. 린스타트업, 애자일을 바탕으로 제품 개발과 경영(전략)을 설명하는데, 0 to 1 조직보다는 1 to 10 조직과 환경에 빗대어 읽기에 좋다. 프로덕트 매니지먼트에 입문하기에 유익한 책이다.

미첼 레스닉의 “평생 유치원”은 창의적 사고와 학습을 하는 방법을 다룬다. 창의적 학습의 틀로 4P, 즉, 프로젝트(Project), 열정(Passion), 동료(Pears), 놀이(Play)를 제시하고, 이들에 대해 연구와 실 사례를 들어 설명한다.

MIT미디어랩에서 만든 두 가지 프로그램을 주요하게 다루는데, 컴퓨터 클럽하우스와 스크레치이다. 이 두 프로그램이 거둔 성과와 이룩한 생태계를 사례로 들어 설명하고, 참여자를 인터뷰하는 내용을 담고 있다.

저자는 AI시대에 돌입한 현대 사회에서 우리가 행복한 삶, 성공하는 삶을 사는 준비하는 방법 중 하나로 창의적 사고를 말한다. 창의적인 활동은 인생에 기쁨과 의미, 목적을 부여하기 때문이다.

개발자 입장에서 이 책에서 말하는 창의적 학습과 활동에 대해, 그리고 AI시대를 맞이하고 바라보는 마음으로 여러 생각을 하며 읽었다.

이미지로만 보던 그 유명한 파도 그림을 보고 왔습니다. 실제로 보니 질감과 세밀함이 정말 감동스럽더라고요. 작품 교체를 하는데, 후지산이나 파도 그림은 전반기에 전시하는 것 같아요. 전반기는 11월 2일까지.

"국립 "청주" 박물관에서 전시합니나. "충주" 아니에요. 이상 충주에 가서 밥 먹고 청주에 가서 관람한 1인이었슴미다.

https://cheongju.museum.go.kr/www/speclExbiView.do?key

소설은 과거, 현재, 미래 시점으로 구성되고, 각 시점마다 주인공 역할을 하는 인물이 달라지며, 각 시점마다 여성성에 대한 주제가 다르다. 오디오북(정확히는 TTS)으로 들으니 내용을 이해하기 혼란스러웠다.

1970년대, 여성 그리고 여성의 성을 바라보는 시대상을 엿볼 수 있었다.

더 기다릴 것도 없다. Claude Code plan 낮춰야지. A 방법으로 배포하지 말라고 해서 고쳐놓고 몇 가지 작업을 하면 어느 순간 A 방법으로 배포 스크립트 고쳐놓고, “제발” A 방법을 쓰지 말라고 하고 되돌려 놓은 뒤 작업을 진행하다보면 어느 순간 또 A 방법으로 되돌려놓고. 중간 중간 Docker 컨테이너 재실행한 스크립트 이후에 해당 인스턴스 서버를 초기화해서 인스턴스를 백치미 넘치게 만드는 스크립트를 추가하는 건 덤. 와, 너무 심하게 멍청해졌네.

안녕하세요, 여러분.

해커스펍에 들어온 시점 전후로 건강에 문제가 생겨 이제야 hello world 메시지를 남기네요. 초대해주신 @hongminhee洪 民憙 (Hong Minhee) 님 고맙습니다.

애호하고 선호하는 프로그래밍 언어는 Python이고 Back-end 직군이 본진이지만, 그때 그때 엔지니어링에 필요한 직군에서 필요한 도구를 써서 개발해요. 현재는(2025년 5월 기준) 프리랜서로 일하고 있습니다.

개발 외엔 글쓰기, 글짓기를 좋아해서 글로 먹고 살 방법도 모색하고 있어요.

잘 부탁드리며, 또 뵈어요.