Posts

에이전트가 같은 말을 반복하기 시작했을 때 처음에는 요청이 먹통이 된 줄 알았습니다. 툴 콜(tool call)이 나와야 할 자리에 모델이 max_tokens 제한까지 줄기차게 같은 문장만 반복하거나, 툴 콜에 필요한 JSON 형식을 끝내 완성하지 못한 채 의미 없는 잡담만 늘어놓고 있었거든요. 어느 쪽이든 토큰 예산만 낭비하고 가끔은 타임아웃까지 발생하며 에이전트 루프 전체를 말아먹기 일쑤였습니다. 당시 저는 B2B로 납품하는 비즈니스 인텔리전스(BI) AI를 만들고, 그 위에 에이전트를 얹는 일을 하고 있었습니다. 고객사 데이터가 외부로 나갈 수 없어서 클라우드 API는 쓸 수가 없었습니다. OpenAI도 Anthropic도 안 됐죠. 모델을 우리 하드웨어에 직접 띄워 서빙하거나, 아니면 기능을 포기하거나, 둘 중 하나였습니다. 이렇게 직접 서빙하면 클라우드 API가 알아서 처리해 주던 양자화(quantization), 서빙 프레임워크, 추측 디코딩(speculative decoding)을 전부 손수 다뤄야 합니다. 설정값 하나하나가 다 제 몫이고, 그만큼 제가 망가뜨릴 여지도 컸습니다. ...

악화가 양화를 구축한다: 콘텐츠 범람 시대의 그레샴의 법칙 콘텐츠 시장은 형편없는 정보로 넘쳐나고 있습니다. 검증되지 않은 거짓이 사실인 양 유통되고, 가치 없는 대량 생산 쓰레기들이 모든 피드를 뒤덮고 있죠. 원작자의 노력은 헛되이 도용되어 원본보다 더 멀리 퍼져나가고, 분노와 자극적인 어그로가 사람들의 주의력을 진공청소기처럼 빨아들이는 실정입니다. 보통 이런 상황이 오면 “깊이 있는 콘텐츠의 시대는 끝났다"며 한탄하기 마련입니다. 하지만 저는 정반대로 생각합니다. 좋은 콘텐츠가 사라지고 있는 게 아니거든요. 그저 나쁜 콘텐츠라는 산더미 아래 묻혀서 안 보일 뿐입니다. ‘묻힌 것’과 ‘사라진 것’은 엄연히 다르니까요. ...

LLM: 우리가 놓치고 있었던 것들 “지금 Temperature 값을 몇으로 쓰고 계신가요?” 누군가 이렇게 물어보면 뭐라고 답하시나요? “기본값요”, “0.7이요”, 아니면 “글쎄요, 그게 중요한가요?” 보통 이 세 가지 답변 중 하나일 겁니다. 그리고 왜 그 값을 쓰는지 정당화하려 하면 금세 말문이 막히곤 하죠. 우리는 지금 LLM을 딱 이 정도로 사용하고 있습니다. 매일 API를 호출하고, 프롬프트를 messages에 담아 보내고, 응답을 받아오죠. 하지만 “Temperature는 실제로 어떤 역할을 하지?”, “Top-P는 Temperature랑 뭐가 다른 거지?”, “Prompt Caching은 켜기만 하면 알아서 작동하나?”, “모델을 더 좋은 걸로 바꾸면 환각(hallucination) 현상이 사라질까?” 같은 질문이 나오면 답변이 모호해집니다. ...

Intro: AI 시대에도 여전히 Clean Code가 중요한 이유 요즘 “코딩은 AI가 다 해준다"고 홍보하는 툴들이 쏟아지고 있습니다. 저도 이것저것 써봤는데, 한 가지 분명한 패턴이 보이더군요. AI는 일종의 ‘진공 상태’에서 코드를 짭니다. 당장 파일 몇 개만 건너뛰어도 마주하게 되는 우리 프로젝트의 지저분한 현실이나 복잡한 맥락은 전혀 고려하지 못하죠. AI가 코드를 뱉어내는 속도가 빠를수록, 주의를 기울이지 않으면 제 코드베이스가 순식간에 악몽으로 변할 수 있겠다는 생각이 들었습니다. 그래서 다시 기본으로 돌아가 봤습니다. 애초에 우리가 왜 Clean Code를 부르짖기 시작했을까요? ChatGPT가 나오기 훨씬 전, ‘엉클 밥’으로 불리는 로버트 C. 마틴은 그의 책에서 이렇게 말했습니다. ...

인공지능이 정작 현장까지 닿지 못하는 이유 AI 자동화 소프트웨어는 무서운 속도로 쏟아져 나오고 있지만, 막상 SW 개발 분야를 제외한 다른 산업군에서는 이런 변화를 체감하기 어렵습니다. 제조업이나 전통적인 비즈니스 영역에 계신 분들과 이야기를 나눠보니 패턴이 뚜렷하게 보이더군요. AI의 역량과 실제 도입 사이에는 엄청난 괴리가 존재합니다. 그 이유는 크게 세 가지 핵심 문제로 정리할 수 있습니다. Digital Transformation이 먼저입니다 경영진은 AI 전환(AX)에 열광하지만, 정작 기본적인 디지털 전환(DX)조차 마무리되지 않은 조직이 태반입니다. AI는 데이터를 먹고 자랍니다. 만약 비즈니스 프로세스가 종이 문서나 담당자의 머릿속, 혹은 서로 단절된 사일로 안에만 존재한다면 AI가 비즈니스를 도울 방법은 없습니다. ...

Intro AI가 정말 무서운 속도로 발전하고 있죠. 아마 다들 이런 걱정 한 번쯤 해보셨을 겁니다. “개발자로서 내 밥그릇은 안전할까? 결국 인간은 쓸모없어지는 걸까?” 저 역시 같은 고민으로 꽤나 머리를 싸맸거든요. 그 과정에서 정리한 제 생각들을 공유해 볼까 합니다. 이 글이 여러분께 작은 위안이 되고, 앞으로 나아갈 방향을 잡는 데 도움이 되었으면 좋겠습니다. 정말 중요한 건 따로 있습니다 역사적으로 수많은 노이즈 속에서 가치 있는 인사이트를 뽑아내는 능력은 언제나 핵심 스킬이었습니다. 동시에 가장 마스터하기 어려운 영역이기도 했죠. 기술이 말도 안 되는 속도로 발전하고 있는 건 맞습니다. 하지만 간과하지 말아야 할 사실이 하나 있습니다. 인류는 언제나 저수준의 정보를 고수준의 지식으로 변환하기 위해 도구를 만들어왔다는 점입니다. 계산기, 컴퓨터, 데이터베이스, 스프레드시트… 예시는 끝도 없습니다. ...

엔지니어링은 트레이드오프의 예술입니다 본론으로 들어가기에 앞서 미리 말씀드리자면, 제 경력이 아주 긴 편은 아닙니다. 기술을 바라보는 관점은 여전히 성장 중이며, 생각이 성숙하지 못할 수 있습니다. 하지만 현업에서 여러 문제를 마주하며 깨달은 확실한 진리 하나는 있습니다. 바로 소프트웨어 엔지니어링에 ‘완벽한 정답’은 없다는 사실입니다. 트레이드오프: 제로섬 게임, 그 이상 흔히 엔지니어링에서 트레이드오프(Trade-off)라고 하면 단순한 기회비용 정도로만 생각하곤 합니다. 성능을 위해 유지보수성을 희생한다거나, 당장의 개발 속도를 챙기느라 장기적인 확장성을 포기하는 식으로 말이죠. 하지만 경험 많은 엔지니어들은 이 문제를 단순히 제로섬 게임으로 보지 않습니다. 오히려 더 정교한 설계를 통해 희생을 최소화할 수 있는 최적의 지점을 찾아냅니다. 진짜 실력은 “무엇을 포기할까?“를 묻는 게 아니라, “나중에 우리가 충분히 감당할 수 있는 부채(Debt)는 무엇인가?” 를 판단하고 그 위에서 설계하는 데서 나옵니다. ...

Intro: 이중 지불 문제 E-commerce 플랫폼을 개발하다 보면 흔히 마주치는 문제가 있습니다. 예를 들어, 환불 로직이 고객, 판매자, 또는 자동화된 사기 탐지 시스템에 의해 동시에 트리거될 수 있습니다. 분산 시스템 내에서 적절한 메커니즘이 없으면 동일한 주문이 여러 번 환불됩니다. 실제 시나리오를 생각해 봅시다. 총액 $200짜리 주문에 대해 1초 안에 세 개의 부분 환불 요청($200씩)이 동시에 들어옵니다. 고객이 앱을 통해 파손된 상품에 대한 $200 환불을 요청합니다. 판매자가 배송 지연에 대한 사과로 $200 환불을 시작합니다. 로열티 시스템이 프로모션 가격 매칭 보장의 일환으로 자동으로 $200 환불을 트리거합니다. 세 개의 독립적인 마이크로서비스가 이 요청들을 동시에 처리합니다. 각 서비스는 데이터베이스에서 주문 상태를 읽고, “남은 환불 가능 금액"이 $200인 것을 확인합니다. 데이터베이스가 잔액을 업데이트하기 전에 요청들이 겹치기 때문에, 세 서비스 모두 트랜잭션을 “안전하다"고 검증합니다. ...

서론 동일한 GPU 두 개를 같은 장비에 꽂고 똑같은 워크로드를 돌려보면, 종종 두 번째 GPU가 뒤처지는 현상을 보게 됩니다. 모델도 같고 드라이버도 같으며 데이터마저 동일한데 처리량(throughput)은 다르게 나타나는 것이죠. 발열 문제도 아니고 BIOS 프로파일 설정이 잘못된 것도 아닙니다. 사실 두 번째 GPU는 버스 수준에서 자원을 제대로 공급받지 못하고 있는 상태인데, 그 원인은 GPU 카드 자체가 아닌 다른 곳에 있습니다. 우리 대부분은 드라이버나 커널 모듈 위에서 작업하기 때문에 x86 시스템이 CPU, RAM, 그리고 PCIe 장치 간에 데이터를 실제로 어떻게 이동시키는지 들여다볼 일이 거의 없습니다. 하지만 처리량 비대칭 문제를 디버깅하거나, 인터럽트 선호도(interrupt affinity)를 튜닝하거나, 도대체 왜 irqaffinity가 중요한지 의문이 들기 시작하는 순간, 하드웨어 토폴로지는 더 이상 추상적인 개념으로 머물지 않게 됩니다. ...

PostgreSQL 통계의 사각지대를 드러낸 고객 클레임 모든 일은 고객의 클레임 한 건에서 시작되었습니다. 워크플로우의 핵심 부분이 응답하지 않는다는 내용이었죠. 로그를 까보니 병목 구간은 평소라면 아무 문제 없었을 평범한 쿼리였는데, 이 녀석이 갑자기 타임아웃을 내고 있었습니다. 원인을 파악하기 위해 우리는 PostgreSQL 쿼리 플래너(Query Planner)의 내부를 깊숙이 파고들어야 했습니다. 그리고 그곳에서 특정 데이터 분포 패턴이 통계 추정(statistics estimation)의 희귀한 버그를 건드리고 있다는 사실을 발견했습니다. 이 글은 그 해결 과정을 기록한 문서입니다. 내용이 다소 긴 이유는 버그 자체가 미묘하기도 하거니와, 왜 이런 일이 발생하는지 이해하려면 PostgreSQL 옵티마이저가 의사결정을 내리는 과정을 따라가 봐야 하기 때문입니다. 이유 없이 쿼리 실행 계획(Query Plan)이 꼬이는 걸 본 적이 있거나, 해시 조인(Hash Join)이 분명 유리해 보이는데 왜 PostgreSQL이 굳이 중첩 루프(Nested Loop)를 선택하는지 궁금했다면, 이 글이 도움이 될 겁니다. ...