ioh's Development

한빛미디어 서평단 활동을 위해서 책을 협찬 받아 작성된 서평입니다.AI가 글을 다 써주는 시대에도 개발자에게 글쓰기 능력이 필요할까?『AI도 모르는 글쓰기』를 읽고도서명: 『AI도 모르는 글쓰기』저자: 정나래출판사: 한빛미디어도서 정보: 『AI도 모르는 글쓰기』 한빛미디어 도서 페이지AI에게 업무 메일이나 공지문을 작성해 달라고 요청하면 몇 초 만에 그럴듯한 글이 나온다. 기술 블로그의 목차를 정리하거나 문장을 다듬는 일도 이전보다 훨씬 쉬워졌다.그렇다면 AI가 글을 대신 써주는 시대에도 글쓰기 능력이 필요할까?『AI도 모르는 글쓰기』는 AI 시대에 글쓰기의 필요성이 사라진 것이 아니라, 사람에게 요구되는 역할이 달라졌다고 설명한다. AI가 초안을 만드는 속도는 빨라졌지만, 무엇을 전달할지 결정하고 결..

분산 유일 ID 생성기 설계: auto_increment가 분산에서 깨지는 지점부터단일 DB의 auto_increment는 한 노드 안에서 유일성과 증가 순서를 공짜로 준다. 그런데 이 전제가 분산에서 깨진다. 이 글은 대규모 시스템 설계 스터디에서 분산 유일 ID 생성기를 다룬 기록이다. 책의 해당 챕터는 단일 DB의 한계에서 출발해 네 가지 후보를 비교하고, 트위터 스노플레이크의 64비트 절 분할을 상세히 본 뒤, 시계 역행이나 worker ID 배정 같은 실무 함정까지 다룬다. 스터디에서는 개념 정리에 더해 각 후보가 어느 요구사항에서 걸리는지를 발표로 검증하고, 백엔드 개발자 관점에서 이 ID가 DB 인덱스·이벤트 설계·배포 환경과 맞물리는 지점까지 파고들었다. 이 글은 그 전개와 토론, 딥다이브..

Anthropic Messages API와 Claude Code를 기준으로 승인 게이트, 컨텍스트 비용, 프롬프트 캐시의 실제 구현을 살펴본다 개관에서는 하네스를 다섯 층으로 나눠 진단 프레임을 잡았다. 층이 있다는 사실과, 그 층이 HTTP 요청 하나하나로 실제로 어떻게 구현되는지는 다른 이야기다. 이 글은 후자다. 승인 게이트가 실행 경로의 어느 지점에 물리적으로 존재하는지, 컨텍스트 비용이 왜 제곱으로 붙는지, 캐시가 어떻게 조용히 깨지는지를 본다.먼저 범위를 못 박아 둔다. 이 글은 Anthropic Messages API와 Claude Code를 기준으로 썼다. 메시지 역할, 종료 사유(stop_reason), 캐시 무효화 조건, 권한과 훅 필드는 그 구현에 해당한다. 다른 벤더에도 비슷한 통제..

모델을 더 똑똑하게 만드는 대신, 모델이 틀릴 수 있는 표면을 구조로 좁힌다프롬프트를 고치던 습관을 버린 지점AI가 원하는 결과를 안 내놓을 때 나는 오래 프롬프트를 고쳤다. 지시를 더 명확히 쓰고, 예시를 붙이고, 하지 말라는 문장을 추가했다. 실무 세션을 몇 번 돌리고 나서 실패 로그를 다시 봤더니 원인이 프롬프트에 있던 경우가 생각보다 적었다.없는 컬럼을 참조한 건 지시가 부족해서가 아니라, 그 스키마가 애초에 컨텍스트에 없었기 때문이다.같은 실수를 세 번 반복한 건 모델이 멍청해서가 아니라, 실패 내용이 다음 시도의 입력에 안 들어갔기 때문이다.위험한 작업이 확인 없이 실행된 건 모델이 규칙을 어겨서가 아니라, 실행 통로가 그냥 열려 있었기 때문이다.셋 다 문장을 고쳐서 해결되는 문제가 아니다. ..

할루시네이션을 어떻게 시스템으로 막는가발생 자체를 없애는 것이 아니라, 불확실한 출력을 사용자에게 전달하기 전에 걸러낸다프롬프트 한 줄로는 안 된다는 걸 먼저 인정한다LLM에 "거짓말하지 마, 모르면 모른다고 해"를 붙여봤다. 그래도 지어냈다. 나는 이걸 프롬프트를 더 정교하게 쓰면 풀리는 문제로 오래 봤는데, 방향이 틀렸다. 프롬프트는 모델의 출력 경향에 영향을 줄 수 있지만, 사실성을 보장하는 장치는 아니다.그래서 질문을 바꿨다. 할루시네이션을 "모델을 더 똑똑하게 만들어 없앨 문제"로 볼 것인가, "생성물은 원래 틀릴 수 있다를 전제로 시스템이 걸러낼 문제"로 볼 것인가. 나는 후자로 정리했다. 모델 성능이 개선되면 오류 빈도가 낮아질 수 있지만, 생성 결과를 항상 사실로 보장하기는 어렵다. 그렇다..

RAG 파이프라인, 검색을 코드로 짜면서 배운 것RAG를 "LLM에 문서 검색을 붙이는 것" 정도로만 알고 있었다. 막상 파이프라인을 코드로 짜 보니, 정작 어려운 건 LLM이 아니라 검색이었다. 색인부터 평가까지 각 단계에서 무엇을 결정해야 하는지 정리한다.RAG를 다시 정의하기: 무엇을 아는가 vs 어떻게 말하는가처음엔 파인튜닝과 RAG를 같은 서랍에 넣고 있었다. 둘 다 "모델에 지식을 넣는 법"이라고 생각했다. 코드를 짜면서 경계가 분명해졌다.파인튜닝은 모델 가중치를 바꾼다. RAG는 가중치를 그대로 두고, 답을 생성하기 전에 외부 저장소에서 관련 문서를 찾아 프롬프트에 끼워 넣는다. 이번 프로젝트 목적을 기준으로 단순화하면, 최신 근거를 제공하는 문제는 RAG에, 반복되는 응답 방식과 형식을 학..

분산 유일 ID 생성기 설계: auto_increment가 분산에서 깨지는 지점부터단일 DB의 auto_increment는 한 노드 안에서 유일성과 증가 순서를 공짜로 준다. 그런데 이 전제가 분산에서 깨진다. 이 글은 대규모 시스템 설계 스터디에서 분산 유일 ID 생성기를 다룬 기록이다.책의 해당 챕터는 단일 DB의 한계에서 출발해 네 가지 후보를 비교하고, 트위터 스노플레이크의 64비트 절 분할을 상세히 본 뒤, 시계 역행이나 worker ID 배정 같은 실무 함정까지 다룬다. 스터디에서는 개념 정리에 더해 각 후보가 어느 요구사항에서 걸리는지를 발표로 검증하고, 백엔드 개발자 관점에서 이 ID가 DB 인덱스·이벤트 설계·배포 환경과 맞물리는 지점까지 파고들었다. 이 글은 그 전개와 토론, 딥다이브를..

안정 해시 설계: 서버가 늘어도 데이터를 옮기지 않는 법여러 서버에 데이터를 나눌 때 가장 단순한 방법은 hash(key) % 서버_수다. 그런데 이 방식은 서버를 한 대만 늘려도 거의 모든 데이터를 재배치한다. 안정 해시(consistent hashing)는 이 재배치 폭발을 막는 기법이다. 이 글은 대규모 시스템 설계 스터디에서 안정 해시를 다룬 기록이다.책의 해당 챕터는 일반 해시의 재배치 문제에서 출발해 해시 링, 가상 노드, 복제, 핫스팟까지 쌓아 올린다. 스터디에서는 개념을 정리하는 데서 멈추지 않고, 각 단계에서 "이게 무엇을 강제하는가"를 따지고 발표 자리에서 서로의 이해를 반론으로 검증했다. 이 글은 그 개념 전개와 토론을 함께 담는다. 핵심 흐름 한 줄 지도일반 해시 재배치 문제 → 해..

처리율 제한 장치 설계: 요구사항 네 개가 모든 결정을 강제한다처리율 제한 장치(rate limiter)는 클라이언트나 서비스가 보내는 트래픽의 양을 제어하는 장치다. 정해둔 임계치를 넘는 요청은 막고 HTTP 429를 돌려준다. 이 글은 대규모 시스템 설계 스터디에서 이 rate limiter를 설계한 기록이다.책의 해당 챕터는 배치 위치, 알고리즘 다섯 종, 저장소, 규칙 설정, 장애 대응까지 다룬다. 스터디에서는 그 내용을 읽기 전에 먼저 요구사항만으로 골격을 잡고(1차), 그다음 책 학습과 심화 분석으로 빈칸을 채웠다(2차). 이 글은 그 before/after와, 발표 자리에서 오간 반론을 함께 담는다. 한 가지 관점을 미리 못박아 둔다. 이 설계를 가른 것은 기능 요구사항이 아니라 비기능 요구..

키-값 저장소 설계: 단일 서버에서 대규모까지키-값 저장소는 key로 value를 넣고 빼는 것만 하는 데이터베이스다. Redis, Amazon DynamoDB, Cassandra가 여기 속한다. 이 글은 대규모 시스템 설계 스터디에서 이 키-값 저장소를 설계한 기록이다. 책의 해당 챕터는 단일 서버 저장소에서 출발해 파티셔닝, 복제, 정족수, 장애 처리까지 분산 저장소의 핵심 개념을 쌓아 올린다. 스터디에서는 그 개념을 읽고 정리하는 데서 멈추지 않고, 직접 설계를 그린 뒤 매주 서로의 설계를 놓고 토론하며 다듬었다. 개념을 손으로 설계해보고 다른 개발자의 반론에 답하는 과정에서 이해가 붙었다.1주차에 순수 안정 해시로 초안을 잡았고, 대규모 트래픽이라는 전제를 숫자로 못박자 그 초안이 흔들리는 걸 확..

1. AI는 개발자를 대체하기보다 개발자의 역량을 증폭한다AI가 개발 과정에 본격적으로 들어오면서 코드 작성에 필요한 비용은 빠르게 낮아지고 있다. 일부 구현 작업에서는 과거 며칠이 필요했던 결과물을 몇 시간 안에 초안 형태로 만들 수 있고, 반복 작업이나 문서 작성, 코드 분석과 테스트 코드 생성도 상당 부분 AI의 도움을 받을 수 있게 되었다.그러나 코드를 빠르게 만드는 것과 좋은 제품을 만드는 것은 같은 문제가 아니다.무엇을 만들어야 하는지 발견하고, 해결할 문제를 구체화하고, 여러 대안 가운데 적절한 구조를 선택하고, 결과물이 실제 요구사항을 충족하는지 판단하는 과정은 여전히 사람의 역할이다.AI는 구현 속도를 높여주지만, 만들어야 할 방향까지 자동으로 결정해주지는 않는다. 오히려 구현 비용이 낮..