개발자 어썸블로그

2026년 5월 출간 IT 원서들 기대평

2026-05-25T13:13:00+09:00

2026년 5월 IT 원서 기대평입니다. 트위터(현 X.com)의 [타래](https://x.com/ryugwang/status/20566766...

마키나락스 코스닥 상장

2026-05-20T15:13:20+09:00

마키나락스가 오늘 코스닥에 상장했다. 스타트업의 염원이기도 하고 이윤을 추구하는 기업의 행위에 대한 자본 시장의 평가라 할 수도 있다. 비 상장 주식회사, 이미 상장한 회사, 비 상장 회사에 인수된 상장사, 상장을 시도했으나 실패한 회사 등 꽤 다양한 회사를 다녔었는데 역시 회사가 상장한다는 것은 정말 특별한 경험이다. 증권 거래소도 가보고 말이다.

팀원으로 입사해서 지금은 제품 개발을 리드하고 있는데 덕분에 상장 과정을 꽤나 가까이에서 봤다. 그래서 회사가 얼마나 노력했고 이 상장이 값진지 많이 느껴진다. 지금까지 이뤄낸 것과 앞으로 이뤄낼 것을 다 정리해서 설명하고 답변해야 하고 회사의 모든 부분을 증명해야 했다. 빈말이 아니라 그동안 많은 것을 이룩한 뛰어난 구성원들이 모두 위대해 보였다.

상장하면 회사가 많이 변화한다고 한다. 기업 공개가 됐으니 더 투명해질테고 인적 구성에도 많은 변화가 올 것이다. 구성원들이 능력을 십분 발휘할 수 있는 환경을 만들어야 한다는 부담감이 생기는 것을 보니 내 업무도 많이 변한것 같다. 진정으로 좋은 사람들과 함께 세상을 바꾸는 회사가 되었으면 한다.

액티브홀더스 - 주식 투자자의 보물창고

2026-05-20T11:59:00+09:00

2017년 부터 주식 투자를 하기 시작했습니다.
피터 린치, 워렌 버핏, 코스톨라니. 대가들의 책을 읽었습니다.

주식을 산다는 건 회사를 사는 것이다.
돈을 잘 버는 회사를 사면 주가는 결국 따라올 것이다.
대가들의 공통적인 가르침이었습니다.

하지만…
몇 년 뒤 배운 뒷통수가 얼얼한 가르침.

“회사가 번 돈을 너에게 나눠준대? 누구 맘대로?”

대가들의 책에는 생략된 말이 있었습니다.
미국 회사들은 번 돈을 주주들에게 돌려주는 것이 당연하기 때문에, 굳이 저런 말 까지는 적혀있지 않았던 것입니다.
아둔한 저는 이걸 깨닫는데 5년이 넘게 걸렸네요.

‘난 이런 것도 모르고 그동안 한국 시장에 투자한 것인가?’

주주총회도 참석해보고, 표대결도 구경해보면서
시장을 위한 법과 제도, 회사의 거버넌스가 얼마나 중요한 것인지 깨닫게 되었습니다.

단지 사업과 이익만 보고 투자해선 안 된다는 것을.
그것을 넘어 거버넌스까지 이해해야만 한다는 것을.

액티브홀더스는 다음 정보들을 제공합니다.

감사 임기 만료를 정렬해서 보기
최대주주나 대표이사 고령순으로 보기
주주제안 목록 보기
2026년 주총에서 부결된 안건들 보기
별도자산총계 1.9조~2.1조 사이 기업 살펴보기 (집중투표제)
의결권 권유가 있었던 기업 리스트 훓어보기
감액 배당하는 회사 찾아보기
부동산 자산 살펴보기
저평가된 지주회사 살펴보기
자회사들 그래프로 보기
주주총회 후기 읽어보기

도대체 이런 기능이 왜 필요해? 라고 할 사람들도 있겠지만…
진지한 투자자들의 눈에는 얼마나 보물 같은 정보들을 담고 있는지 보일 것 같습니다.

삼성전자의 지분을 보유하고 있는 회사들

저 스스로와 몇몇 지인을 위한 서비스로 시작했지만, 더 많은 사람들에게 도움이 되길 바라며 공개합니다.
액티브홀더스가 자본 시장의 선진화에 조금이라도 기여하고 (추후에는) 약간의 돈도 벌 수 있다면 더할 나위 없이 행복할 것 같네요. 😀

서비스는 여기에서 구경해볼 수 있습니다.

✔️

함께 읽으면 좋은 글:

Agentic AI 를 사용해보면서..

2026-05-22T21:24:09+09:00

근래에 회사 프로젝트를 하면서 Agentic AI를 사용하여 일을 하게 되었다. 물론 SNS를 통해 요즘은 바이브 코딩이라는 걸 한다는 것 즈음은 알고 있었지만, 내가 직접 코딩을 할 일은 없어서 그런가 보다 하고 있었는데 이번에 운이 좋게도 요즘 유행하는 Agentic AI를 사용하여 일을 하게 된 것이다.

Google Nano Banana가 그려준 Agentic AI 이미지

회사에서는 Google Gemini Pro를 사용할 수 있어 간단한 일을 하거나 정보들을 검색할때 채팅이나 NotebookLM, CoLab 등을 사용해 보기는 했지만, 구독료를 내야 하는 OpenAI의 ChatGPT나 Antropic의 Claude를 써 본적은 없었다.

Obsidian이나 VSCode를 설치하고, 거기에 opencode를 설치해 ChatGPT, Claude 또는 Gemini 등의 LLM을 연동하고, 하고 싶은 일을 대화창에 입력하니 스스로 디렉터리를 만들고, 애플리케이션을 설치해주고, 문서를 만들어 준다. 물론 이런 과정없이 웹사이트의 채팅 앱에서 그냥 말로 요청을 해도 기가막힌 슬라이드 자료를 뚝딱해서 만들어 주는데, 정말 깜짝 놀랐다.

몇일동안 사용을 해 보면서 정보를 알아서 찾아서 문서를 만들어주는데 왠지 LLM이 말하는 건 다 그럴듯 해 보였다. 물론 가끔은 내가 시킨게 아니라 그냥 일반적인 정보들을 찾아서 알려주는 것 같다는 생각이 들때도 있었지만, 그냥 그 말이 다 맞는것 같았다. 그리고, LLM이 다 해주니 생각이라는걸 잘 못하게 되고, 생각하는거 자체가 그냥 귀찮아서 주는대로 다 맞겠지 라고 믿었던것 같다.

매일 같은 프로젝트를 하는 회사 사람들과 모여서 문서를 서로 피드백해주는 과정을 거치며, 내가 AI를 잘못 사용하고 있었구나! 너무 AI를 믿었구나! 라는 걸 깨달았다. 분명 나에게는 경험이라는 매우 훌륭한 걸 가지고 있는데도 그걸 제대로 사용하지 않았던 것이다.

AI를 사용할 때는 직접 해보고 확인하고, 정책과 기술이 반영된 공식 문서를 확인하고 하는 과정들을 거치면서 LLM이 주는 정보가 정확한 것인지를 검증하는 절차를 반드시 거쳐야만 한다. 어떤 Yutobe 동영상을 보니 "AI를 사용하는 것은 쉬우나 이를 잘 사용하는 것은 매우 어렵다" 는 말을 들었다. 그 말이 맞는것 같다.

아무튼 나는 오늘도 AI를 잘 사용할 줄 아는 엔지니어가 되기 위해 고군분투 중이다. 세상에 꽁짜로 얻어지는 것은 없다. 이것 역시 많이 시간을 투자해야 하고 많이 사용해 봐야 한다.

1인 빌더의 지난 1년 회고

2026-05-24T20:50:48+09:00

Posteady.com 개발 1주년 기념으로, 지난 1년간 퇴근 후에 개발하고 운영하면서 경험한 것들, 실수한 것들, 잘한 것들을 회고한 글. (음슴체로 빠르게 씀)

0. 배경 설명

9년째 개발자로 재직 중
6세/4세 아이 둘 외벌이 아빠
4년 전에 미국으로 이민 옴
퇴근 후 매일 최대 3시간 1인 개발
월 생활비 1만불 넘어서 현재 퇴사 불가능ㅠㅋ

1. 내가 만든 제품

2024년 5월부터 Posteady.com 하나만 개발 중.
SNS 마케팅 (반)자동화 도구.
내가 마케팅 편하게 하려고 만들기 시작.
이렇게 오래 개발할 생각은 없었음.
그냥 해야 될 게 쥬오오온나 많은 제품 분야인데,
경쟁 제품도 쥬오오온나 많은 새빨간 레드오션.

2. 내가 했던 실수 5가지

1️⃣ 타깃 고객을 잘못 설정함

AI 덕분에 제품 개발은 쉬워졌으니까, 앞으로 1인 빌더들이 SNS 마케팅 피 터지게 하겠지? 나 같은 1인 빌더들이 SNS 마케팅을 꾸준히 하도록 돕는 도구를 만들자!로 시작했으나, 정작 1인 빌더들은 개발하느라 바빠서 SNS 마케팅에 진심으로 뛰어들 여력이 없음.

노출 극대화 → 퍼널 유입 → 구매 전환 흐름에서 '노출 극대화' 파트는 (전문 마케터가 아닌 경우) SNS 마케팅이 가장 접근성 좋지만, 1인 빌더들은 개인 브랜딩 계정만 운영하는 경우가 대부분임.

때문에 여러 마케팅용 계정으로 여러 플랫폼에서 노출 극대화를 노리지 않거나 이런 방식을 잘 모름. 게다가 아직 퍼널이 없거나 구매로 전환시킬 제품/서비스가 없는 경우도 많음.

이제는 포스테디(Posteady)의 타깃 고객과 실제 결제 고객들은 마케터와 마케팅 대행사, 그리고 자영업자 분들임. 즉, 노출 극대화가 매출과 직결되는 분들.

2️⃣ 비타민을 만듦

누가 만든 비유인지 모르겠으나, 있으면 좋은 비타민이 아니라, 실제 고통을 줄이는 진통제를 만들라는 격언이 100% 맞음.

마케터가 아닌 개발자인 나는, SNS 마케팅 SaaS를 만들면서도 마케팅 대행사 실무자들이 겪는 실제 고통이 무엇인지 몰랐음.

그래서 그들의 주된 고통인 '콘텐츠 제작'을 돕는 기능들이 아닌, AI 시대 이전에도 존재하던 기본적인 멀티 플랫폼 예약, 데이터 분석, 제품 성능과 디자인에 집중했음.

이런 기능들은 있으면 좋지만, 없어도 문제없는 비타민 그 자체였음. SNS 플랫폼 앱이나 웹에서도 게시물 예약이 되는데 굳이 포스테디에서? 스레드, X, 링크드인을 동시에 사용하지도 않는데 굳이 포스테디에서?

하지만 최근에 출시한 AI 기능들은 '내 계정 톤으로 콘텐츠를 쉽고 빠르게 제작'이라는 허들을 버튼 딸깍딸깍으로 넘을 수 있게 했고, 출시하자마자 결제가 발생함.

실제 타깃 고객들에게 필요한 진통제는 '쉽고 빠른 콘텐츠 생성 및 발행'이었고, 나머지는 다 비타민이었음. 그리고 현재 Posteady에 빠르게 도입할 진통제는

→ 인스타그램/틱톡 연동

사실상 타깃 고객들이 가장 많이 활용하는 마케팅 플랫폼은 인스타그램/틱톡이기 때문. 그동안 텍스트 기반 플랫폼들(X, Threads, LinkedIn)을 완벽하게 커버하고 영상 플랫폼으로 넘어가야지라고 생각해왔지만, 아주 비타민스러운 발상이었음.

3️⃣ 유료화를 늦게 함

지난 1년간 무료로 운영하다가, 2주 전에 AI 기능들을 출시하면서 유료(+7일 무료 체험)로 바꿈. 처음부터 7일 무료 체험 + 유료 플랜 구독제로 운영했어야 함.

내가 제품 만드는 걸 좋아하고 재밌어했으니까 돈이 되지 않아도 많은 사람들이 사용해 주면 뭔가 뿌듯하고 기뻤음. 그래서 사용자부터 모으는 전략을 선택함.

하지만 네트워크 효과가 필요한 제품(기존 사용자가 많을수록 새로운 사용자들의 진입 가치가 높아지는 커뮤니티나 플랫폼 제품)이 아닌 이상 무료 사용자부터 모을 필요가 전혀 없었음. 오히려 ICP가 아닌 사용자들의 피드백은 제품 방향을 산으로 끌고 감.

Posteady를 1년간 무료로 운영해 보니까, 특히 1인 빌더는 제품을 유료로 운영해야만 돈 내는 고객들에게 필요한 것들을 우선 개발하게 됨. 무료로 운영하면 1인 빌더인 내가 왕이 되고, 내 입맛대로 만들게 됨.

그럼 점점 더 잠재 유료 고객(=왕)으로부터 멀어지고, 어느 순간 제품이 방향을 잃어버림. 성능과 디자인은 전부 훌륭하지만 아무도 안 쓰는 제품이 됨.

4️⃣ 개인 브랜딩 계정과 마케팅 계정 분리 안 함

요즘의 SNS 마케팅은 팔로워 숫자 기반이 아니라, 노출과 반응 기반임. 즉, 내 콘텐츠가 타깃 하는 분야와 내 콘텐츠에 노출되어서 반응(=좋아요/댓글/리포스트/공유)하는 사람들의 관심 분야가 일치하는 게 중요함.

내가 마케터와 자영업자를 위한 제품을 팔고 있는데, 내 콘텐츠를 보는 사람들이 전부 개발자라면, 내 SNS 계정에 정보와 광고를 어떤 비율로 섞어도 광고 효율이 나올 수가 없음.

마케터를 위한 제품을 판다면,

마케터를 타깃 하는 별도의 SNS 계정을 셋업(워밍업 포함)하고,
마케터에게 도움 되는 정보/인사이트 콘텐츠의 비율을 최소 70%로 맞춰서 콘텐츠당 조회수 1천 정도를 확보한 후에
제품 홍보를 조금씩 시작하거나, 아예 정보/인사이트 콘텐츠 비율을 100%로 두고 프로필 링크에서 퍼널에 유입시키는 방식을 써야 했음.

5️⃣ SEO를 늦게 시작한 것

기능 구현이 끝나면 SEO를 본격적으로 하려 했는데, 포스테디 같은 제품은 기능 구현에 '끝'이 존재할 수 없음. 그래서 SEO도 초반부터 병행했어야 했음.

SNS 마케팅이 대형 그물을 던지는 낚시라면, SEO는 작은 통발을 계속 설치하는 낚시임. SEO는 6개월 이상 지속해야 효과가 보이기 때문에, 막상 노출/유입이 당장 필요한 시점에 시작하면 늦음.

Posteady에 AI 기능들을 출시해서 검색 유입이 들어와 주면 좋은 상황이었지만, SEO 작업을 미룬 탓에 현재는 검색 유입이 거의 없는 상태.

3. 내가 잘한 점 2가지

1️⃣ 초반에 퀄리티를 빡세게 잡아둔 것

Posteady 개발을 시작한 2024년 5월에는 아직 AI를 활용한 개발이 온전치 못했음. 그래서 AI의 코드 리뷰를 빡세게 진행했고, 직업병 덕분에 초반부터 관심사 분리, 확장성, 고가용성을 고려해 시스템 아키텍처를 설계하고 꾸준히 개선함.

이렇게 초반에 시스템 구조를 제대로 잡아둔 덕분에, 이후 클로드 코드로 100% 개발하기 시작한 후에도, 기존 구조 위에 여러 복잡한 기능들을 수월하게 추가할 수 있었음.

2️⃣ 포기하지 않고 꾸준히 만든 것

지난 1년간 회사 업무와 육아를 병행하며, 주말에는 최대한 가족들과 시간을 보내면서도 시간을 아끼고 아껴 하루 3시간씩 매일 만듦.

비록 초반 제품 개발 방향은 조금 어긋났지만, 머리로 아는 것과 직접 경험하는 것은 다르기에 지난 1년간 수익은 없었어도 앞으로 1인 빌더, 1인 개발자로서 롱런할 경험치를 잘 쌓았다고 생각함.

잠깐 만들다 포기했으면 몰랐을 것들과 이 글에 모두 담지 못한 노하우를 많이 쌓은 지난 1년이었음.

두서 없는 긴 글 읽어주셔서 감사합니다. 🙇‍♂️

1인 개발자/빌더 분들 모두 파이팅! 💪

클로드 코드 1년 후기

2026-05-19T20:47:06+09:00

2025년 6월부터 2026년 5월까지 지난 1년간 클로드코드를 사용하고 잠시 뒤를 돌아보았다.

1. 도파민 대잔치

되돌아보니, 지난 1년은 도파민 대잔치였다.

클로드코드를 사용하기 전부터 Cursor로 사이드 프로젝트(Posteady.com)를 만들고 있었는데, 아직 LLM들의 코딩 성능이 좀 부족하던 시절이라 도파민 대잔치 수준은 아니었다.

하지만 2025년 6월부터 클로드코드를 쓰기 시작하면서 개발 속도에 불이 붙자, 도파민 대잔치가 시작되었다. 저녁 8~9시쯤 애들을 재우면서 같이 잠들고, 새벽 2시쯤 일어나서 출근 시간 까지 계속 개발하는 생활이 반복되었다.

도파민에 절어서, 자는 시간도 아까웠는지 피곤해도 눈이 떠지더라. (사실상 수면 장애)

2. 굿바이 스택오버플로우

2018년부터 2024년까지는 StackOverFlow.com에 매일 최소 1번은 방문했던 것 같다. 개발하다가 무언가 되지 않는 이유와 되는 이유를 찾기 위해. 그런데 지난 1년간 단 한 번도 방문하지 않았고, 존재 자체를 잊고 지냈다.

마찬가지로, 2023년부터 사이드 프로젝트에 Next.js와 Supabase를 사용하면서, (초기 버전이라 이슈가 많았어서) 자연스럽게 공식 Discord 채널에 일주일에 1번 이상은 질문을 올렸는데, 이제는 아예 접속조차 하지 않는다.

이 블로그도 개발 블로그로 시작했었는데, 이제는 개발과 관련된 글은 거의 올리지 않게 되었다. 나조차도 개발과 관련된 것들은 더 이상 블로그를 찾아보지 않고 LLM에게 물어보거나, 혹은 아예 물어볼 필요도 없이 개발 과정에서 LLM이 알려주기 때문이다.

선행자들의 경험에 의존하지 않고, LLM에 의존하게 된 것이다.

3. 유일한 병목

Cursor를 쓸 때는 코드 변경 사항을 하나씩 확인했지만, 클로드코드를 쓴 이후에 코드 변경을 세세하게 검토하지 않게 되었다.

대신 시스템 아키텍쳐와 구현 방식/방향은 여전히 꼼꼼하게 체크하는데, 이 지점에서 병목이 발생한다.

지난 1년간 개발한 Posteady.com 의 프로젝트 규모가 커지면서, 클로드코드가 참고해야 하는 컨텍스트 규모가 커지고, 복잡도가 높아지다 보니 단순한 작업 외에는 대부분 Superpowers 스킬을 사용한다. (마무리는 /simplify)

그런데 이 스킬은 작업을 진행하기 전에 구현 방향과 방식을 정하기 위한 질문도 많고, 구현 계획 문서와 코드 리뷰 결과 등, 읽어야 하는 코드 글의 양이 많다.

결국 내 독해 속도가 유일한 병목이 된다.

4. 모니터 다다익선

처음에는 모니터 1대로 시작했다가, 하나씩 늘려서 모니터 3대가 되었다.

지난 3년간 Raycast를 적극적으로 쓴 덕에 단축키 최적화가 잘 된 편이라 화면 전환을 쉽고 빠르게 할 수 있지만, 클로드코드 3개 이상부터는 모니터를 1개만 쓰면 화면 전환을 너무 자주해서 불편했다.

그렇다고 모니터 하나에서 터미널을 여러 개로 나눌 수도 없었다. 나는 시력 보호를 위해 코드도 글자도 크게 보는 편이기 때문이다. 모니터 하나에 터미널 2개 이상은 무리였다. (터미널은 Warp 사용 중)

결국 모니터를 늘려서 모니터당 2개씩 총 6개의 worktree로 클로드코드를 돌리는 세팅에 정착했다. 그리고 세 번째 모니터를 구매한 2026년 2월 말부터 확실하게 작업 속도가 빨라졌다.↓ (이 글을 쓰는 중에도 양쪽 모니터에서는 각각 2개씩 총 4개의 작업이 진행 중이다.)

회사 업무와 육아 덕분에 commit 수가 많지는 않지만, 모니터 추가 이후 확실히 작업 속도는 빨라졌다.

멀티태스킹이 잘 되는 분들은 모니터가 많을수록 좋을 것 같다. 나는 6개 이상은 클로드코드 작업 속도를 내가 따라갈 수 없었고, 내 금붕어급 기억력 덕분에 이게 무슨 작업이었는지 잊어버려서 6개가 최적이었다.

물론 결과물 퀄리티가 크게 상관없는 작업이거나, 유료 서비스 개발이 아니라면 클로드 코드를 더 많이 돌리거나, 하네스를 깎아서 알아서 몇 시간씩 작업하게끔 세팅하겠지만,

Posteady.com은 대부분 유료 결제해서 사용하는 1인 사업자나 마케팅 대행사들이기 때문에 안정성이 중요해서 그럴 수 없었다.

5. 그리운 손코딩

나는 2017년 12월부터 개발 공부를 시작했고, 2018년부터 개발자로 일했다. 돌이켜보면 운이 좋았다. 2018년부터 2022년까지 약 5년간 개발자 황금기(?)였기 때문이다.

2018년쯤에는 AWS가 국내에 적극적으로 보급되면서, 많은 회사가 클라우드로 전환하던 시기였는데 DevOps는 거의 없던 시절이라 주니어 백엔드 개발자들도 성장에 도움 되는 다양한 경험을 할 기회가 많았고,

네카라쿠배를 비롯한 테크 회사들과 스타트업들이 비약적으로 성장/확장하기 시작한 시기라 취업과 이직도 수월했다.

이즈음부터 생활코딩을 넘어선 인프런에 다양한 개발 강의들이 올라오기 시작했고, 개발 서적 스터디나 개발자들이 모이는 컨퍼런스도 활발해서 사람들과 함께, 사람들 사이에서 조금씩 성장하는 재미가 있었다.

특히 객체지향 프로그래밍(OOP), 클린코드, 이펙티브 자바 같은 책들 내용을 실무에 적용하면서 코딩의 재미를 많이 느꼈었는데, 이제는 그 쾌감(?)을 느낄 틈조차 없어진 것 같아 아쉽다.

6. 앞으로는?

집에서도 회사에서도 직접 코드를 작성하지 않고, 클로드코드와 코덱스로만 개발한다. 집에서는 1년 되었고, 회사에서는 6개월 전부터 엔터프라이즈 계정을 제공해줬다.

내가 개발자로 일한 9년 중 지난 1년의 변화는 그야말로 천지개벽 수준이었다. 특히 해고가 자유로운 이곳 미국에서는 개발자들의 직업 안정성이 확 떨어졌다.

AI에 대체되기 쉬운 평범한 개발자인 내가 하는 준비는 단순하다. 월급 의존도 낮추기.

모두의 손에 AI라는 도구가 주어졌다. 비개발자들이 뛸 수 있게 되었다면, 개발자들에게는 날개가 달린 것이다. 각자의 선택이다. 날개를 퍼덕거리며 날아갈 준비를 하거나, 닭처럼 편히 지내다가 치킨 ~~혹은 치킨집 사장~~이 되거나.

[책] 에이전트 시대의 AI 시스템 설계

2026-05-23T12:01:48+09:00

한빛미디어 서평단 <나는 리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다

에이전트 시대의 AI 시스템 설계

최근 정보기술(IT) 업계를 바라보고 있으면 거대한 패러다임의 전환 한복판에 서 있다는 사실을 온몸으로 실감하게 됩니다. 생성형 AI의 등장 이후 우리는 매일같이 쏟아지는 새로운 모델과 기법의 홍수 속에 살고 있지요. 하지만 현업에서 이를 활용해 실제 비즈니스에 가치를 더하는 애플리케이션을 구축하려고 하면, 기술의 화려함 이면에 숨겨진 수많은 현실적 장벽과 마주하게 됩니다. 환각 현상을 어떻게 제어할 것인가, 예측 불가능한 거대 언어 모델의 출력을 어떻게 기존 시스템과 안정적으로 연동할 것인가와 같은 고민들 말입니다. '에이전트 시대의 AI 시스템 설계'는 바로 이러한 지점에서 방황하는 엔지니어와 설계자들에게 명확한 이정표를 제시해 주는 책입니다. 단순히 프롬프트를 잘 쓰는 요령을 알려주는 시중의 가벼운 지침서들과는 궤를 달리하며, AI를 견고한 소프트웨어 공학의 영역으로 끌어올리는 묵직한 내공이 돋보입니다.

이 책이 지닌 가장 독보적인 가치는 거대 언어 모델이라는 원시적인 재료를 가지고 어떻게 실무에서 작동하는 안전하고 확장 가능한 에이전트 시스템을 '빌드'할 수 있는지 그 아키텍처 패턴을 집대성했다는 점에 있습니다. 로짓 마스킹이나 문법 제어 같은 텍스트 스타일링의 기본기부터 시작해서, 검색 증강 생성(RAG)의 기초와 심화 과정을 거쳐, 종국에는 다중 에이전트 협업과 장기 기억 시스템 구축에 이르기까지 그 여정이 무척이나 촘촘합니다. 흔히 AI 시스템을 만든다고 하면 거대한 모델 자체를 학습시키는 일에만 주목하기 쉽지만, 이 책은 그 모델이 현실 세상의 API를 호출하고 코드를 실행하며 안전하게 행동할 수 있도록 만드는 '시스템적 안전장치'와 '컨텍스트 제어'가 왜 더 중요한지 집요하게 파고듭니다. 기술의 표면적 현상에 매몰되지 않고 시스템 전체를 관통하는 설계 원칙을 다룬다는 점에서, 읽는 내내 노련한 아키텍트의 깊이 있는 통찰력을 고스란히 느낄 수 있었습니다.

특히 페이지를 넘기며 무릎을 탁 치게 만들었던 부분은, 이론적인 아키텍처 패턴의 나열에 그치지 않고 개발자가 현업에서 즉시 활용할 수 있는 구체적인 예시 코드를 아낌없이 제공한다는 점이었습니다. 추상적인 다이어그램 몇 장으로 '이렇게 설계하면 됩니다'라고 말하는 책들은 많지만, 이 책은 그 설계가 실제 애플리케이션 레벨에서 어떻게 구현되는지 코드를 통해 직접 증명해 보입니다. 사고 연쇄(CoT)나 심판형 LLM, 프롬프트 캐싱과 가드레일 같은 고난도 기법들이 소스 코드 안에서 어떻게 유기적으로 맞물려 돌아가는지 눈으로 확인하는 과정은 대단히 짜릿한 경험이었습니다. 덕분에 모호하게 구름 위에 떠 있던 에이전트형 작업흐름의 개념이 단숨에 현실의 영역으로 내려와 명쾌하게 이해되었습니다.

결국 이 책이 우리에게 던지는 메시지는 명확합니다. 앞으로의 AI 애플리케이션 개발은 얼마나 더 큰 모델을 쓰느냐의 싸움이 아니라, 주어진 모델의 능력을 확장하고 제약 조건을 극복하며 얼마나 신뢰할 수 있는 '에이전트형 작업흐름'을 촘촘하게 설계하느냐의 싸움이 될 것이라는 점입니다. 소규모 언어 모델의 최적화나 성능 저하 테스트, 인퍼런스 비용을 아끼기 위한 캐싱 전략까지 다루는 후반부를 읽다 보면, 저자가 실제 프로덕션 환경에서 수많은 시행착오를 겪으며 쌓아 올린 실전 노하우가 그대로 전해집니다. AI를 다루는 엔지니어뿐만 아니라 차세대 서비스 아키텍처를 고민하는 모든 기술 리더들에게 이 책은 훌륭한 길잡이가 되어줄 것입니다.

우리가 만드는 시스템은 과연 변화하는 AI 패러다임 수용할 만큼 유연하고, 동시에 비즈니스의 엄격한 기준을 만족할 만큼 통제 가능한 구조를 갖추고 있을까요? 단순히 신기한 기술을 구현하는 것을 넘어, 비즈니스를 실제로 움직이는 '살아있는 에이전트 시스템'을 설계하기 위해 우리는 지금 무엇을 준비해야 할지 진지하게 고민해보게 됐습니다.

이력서의 서사

2026-05-19T23:14:16+09:00

트위터에서 가끔 보이는 링크드인 밈이 있다.

맥도날드에서 아르바이트한 경험을 이력서에 쓸 때, 그냥 "맥도날드 알바"라고 쓰지 않는다는 것이다.
"글로벌 F&B 기업에서 고객 접점 운영을 경험"했다고 쓴다.
편의점 알바는 "리테일 현장에서 재고 관리와 고객 경험을 담당"한 일이 되고, 카페 알바는 "고객 응대와 주문 처리 프로세스를 개선한 경험"이 된다.

처음 보면 웃기다.
특히 링크드인 특유의 진지한 문체와 만나면 더 그렇다.
별것 아닌 경험을 대단한 커리어처럼 포장하는 것처럼 보인다.

그런데 한편으로는 꼭 나쁘게만 볼 일인가 싶기도 하다.

맥도날드에서 일했다는 사실은 작아 보인다.
하지만 그 안에는 피크타임의 압박, 반복되는 주문, 실수하면 바로 드러나는 현장, 낯선 고객을 상대하는 긴장, 같이 일하는 사람들과 맞춰 움직이는 감각이 있다.
그걸 "그냥 알바"라고만 부르면 경험의 대부분이 사라진다.
반대로 "글로벌 프랜차이즈 매장에서 표준화된 운영과 고객 응대를 경험했다"고 말하면, 같은 사실 안에서 다른 의미가 드러난다.

그래서 이 밈이 웃기면서도 완전히 틀렸다고 말하기는 어렵다.
같은 경험을 두고도, 어디까지가 해석이고 어디부터가 과장인지는 문장 하나 차이로 갈린다.

"글로벌 F&B 기업의 매출 성장 전략을 리드했다"고 쓰면 거짓에 가깝다.
하지만 "글로벌 프랜차이즈 매장에서 고객 응대, 주문 처리, 동료 협업을 경험했다"고 쓰면 그것은 포장이라기보다 해석이다.
자신이 한 일을 더 정확한 언어로 다시 보는 일이다.

이 밈을 보고 떠오른 논문이 있었다.
"Seeing Your Life Story as a Hero's Journey Increases Meaning in Life"라는 제목의 연구다.
자기 삶을 영웅의 여정처럼 인식할수록 삶의 의미감이 높아진다는 내용이다.
영웅의 여정이라고 해서 꼭 용을 물리치거나 세계를 구해야 하는 것은 아니다.
익숙한 세계를 떠나고, 낯선 과제를 만나고, 조력자를 만나고, 시련을 겪고, 이전과 조금 다른 사람이 되어 돌아오는 구조다.

생각해보면 많은 경험이 그렇다.

첫 아르바이트도 그렇고, 첫 회사도 그렇고, 처음 맡은 장애 대응도 그렇다.
당시에는 그저 정신없이 지나간 일처럼 느껴지지만, 시간이 지난 뒤 돌아보면 그 안에 나를 바꾼 장면들이 있다.
처음으로 돈을 벌어본 감각, 고객 앞에서 내 감정을 조절한 경험, 누군가와 같이 일한다는 것이 생각보다 어렵다는 발견, 매뉴얼과 현실 사이의 차이를 몸으로 알게 된 순간 같은 것들이다.

우리는 남의 이력을 볼 때는 과장을 잘 찾아낸다.
"저걸 저렇게까지 쓴다고?" 하고 웃는다.
그리고 그 냉소적인 시선을 자기 삶에도 그대로 들이댄다.
"그냥 알바였어."
"그냥 시키는 일 한 거지."
"별거 아니야."
그렇게 말하는 사이에 실제로 배운 것들까지 같이 사라진다.
남들이 내 일을 작게 보는 건 어쩔 수 없다.
하지만 나까지 내가 지나온 시간을 굳이 별볼 일 없는 일로 만들 필요는 없다.

앤절라 더크워스의 "그릿"에도 비슷한 이야기가 나온다.

세 명의 벽돌공에게 같은 질문을 한다.
"무엇을 하고 있습니까?"
첫 번째 사람은 벽돌을 쌓고 있다고 답한다.
두 번째 사람은 교회를 짓고 있다고 답한다.
세 번째 사람은 하느님의 성전을 짓고 있다고 답한다.

세 사람은 같은 일을 하고 있다.
손에 든 도구도 같고, 쌓고 있는 벽돌도 같다.
그런데 그 일을 바라보는 방식은 다르다.
첫 번째 사람에게 그것은 생업이고, 두 번째 사람에게는 직업이며, 세 번째 사람에게는 천직이다.

세 번째 사람이 거짓말을 한 것은 아니다.
그는 벽돌을 쌓고 있었다.
동시에 성전을 짓고 있었다.
눈앞의 행위만 보면 벽돌 쌓기지만, 그 일이 연결되는 더 큰 맥락까지 보면 성전을 짓는 일이 된다.

내가 하지 않은 일을 했다고 말하면 과장이다.
벽돌 하나를 얹었을 뿐인데 성당의 설계를 총괄했다고 말하면 거짓이다.
하지만 내가 얹은 벽돌이 어떤 건물의 일부였는지, 그 일을 통해 무엇을 배웠는지, 그 경험이 내 안에서 어떤 의미가 되었는지를 말하는 것은 거짓이 아니다.

같은 일을 하더라도 그 일을 어떻게 바라볼지는 내가 선택할 수 있다.
나는 단순히 주문을 받았는가, 아니면 고객이 몰리는 현장에서 감정과 속도를 조율하는 법을 배웠는가.
나는 단순히 벽돌을 쌓았는가, 아니면 오래 남을 무언가의 일부를 만들고 있었는가.
그 일을 밖에서 어떻게 부르는지는 내가 정할 수 없다.
하지만 내 안에서 그 일을 어떤 문장으로 남길지는 내가 정할 수 있다.

돌아보면, 만족스러웠던 시기가 꼭 대단한 사건이 많았던 때만은 아니었다.
같은 사건도 어떤 이야기 안에 놓느냐에 따라 다르게 남는다.
어떤 사람에게 첫 아르바이트는 단순한 시급 노동으로 남지만, 어떤 사람에게는 사회가 어떻게 움직이는지 처음 몸으로 배운 시간이 된다.

서사는 사실의 의미를 다시 바라보는 일이다.
내가 지나온 시간을 어떤 이야기 안에 놓을지 선택하는 일이다.

스스로가 걸어온 길을 굳이 별볼 일 없이 만들지 않았으면 좋겠다.
남들이 그 일을 어떻게 바라보든, 내가 어떤 문장으로 그 일을 남기느냐가 내 삶의 만족도에 오래 영향을 준다.
그러니 그간의 내 여정에 서사를 붙여 바라보면 어떨까?

[SE-0522] Source-Level Control Over Compiler Warnings

2026-05-23T08:45:27+09:00

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0522 — 소스 레벨에서의 컴파일러 경고 제어에 대해 정리해보겠습니다

Intro

Proposal: SE-0522
Authors: Artem Chikin, Doug Gregor, Holly Borla
Review Manager: Tony Allevato
Status: Accepted

Motivation

SE-0443에서는 커맨드라인 플래그로 컴파일러 경고를 제어할 수 있게 되었습니다.

예를 들어 -Werror DeprecatedDeclaration을 사용하면 Deprecated 경고를 에러로 격상시킬 수 있죠.

하지만 이 방식은 모듈 전체에 적용되는 블런트한 수단이에요.

특정 선언에서만 예외를 두고 싶은 경우에는 대응할 방법이 없었습니다.

// 모듈 전체에 -Werror DeprecatedDeclaration 적용 중
func bridgeToLegacySystem() {
  oldAPI() //   error: 'oldAPI()' is deprecated [#Deprecated]
}
// 이 함수만 warning으로 낮추고 싶어도 방법이 없었어요

마이그레이션 중인 코드베이스, 레거시 호환성 유지, strict 언어 모드의 점진적 도입 등 현실에서 "딱 이 선언만 예외"가 필요한 순간은 생각보다 많거든요!

Proposed Solution

새로운 선언 어트리뷰트 @diagnose를 도입합니다.

어노테이션된 선언의 렉시컬 스코프 내에서 특정 diagnostic group의 경고 동작을 error, warning, ignored 세 가지 중 하나로 제어할 수 있어요.

기본 문법

@diagnose(group-identifier, as: error | warning | ignored)
@diagnose(group-identifier, as: behavior, reason: "이유")

동작 예시

// 모듈 전체: -Werror DeprecatedDeclaration 적용 중

func normalFunction() {
  oldAPI() //   error
}

@diagnose(DeprecatedDeclaration, as: warning,
           reason: "Must maintain compatibility until end of release cycle")
func bridgeToLegacySystem() {
  oldAPI() //   warning: 'oldAPI()' is deprecated [#Deprecated]
}

ignored로 지정하면 해당 스코프에서 완전히 경고를 억제할 수 있어요.

@diagnose(UnsafeImportedAPI, as: warning)
struct LegacyFormatReader {
  func read(_ data: UnsafeRawPointer, _ count: Int) -> Header {
    c_read_bundle(data, count) //   warning
  }

  @diagnose(UnsafeImportedAPI, as: ignored, reason: "input is validated upstream")
  func readTrustedInput(_ data: UnsafeRawPointer, _ count: Int) -> Header {
    c_read_bundle(data, count) // 진단 없음
  }
}

서브그룹에도 개별적으로 적용이 가능합니다.

// UnsafeImportedOwnership은 UnsafeImportedAPI의 서브그룹
// 모듈 전체: -Werror UnsafeImportedAPI

@diagnose(UnsafeImportedOwnership, as: warning)
func createSession(_ ctx: OpaquePointer) -> Session {
  let session = c_create_session(ctx)
  //   warning: cannot infer ownership ... [#UnsafeImportedOwnership]

  c_bind_session(session, nil)
  //   error: call to imported function ... [#UnsafeImportedAPI]
}

Detailed Design

적용 가능한 선언 종류

@diagnose는 func, struct, class, enum, actor, protocol, extension, init, deinit, subscript, macro, typealias, associatedtype, get/set, willSet/didSet, import, enum case 등 대부분의 선언에 적용할 수 있습니다.

@diagnose(DiagGroupID, as: ignored)
import bar

@diagnose(DiagGroupID, as: ignored, reason: "Proposal Example")
func foo() { ... }

struct Foo {
  var property: Int {
    @diagnose(DiagGroupID, as: ignored)
    get { ... }
    @diagnose(DiagGroupID, as: ignored)
    set { ... }
  }
}

여러 @diagnose 어트리뷰트 — 순서가 중요합니다!

동일한 선언에 여러 @diagnose를 적용할 경우 마지막(렉시컬 순서상 가장 아래)에 있는 어트리뷰트가 우선합니다.

@diagnose(DiagGroupID, as: error)
@diagnose(DiagGroupID, as: warning) // 이 쪽이 최종 적용됨
public func foo() { ... }

Swift 어트리뷰트는 일반적으로 순서 무관하지만, @diagnose는 SE-0443의 커맨드라인 플래그 동작과 일관성을 맞추기 위해 순서가 중요합니다!

-suppress-warnings와의 관계

-suppress-warnings 플래그가 적용된 상태에서는 @diagnose가 완전히 무시됩니다.

as: error를 지정해도 에러로 격상되지 않아요.

이는 SE-0480에서 SwiftPM이 외부 패키지 의존성 빌드 시 경고 관련 플래그를 -suppress-warnings로 대체하는 방식과의 일관성을 위한 것입니다.

매크로와의 상호작용

@diagnose가 적용된 스코프 내에서 매크로가 코드를 생성하면, 그 생성된 코드에도 어트리뷰트의 효과가 적용됩니다.

또한 매크로 작성자가 매크로 확장 코드 안에 직접 @diagnose를 생성할 수도 있어요.

// 매크로 확장 결과물에 @diagnose가 포함될 수 있어요
@diagnose(DeprecatedDeclaration, as: error)
public func endpoint() -> UserProvidedType {
  //   error: 'UserProvidedType' is deprecated [#DeprecatedDeclaration]
}

단, 어트리뷰트가 적용된 선언에 peer 매크로가 붙어 있는 경우, @diagnose의 효과는 peer로 생성된 독립 선언에는 전파되지 않습니다.

Source Compatibility / ABI

이번 변경은 순수 additive 변경으로 기존 소스 호환성에 영향이 없습니다.
ABI에도 영향이 없으며, 텍스트 모듈 인터페이스에도 방출되지 않습니다.
배포 제약 없이 자유롭게 도입하거나 제거할 수 있습니다.

Alternatives Considered

Region-based #pragma 스타일 지시문

Clang 등 C계열 컴파일러처럼 임의 코드 영역에 #pragma clang diagnostic push/pop을 사용하는 방식도 고려되었어요.

하지만 Swift는 메타데이터와 동작을 선언에 귀속시키는 방식을 선호하고, 영역의 끝을 수동으로 관리해야 한다는 점이 복잡한 버그로 이어질 수 있어 채택되지 않았습니다.

매크로 생성 코드에서 @diagnose 금지하기

모든 경고 제어가 개발자 소스 코드에서 명시적으로 보이도록 매크로 확장에서 @diagnose 생성을 금지하는 방법도 고려되었지만, 매크로 작성자가 자신이 생성하는 코드에 대한 진단 정책을 표현할 수 없게 되므로 허용하는 방향으로 결정되었습니다.

-suppress-warnings 하에서도 as: error 적용하기

무조건적인 소스 레벨 에러 격상을 위해 -suppress-warnings 하에서도 as: error를 적용하는 방법도 고려되었지만, SE-0443 및 SE-0480과의 일관성 유지를 위해 채택되지 않았습니다.

Future Directions

로컬 렉시컬 스코프 제어 — do {} 블록처럼 선언이 아닌 임의 스코프에도 적용하는 방향
클로저 표현식 — 특정 클로저 body의 경고 동작 제어
파일 스코프 제어 — using @diagnose(...) 형태의 파일 범위 제어
서드파티 툴 통합 — @diagnose(rule, from: SwiftLint, as: ignored) 같은 형태로 린터 등과의 통합

Conclusion

커맨드라인 플래그로만 가능했던 경고 제어를 소스 레벨의 선언 단위로 세밀하게 다룰 수 있게 해주는 실용적인 변경입니다

마이그레이션 중인 코드베이스, 레거시 호환성 유지, strict 언어 모드의 점진적 도입 등 현실적인 시나리오에서 개발자가 예외의 의도를 코드에 명확하게 문서화할 수 있게 됩니다.

Swift가 더 엄격한 언어 모드와 정적 분석을 강화해가는 흐름 속에서, @diagnose는 그 여정을 훨씬 유연하게 해줄 도구라고 생각합니다

References

swift-evolution/proposals/0522-source-warning-control.md at main · swiftlang/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swiftlang/swift-evolution

github.com

<에이전트 시대의 AI 시스템 설계> AI 실습 문제 생성은 프롬프트만 잘 쓰면 충분할까?

2026-05-24T09:00:00+09:00

“한빛미디어 <나는 리뷰어다> 활동을 위해 도서를 제공받아 작성된 서평입니다.”

제품을 만들 때 AI로 실습 문제를 생성하는 기능을 붙인 적이 있다. 사용자의 직무, 개선하고 싶은 업무, 지금 하고 있는 일을 입력으로 받아서 그 사람의 상황에 맞는 실습 문제를 만들어주는 흐름이었다. 처음에는 프롬프트에 규칙을 잘 적어두면 어느 정도 안정적인 결과가 나올 거라고 생각했다.

그런데 실제로 만들어보니 생각보다 쉽지 않았다. 결과물이 겉으로는 문제 형식을 갖추고 있었지만, 실제 업무 상황처럼 느껴지지 않는 경우가 많았다. 실습 데이터도 부실해서 사용자가 “이걸 내 업무에서 어떻게 쓰지?”라고 느낄 만한 결과가 나왔다. 직무와 상황을 입력으로 넣었는데도, 결과물은 그 맥락을 깊게 반영하지 못했다.

그래서 계속 규칙을 고쳤다. “이런 상황을 더 구체적으로 반영해라”처럼 규칙을 자세히 쓰기도 했고, 반복해서 안 좋은 결과가 나오는 경우에는 “이런 식으로 만들면 안 된다”는 금지 규칙을 추가하기도 했다. 이 과정을 반복하면서 AI 기능은 프롬프트 한 번으로 완성되는 게 아니라, 실패 사례를 보고 규칙과 검증 기준을 계속 보강하는 운영 루프에 가깝다는 생각을 하게 됐다.

이 책 <에이전트 시대의 AI 시스템 설계>는 생성형 AI를 실제 서비스로 운영할 때 마주치는 환각, 비결정적 응답, 지식 공백, 도구 호출 실패, 비용과 지연시간, 안전장치 문제를 32가지 설계 패턴으로 다루는 책이다. 내가 겪었던 “AI가 문제는 만들지만 좋은 실습 문제는 못 만든다”는 문제도 결국 프롬프트 문장력보다 시스템 설계에 가까웠다.

인사이트 1: 좋은 문제를 만들려면 좋은 맥락이 먼저 필요하다

AI에게 직무와 상황을 넣었다고 해서 곧바로 실제 업무 같은 문제가 나오지는 않았다. “프론트엔드 개발자”, “업무 자동화를 개선하고 싶다”, “현재 이런 일을 하고 있다” 같은 정보를 줘도 결과물은 종종 일반적인 예시 문제에 머물렀다. 입력값은 구체적인데 출력은 뭉뚱그려지는 느낌이었다.

이때 아쉬웠던 건 실습 데이터였다. 실제 업무에서 다룰 법한 데이터, 제약 조건, 예외 상황, 의사결정 맥락이 있어야 문제가 살아나는데, AI가 만든 데이터는 너무 얇았다. 테이블이나 예시 값은 있지만 현업에서 마주치는 복잡함이 없었다. 그래서 학습자는 문제를 풀 수는 있어도, 그 문제가 자기 업무와 연결된다는 느낌을 받기 어려웠다.

책을 읽으면서 가장 먼저 연결된 부분도 RAG와 지식 추가였다. 기본 RAG, 의미 기반 색인화, 대규모 색인화, 신뢰할 수 있는 생성 같은 주제를 따로 다루는데, 여기서 좋았던 건 RAG를 단순히 “문서 검색 붙이기”로 설명하지 않는다는 점이었다. 내가 만들던 기능에 대입해보면, 사용자 입력 몇 개를 프롬프트에 넣는 것만으로는 부족하고, 직무별 업무 사례나 좋은 실습 데이터의 기준을 어떻게 공급할지까지 설계해야 한다는 이야기로 읽혔다.

결국 맥락은 “문장으로 설명하는 것”만으로 충분하지 않다. 좋은 실습 문제를 만들려면 사용자의 직무와 상황을 해석할 수 있는 참고 데이터, 예시, 제약 조건이 같이 들어가야 한다. 책을 읽고 나서는 내가 부족하다고 느꼈던 “실습 데이터의 부실함”도 단순 데이터 양의 문제가 아니라, 어떤 지식을 어떻게 가져오고 생성 과정에 연결할지의 문제였다는 생각이 들었다.

인사이트 2: 금지 규칙도 시스템의 일부다

실습 문제 생성에서 규칙을 추가하다 보면 자연스럽게 금지 규칙이 늘어난다. 처음에는 “직무와 레벨을 반영해라”처럼 원하는 방향을 적는다. 그런데 결과를 보다 보면 “이런 식으로 만들면 안 된다”는 조건이 더 중요해지는 순간이 생긴다. 실제 업무 상황 같지 않은 문제, 데이터가 너무 단순한 문제, 정답이 뻔한 문제, 맥락 없이 용어만 바꾼 문제 같은 것들이다.

이런 금지 규칙을 넣으면 당장은 나아진다. 하지만 금지 규칙만 계속 늘어나는 방식은 한계가 있다. 프롬프트가 길어지고, 규칙 사이의 우선순위가 애매해지고, 새로운 실패 유형이 나오면 또 규칙을 추가해야 한다. 결국 “규칙을 얼마나 많이 쓰느냐”보다 “어떤 실패를 막아야 하고, 그 실패를 어떻게 감지할 것인가”가 더 중요한 문제가 된다.

책의 후반부에는 템플릿 생성, 조립 후 재구성, 자체점검, 가드레일 같은 안전장치 패턴이 나온다. 이 부분을 읽으면서 내가 프롬프트에 계속 추가하던 금지 규칙을 조금 다르게 보게 됐다. AI가 부실한 실습 문제를 만들지 않게 하려면 단순히 “잘 만들어줘”라고 하는 게 아니라, 나쁜 결과의 유형을 정의하고 막는 장치가 필요하다.

내가 추가했던 금지 규칙은 일종의 작은 가드레일이었다. 다만 그때는 그것을 시스템 설계라고까지 생각하지 못했다. 책을 읽고 나니 금지 규칙을 프롬프트 안에 계속 쌓아두는 것보다, 템플릿, 자체점검, 평가 기준으로 분리하는 편이 더 운영 가능한 방식이라는 생각이 들었다.

인사이트 3: 퀄리티 컨트롤은 생성 이후에 더 중요해진다

실습 문제 생성에서 가장 어려웠던 건 퀄리티 컨트롤이었다. 문제를 하나 생성하는 것 자체는 어렵지 않았다. 어려운 건 그 문제가 정말 사용자의 직무와 상황에 맞는지, 실습 데이터가 충분한지, 실제 업무 상황처럼 느껴지는지 판단하는 일이었다.

처음에는 결과가 마음에 들지 않으면 프롬프트를 고쳤다. 규칙을 더 구체화하거나 금지 규칙을 추가했다. 하지만 시간이 지날수록 프롬프트를 수정하는 것만으로는 충분하지 않다는 생각이 들었다. 어떤 결과가 좋은 문제인지, 어떤 결과가 나쁜 문제인지 판단하는 기준이 더 중요했다. 기준이 없으면 매번 사람이 감으로 보고 고쳐야 한다.

이 책은 신뢰성 개선 파트에서 심판형 LLM, 성찰, 의존성 주입, 프롬프트 최적화 같은 패턴을 다룬다. 제약 조건 해결 파트에는 성능 저하 테스트도 있다. 이 부분을 읽으면서 이 책이 “생성”만이 아니라 “생성된 결과를 어떻게 믿을 것인가”를 꽤 중요하게 다룬다는 느낌을 받았다.

내 경험에 대입하면, AI가 만든 실습 문제를 다시 평가하는 단계가 필요했다. 예를 들어 “실제 업무 상황이 드러나는가”, “사용자의 입력이 문제에 반영됐는가”, “실습 데이터가 충분한가”, “금지한 유형의 문제가 나오지 않았는가” 같은 기준이다. 이 기준을 사람이 매번 감으로 보는 게 아니라, 시스템 안에 넣을 수 있어야 제품으로 안정화될 수 있다. 책에서 말하는 신뢰성 개선 패턴은 이 지점을 정리하는 데 도움이 됐다.

마무리

책을 다 읽고 나니, 이 책은 단순한 AI 입문서나 프롬프트 작성법 책과는 거리가 있었다. 생성형 AI를 실제 서비스로 운영할 때 생기는 문제를 패턴 단위로 다루는 책에 가깝다. 그래서 처음부터 끝까지 순서대로 읽는 것도 가능하지만, 지금 만들고 있는 AI 기능에서 막히는 지점을 기준으로 필요한 패턴을 찾아 읽는 방식도 잘 맞아 보였다.

내가 AI 실습 문제 생성 기능을 만들면서 겪었던 문제도 결국 같은 방향이었다. 좋은 결과가 나오지 않을 때마다 프롬프트를 고치고 규칙을 추가했지만, 더 근본적으로는 맥락 공급, 금지 규칙, 품질 평가, 검증 루프가 필요했다. 이 책을 읽으면서 그 경험을 RAG, 신뢰성 개선, 가드레일, 성능 저하 테스트 같은 패턴으로 다시 정리할 수 있었다.

AI 기능을 빠르게 만드는 단계에서는 프롬프트와 데모가 중요하다. 하지만 오래 버티는 AI 시스템을 만들려면 그 뒤의 설계가 필요하다. 특히 AI로 무언가를 생성하는 제품을 만들고 있고, “결과는 나오는데 품질이 안정적이지 않다”는 고민을 해본 사람이라면 이 책에서 연결해볼 지점이 많을 것 같다.

#한빛미디어 #나는리뷰어다 #에이전트시대의AI시스템설계 #AI시스템설계 #RAG #가드레일 #AI에이전트

AMD의 구원 투수이자 반도체 제국의 여제, 리사 수(Lisa Su)

2026-05-21T00:00:52+09:00

때로는 '하면 된다'가 아니라 '되면 한다'가 더 큰 결과를 만들어 낼 수 있습니다. 어린 시절 피아니스트를 꿈꾸었던 한 소녀는 음악 명문인 줄리어드 음대 진학을 목표로 열심히 피아노를 연습합니다. 여러 차례 오디션과 콩쿨을 거치면서 아무리 노력해도 자신은 세계 1등 피아니스트가 될 수 없다는 냉혹한 현실을 깨닫습니다. 그리고는 기왕 무언가를 해야 한다면 자신이 최고가 될 수 있는 일을 하겠다고 결심합니다. 그동안 연습해 오던 피아노를 덮고, 자신이 가장 잘하는 수학과 과학에 매진합니다. 1986년 소녀는 마침내 전세계 수재들이 모이는 MIT에 입학합니다. 이제 전공을 선택해야 하는데, 선배와 동기들이 '전기공학은 너무 어렵고 과제가 많아 미친짓'이라고 말하는 것을 듣고, '가장 어려운 문제를 풀었을 때 가장 큰 성취감을 얻으니까.. 가장 어려운 전공이라면 내가 그걸 해야지.'라며 전기공학을 선택합니다. 그 소녀는 현재 AMD를 이끌고 있는 반도체 제국의 여제, 리사 수입니다.

MIT에서 웨이퍼 제작 관련 논문으로 석박사학위를 취득한 후, 리사 수는 IBM 반도체 R&D 이사로써 구리 배선 기술을 상용화하는데 큰 역할을 담당합니다. 또한 소니, 도시바와 협력하여 게이밍용 차세대 프로세스 개발을 지휘합니다. 이 성과로 셀-브로드밴드 엔진이 개발될 수 있었고, 이를 이용하여 플레이스테이션 3의 핵심 프로세서가 만들어 집니다.

2012년 그녀는 인텔에 밀리고 있던 AMD에 합류합니다. 리사 수는 2014년 CEO 에 취임한 이후, 선택과 집중 전략을 선언하고, 모든 사내 리소스를 차세대 아키텍처인 ZEN 개발에 집중시킵니다. 당시 업계에서는 조만간 AMD가 파산할 것이라 예측했었죠. 하지만 리사 수는 취임 직후 자신의 개인 재산을 털어 AMD 주식을 대량으로 사들입니다. CPU 시장에서 인텔에 밀리고 있던 AMD는 2017년 라이젠 CPU와 에픽(EPYC) 서버 칩을 출시하면서 점차 기술적 우위를 회복하기 시작했고, 콘솔 게임기의 CPU를 독점하게 되면서 큰 성장을 이루게 됩니다. 리사 수가 CEO로 합류할 당시 주가는 3달러였는데, 현재는 400달러가 넘는 회사로 부활시켰습니다.

AMD를 부활시킨 리사수는 대만 타이난 출신으로, 엔비디아의 젠슨 황과 5촌관계입니다. 리사수의 외할아버지와 젠슨 황의 어머니가 남매지간이라고 하네요.

"가장 어려운 문제들을 향해 달려가십시오. (Run toward the hardest problems.)"

"가장 큰 위험은 어떠한 위험도 감수하지 않는 것입니다." (The biggest risk is not taking any risk.)

"혁신은 사치가 아니라 필수입니다. (Innovation is not a luxury; it's a necessity.)"

"저는 MIT에서 많은 엔지니어들과 함께 학교를 다녔습니다. 그리고 어느 날 '왜 MIT 박사들이 하버드 MBA 출신들을 위해 일해야 하는가?'라는 의문을 가졌습니다. 이제 직접 결정하는 사람이 되는 것은 즐거운 일입니다."

우리는 결코 싼값에 파는 '저가형 대안(Cheap Alternative)'이 아니다. 우리는 시장에서 가장 뛰어난(Best) 제품을 만들 것이다

"우리는 단지 성공적인 반도체 회사가 되는 것을 넘어, 세상을 바꾸는 유산을 남기고 싶습니다." (We want to leave a legacy of changing the world.)

나답게 살고 싶다

2026-05-24T18:00:00+09:00

역시 회사생활은 재미가 없다. 어느 순간부터 나는 점점 더 "올바른 사람"이 되어가고 있었다. 창업을 하면서 비즈니스를 배웠고, 무언가를 만든다는 일이 만드는 행위만으로 끝나지 않는다는 사실을 그때 알았다. 사람들이 원하는 것이 무엇인지 알아야 했고, 시장이 어디로 움직이는지 읽어야 했으며, 어떤 제품은 살아남고 어떤 제품은 사라지는 이유까지 이해해야 했다. 회사에 들어간 뒤로 그 감각은 한결 정교해졌다. 조직 안에서 일한다는 것은 좋은 아이디어를 내는 일이 아니라, 우선순위를 정하고 자원을 배분하고 사람을 설득하고 숫자로 증명하는 일이었고, 나는 그런 방식으로 조금씩 성장해갔다. 인정도 받았다. 예전보다 훨씬 비즈니스적으로 사고하게 되었고, 더 필요한 사람이 되어갔다. 나 역시 그런 성장을 원해서 회사에 들어간 것이었다. 더 배우고 싶었고, 더 넓게 보고 싶었고, 더 현실적인 사람이 되고 싶었다. 그런데 이상하게도, 많은 것을 이해하게 될수록 설명하기 어려운 감각 하나가 함께 자라났다. 분명 나는 더 잘하고 있었는데, 동시에 무언가로부터 조금씩 멀어지고 있다는 느낌이 들었다. 처음에는 그저 피로라고 생각했다. 하지만 시간이 지날수록 그것이 피로와는 다른 종류의 감각이라는 걸 알게 되었다. 이성은 지금의 방향이 맞다고 말하고 있었지만, 내면은 조용히 정말 네가 원했던 게 이것이었나 하고 되묻는다. 비즈니스는 사람들에게 필요한 것을 만들라고 말한다. 팔리는 것을 만들고, 문제를 정의하고, 시장을 분석하고, 수요를 찾아내라고 말한다. 틀린 말은 아니다. 오히려 굉장히 현실적이고 강력한 사고방식이다. 그런데 언젠가부터 나는 자꾸 반대 방향을 생각하게 되었다. 사람들이 원하는 것을 만드는 삶이 아니라 내가 정말 만들고 싶은 것을 만드는 삶, 누가 사줄지부터 고민하는 일이 아니라 그 자체로 옳다고 느껴지는 것을 만드는 일, 팔기 위해 만드는 것이 아니라 그저 만들 수밖에 없어서 만드는 것, 그리고 우연히 그걸 좋아해주는 사람들이 생기는 것. 어쩌면 그쪽이 내가 원하던 자리였는지도 모른다. 어쩌면 나는 비즈니스를 잘 아는 개발자가 되고 싶은 게 아닐지도 모른다. 정확히는, 어떤 특정한 직업이 되고 싶은 게 아니다. 나는 그저 제품을 만드는 사람이 되고 싶은 것 같다. 무언가를 더 낫게 다듬고, 형태를 잡고, 사용성을 고민하고, 작은 디테일까지 신경 쓰면서, 스스로 아름답다고 느끼는 무언가를 끝까지 완성해내는 사람. 세상은 효율을 말하지만, 나는 점점 효율만으로 설명되지 않는 것들에 끌린다. 왜 어떤 제품은 손에 쥐는 순간 만든 사람의 마음이 전해지는지, 왜 어떤 물건은 기능 이상으로 사람을 움직이는지, 왜 어떤 경험은 사용자를 단순한 고객이 아니라 팬으로 만드는지. 그런 것들은 좀처럼 숫자로 설명되지 않고, 오히려 누군가의 집요함, 취향, 고집, 애정 같은 것에서 시작된다. 그래서 가끔은 두려워진다. 나는 사회적으로 점점 더 올바른 방향으로 가고 있는데, 그 과정에서 정작 내가 사랑했던 감각을 잃어가고 있는 건 아닐까 하는 생각이 든다. 나답게 산다는 건 생각보다 어려운 일이다. 많은 것을 포기해야 할지도 모르고, 남들 눈에는 비효율적인 길처럼 보일 수도 있으며, 더 빠른 길을 두고 굳이 돌아가는 선택처럼 보일 수도 있다. 하지만 이상하게도, 마음 한구석에서는 자꾸 시장에 가장 적합한 사람이 되는 것보다, 내가 진심으로 만들고 싶었던 것을 만드는 사람으로 남는 삶을, 그런 삶을 동경하게 된다. 나답게 산다는건 모호하고, 무엇인지 모르겠고, 그리고 어렵다.

오픈코드를 핸드폰에서 사용해봅시다.

2026-05-24T03:02:57+09:00

텀블러가 코드 관련 기능이 없어져서 ㅠㅠㅠ
티스토리에 쓰게됨.

Open Code의 웹 UI 기능을 사용해 집컴에 연결해봤다.

이제 왔다갔다 하면서 딸깍 코딩이 가능해졌음.

그래서 어떻게 했나?

데스크톱 설정

나는 EndeavourOS를 사용한다.

프로그램 설치

먼저 필요한 것들을 설치하자.

yay -S opencode-bin tailscale tmux mosh caddy

opencode를 연결해야 하니까
tailscale의 메시 VPN 으로 쉽게 보안을 달성하자
tmux로 세션이 계속 살아있도록 하자
mosh로 모바일에서 shell에 접속이 필요하면 안정적으로 하자
caddy로 https 연결을 지원하도록 리버스 프록시 하자

테일스케일 설정

먼저 tailscale을 설정한다.

# 테일스케일 활성화
sudo systemctl enable --now tailscaled
sudo tailscale up

# SSH 설정
sudo systemctl enable --now sshd

# 방화벽 설정
sudo firewall-cmd --permanent --zone=trusted --add-interface=tailscale0
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

이제 Tailscale 정보를 확인하고 사용할 수 있을 것이다.

Addresses, Machine 정보를 확인가능하다. (뒤에서 사용할 예정)

tailscale status

Tailscale HTTPS 설정

나는 HTTPS 를 사용할거니 추가설정을 해준다.

어드민에서 HTTPS 도 활성화 해주자.

이때 이 DNS 이름을 잘 기억해야 함.

인증서를 발급받기 위해 cert를 실행한다.
MACHINE NAME은 앞서 status에서 볼 수 있고, DNS이름은 .ts.net 가 뒤에 붙은 것이다.

sudo tailscale cert ${MACHINE_NAME}.${TAILSCALE_DNS_NAME}

HTTPS 를 위한 리버스 프록시

opencode는 호스트로 https를 지원하지 않으니 리버스 프록시를 사용하자.

나는 간단하게 설정하기 위해 caddy를 사용했다.

# caddy 시작
sudo systemctl enable --now caddy

# 인증서 권한 설정
sudo chown root:caddy /var/lib/tailscale
sudo chown root:caddy /var/lib/tailscale/certs
sudo chmod 750 /var/lib/tailscale
sudo chmod 750 /var/lib/tailscale/certs

# 인증서 이름들 확인 (보통 ${TAILSCALE_DNS_NAME}.crt + ${TAILSCALE_DNS_NAME}.key 형태)
sudo ls /var/lib/tailscale/certs

# 설정 편집
sudo nano /etc/caddy/Caddyfile

이제 설정하자. Address는 앞의 tailscale status 로 확인가능하다.

${TAILSCALE_DNS_NAME} {
    # opencode가 4096 포트를 사용함
    reverse_proxy ${TAILSCALE_ADDRESS}:4096

    tls ${TAILSCALE_DNS_NAME}.crt ${TAILSCALE_DNS_NAME}.key
}

다시 시작하여 적용한다.

sudo caddy fmt --overwrite /etc/caddy/Caddyfile
sudo systemctl restart caddy

컴퓨터 설정은 끝났다.

핸드폰 설정

Termux를 설치한다.

그리고 Tailscale 앱도 설치하여 로그인한다.

패키지 업데이트 및 설치

당연하지만 패키지는 설치해야 한다.

pkg update
pkg upgrade
pkg install openssh mosh

SSH 설정

귀찮게 비번 맨날 치기 싫다면 SSH 키 설정하자.

ssh-keygen -t ed25519
# 엔터 3번 누르면 됨

ssh-copy-id ${MACHINE}@${TAILSCALE_ADDRESS}

웹으로 연결해주는 스크립트

이제 처음 사진처럼 바로 연결하도록 만들자.

mkdir ~/.termux
nano ~/.termux/connect.sh

스크립트는 이렇게 작성하면 된다.

#!/bin/bash
SERVER="${MACHINE}@${TAILSCALE_ADDRESS}"
TAILSCALE_IP="${TAILSCALE_ADDRESS}"
TAILSCALE_HOST="${TAILSCALE_DNS_NAME}"
LOG="/tmp/opencode.log"

# 1. tmux 세션 확인 및 생성
echo "  tmux 세션 확인 중..."
ssh $SERVER \
  "tmux has-session -t main 2>/dev/null || tmux new-session -d -s main"

# 2. opencode 시작 (Caddy가 HTTPS 처리하므로 HTTP로만) 
echo "  opencode serve 시작..."
ssh $SERVER \
  "tmux new-window -t main -n opencode \
  'opencode serve --hostname $TAILSCALE_IP 2>&1 | tee $LOG'"

# 3. 포트 감지
echo "  포트 감지 중..."
PORT=""
for i in $(seq 1 30); do
  PORT=$(ssh $SERVER \
    "grep -oP '(?<=http://$TAILSCALE_IP:)\d+' $LOG 2>/dev/null")
  [ -n "$PORT" ] && break
  sleep 0.5
done

if [ -z "$PORT" ]; then
  echo "❌ 포트 감지 실패"
  exit 1
fi

# 4. URL 출력 + mosh 접속
echo "✅ http://$TAILSCALE_IP:$PORT 접속 가능!"
echo "✅ https://$TAILSCALE_HOST 로 접속"
termux-open-url "https://$TAILSCALE_HOST"
mosh $SERVER -- tmux new-session -A -s main

기타 편의성 스크립트 작성

이제 실행권한을 주고 편의성을 위해 스크립트를 작성하자.

chomod +x ~/.termux/connect.sh
nano ~/.bashrc

이렇게 작성한다.

function tmux-mosh() {
  mosh "$1" -- tmux new-session -A -s main
}

alias host-shell="tmux-mosh ${MACHINE}@${TAILSCALE_ADDRESS}"
alias opencode="~/.termux/connect.sh"

스크립트 로드하고 무지성 포터블 코딩 즐깁시다. 끝.

source ~/.bashrc

[리뷰] 세븐 킹덤의 기사 (스포주의)

2026-05-25T22:00:01+09:00

간만에 집중해서 봤던 미드. 하지만 이제 좀 재미있어 지려니 끝나 버려서 다소 황당했던 미드.

기본적으로는 왕좌의 게임 프리퀄이다. 왕좌의 게임 전 시대를 다룬 시리즈. 떠돌이 기사, 던크가 마상 시합에 출전 하면서 겪게 되는 사건을 그리고 있다. 뭐 여러가지가 인상적이지만 그 중에서도 가장 인상적인 장면을 꼽으라면 당연 7인의 결투 마지막 멤버로 베일러 타르가르엔 왕자가 합류하는 거 아닐까 싶다.

대략적인 스토리는 떠돌이 기사가 마상 시합에 참여하면서 겪게 되는 일을 그리고 있다. 떠돌이 가사 던크가 스승이 죽고 여차저차해서 겨우 마상 시합에 들어갈 수 있게 됐는데, 호감을 가지고 있던 연극패 여자를, 드래곤 이미지를 더렵혔다는 이유로 망나니 타르가르엔 왕손이 깽판치는 걸 제압하면서 인생이 험난해지는 과정을 보여준다. 실제로는 바로 재판으로 나락행으로 가야 하지만 그걸 결투 재판으로 뒤집고, 그걸 또 다시 왕손이 7v7로 확장 하면서 결투가 벌어지는 뭐 그런 스토리. 하지만 떠돌이 기사쪽 7인 중에 한명이 배신하면서 6인이 되서 시작이 안되는 상황. 사람이 모자르면 자동으로 패하고, 패하면 그냥 골로 가야하는 절체절명의 순간 왕좌의 게임 메인 타이틀이 흐르면서 베일러 왕자가 등장한다. 뚜둥. 이때 좀 존멋. 왕좌의 게임 메인 타이틀 곡도 웅장하게 분위기를 업시켜준다.

예나 지금이나 없이 사는 사람들은 참 세상 난이도가 높다. 실력이 있어 보임에도 출전 자체도 쉽지 않고, 출전을 해도 모든 걸 걸어야만 겨우 가능하다. 심지어 불의를 못참고 바로잡으려 할때에는 목숨을 걸어야 한다. 많이 바꼈다 생각하지만 요즘도 별 차이는 없다는 게 내 느낌. 그러니 흐린 눈으로 무심하게 사는 게 안전한 길인지도 모르겠다.

하우스 오브 드래곤은 보다가 몰입이 안되서 말았는데 세븐 킹덤의 기사는 아주 재미있게 봤다. 시즌2가 어여 빨리 나오기를~

[일상] 마인크래프트 던전스와 자전거

2026-05-25T00:00:01+09:00

자전거 타는 따님

어릴 때에는 애들이 자라면 함께 게임을 하면 참 좋겠다라는 생각을 했었다. 하지만 막상 애들이 크니 내가 더 이상 게임을 좋아하는 사람이 아니게 돼 버렸다. 이런 걸 보면 인생은 참 기묘하다. 무튼 최근 애들은 로블록스가 최애, 다음이 마인크래프트 던전스를 한다. 토욜에 둘째가 졸라서 탑을 한 판 했었다. 30층을 깨고 싶었지만 패드는 익숙하지 않았고, 아드님의 잔소리는 너무 힘들었다. 결국 대충대충하다 29층에서 종말을 맞았다. 일욜, 또 따님이 한판 하쟤서 동생이랑 하랬더니 아빠랑 하고 싶다고 졸라데서 탑을 또 돌았다. 딸이랑 하면 내가 키마로 해서 훨씬 편했다. 그덕에 또 30층을 깼다. 둘 다 신나서 좋아한다. 이게 뭐라고?!

게임을 한 판 하고 나서 날이 좋아 놀이터를 나갔다. 둘째가 배드민턴 치고 싶데서 채를 챙겨나가는데 큰 애가 자전거 배웠다고 자전거를 타 볼 수 있냐고 물었다. 그래서 내가 타던 미니벨로 안장을 낮춰서 함께 들고 나갔다. 배드민턴 좀 치다 동네 꼬마들이 몰려 들어서 애들끼리 치라고 오토 돌려 놓고는 나는 핸폰 삼매경에 다시 빠져들었다. 첫째가 처음에는 애들 타는 자전거가 아니라 어색하다고 하더니 금새 익숙해져서 잘 타는 게 보였다. 허우적대던 녀석이 수영장에서 나보다 수영을 잘하고, 자전거를 알려주지 않았는데도 잘 타는 걸 보면서 새삼 신기하다는 생각이 들었다.

내 인생의 좋은 시절이 흘러 가고 있다. 세월은 흐른다. 이렇게든, 저렇게든. 그러니 조금 더 명랑하게 살도록 노력해야겠다.