Intro: AI 시대에도 여전히 Clean Code가 중요한 이유 요즘 “코딩은 AI가 다 해준다"고 홍보하는 툴들이 쏟아지고 있습니다. 저도 이것저것 써봤는데, 한 가지 분명한 패턴이 보이더군요. AI는 일종의 ‘진공 상태’에서 코드를 짭니다. 당장 파일 몇 개만 건너뛰어도 마주하게 되는 우리 프로젝트의 지저분한 현실이나 복잡한 맥락은 전혀 고려하지 못하죠. AI가 코드를 뱉어내는 속도가 빠를수록, 주의를 기울이지 않으면 제 코드베이스가 순식간에 악몽으로 변할 수 있겠다는 생각이 들었습니다. 그래서 다시 기본으로 돌아가 봤습니다. 애초에 우리가 왜 Clean Code를 부르짖기 시작했을까요? ChatGPT가 나오기 훨씬 전, ‘엉클 밥’으로 불리는 로버트 C. 마틴은 그의 책에서 이렇게 말했습니다. ...
AI 자동화가 정작 현장까지 닿지 못하는 이유 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인 것을 확인합니다. 데이터베이스가 잔액을 업데이트하기 전에 요청들이 겹치기 때문에, 세 서비스 모두 트랜잭션을 “안전하다"고 검증합니다. ...
들어가며 CPU는 NVMe 드라이브, 네트워크 카드, 혹은 GPU와 어떻게 대화를 나눌까요? 대부분의 소프트웨어 엔지니어는 드라이버나 커널 모듈이 알아서 해주겠거니 믿고, 그 밑바닥 메커니즘까지는 깊게 생각하지 않습니다. 하지만 성능 이슈를 디버깅하거나, 인터럽트 처리를 튜닝하거나, perf가 가리키는 병목 현상의 원인을 파악하려면 하드웨어 레벨에서 무슨 일이 벌어지는지 반드시 알아야 합니다. x86 시스템은 CPU와 주변 장치 간 통신을 위해 크게 세 가지 메커니즘을 사용합니다: Port-mapped I/O (PMIO): CPU가 별도의 I/O 명령어를 사용해 독립된 주소 공간에 접근합니다. Memory-mapped I/O (MMIO): 주변 장치가 자신의 제어 레지스터를 메모리 주소처럼 노출합니다. Direct Memory Access (DMA): 주변 장치가 CPU의 개입 없이 RAM과 데이터를 직접 주고받습니다. NVMe 드라이브, 네트워크 카드, GPU 같은 현대적인 PCIe 장치들은 거의 전적으로 MMIO와 DMA를 사용합니다. PMIO는 구형 ISA 장치나 하위 호환성 모드에서나 볼 수 있는 유물이죠. 이 메커니즘들을 이해하면 시스템의 동작을 해석하는 눈이 생깁니다. 왜 DMA 버퍼 크기가 처리량(Throughput)에 영향을 주는지, 왜 인터럽트 조절(Moderation)이 레이턴시에 중요한지, 그리고 irqaffinity 같은 커널 파라미터가 실제로 무엇을 제어하는지 알게 되니까요. ...
PostgreSQL 통계의 사각지대를 드러낸 고객 클레임 모든 일은 고객의 클레임 한 건에서 시작되었습니다. 워크플로우의 핵심 부분이 응답하지 않는다는 내용이었죠. 로그를 까보니 병목 구간은 평소라면 아무 문제 없었을 평범한 쿼리였는데, 이 녀석이 갑자기 타임아웃을 내고 있었습니다. 원인을 파악하기 위해 우리는 PostgreSQL 쿼리 플래너(Query Planner)의 내부를 깊숙이 파고들어야 했습니다. 그리고 그곳에서 특정 데이터 분포 패턴이 통계 추정(statistics estimation)의 희귀한 버그를 건드리고 있다는 사실을 발견했습니다. 이 글은 그 해결 과정을 기록한 문서입니다. 내용이 다소 긴 이유는 버그 자체가 미묘하기도 하거니와, 왜 이런 일이 발생하는지 이해하려면 PostgreSQL 옵티마이저가 의사결정을 내리는 과정을 따라가 봐야 하기 때문입니다. 이유 없이 쿼리 실행 계획(Query Plan)이 꼬이는 걸 본 적이 있거나, 해시 조인(Hash Join)이 분명 유리해 보이는데 왜 PostgreSQL이 굳이 중첩 루프(Nested Loop)를 선택하는지 궁금했다면, 이 글이 도움이 될 겁니다. ...