한날

“기획에서 출시까지 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월 기준) 프리랜서로 일하고 있습니다.

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

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