DataCook DataCook

코드는 오늘 바꿀 수 있습니다.데이터는 어제 만든 것도, 작년에 만든 것도 남아 있습니다.그래서 필드 이름을 바꾸거나 구조를 나누면 새 코드가 과거 데이터를 읽어야 하는 순간이 옵니다.스키마 버전은 그 시간을 버티기 위한 표시입니다.버전은 파일 이름이 아니라 해석 규칙입니다version: 2라고 적는 것만으로는 부족합니다.v1은 어떤 필드를 가지고, v2는 무엇이 추가됐고, v1을 v2처럼 읽을 때 어떤 기본값을 줄지 정해야 합니다.버전은 숫자가 아니라 파서와 마이그레이션 규칙까지 포함한 계약입니다.읽기 호환성을 먼저 확보합니다안전한 순서는 보통 읽기부터입니다.새 코드가 v1과 v2를 모두 읽을 수 있게 만든 뒤, 쓰기를 v2로 바꾸고, 마지막에 오래된 데이터를 천천히 옮깁니다.한 번에 전부 바꾸려 하면..

주문 하나를 만든다고 해도 실제로는 여러 테이블이 바뀝니다.주문 행을 만들고, 재고를 줄이고, 결제 기록을 남기고, 쿠폰 사용 상태를 바꿉니다.이 중 하나만 성공하고 나머지가 실패하면 데이터는 보기 좋게 깨집니다.경계 안의 작업은 운명을 같이합니다트랜잭션은 이 작업들을 하나의 운명으로 묶습니다.전부 성공하면 커밋합니다.하나라도 실패하면 롤백합니다.핵심은 SQL 문법이 아니라 경계입니다.무엇이 반드시 함께 성공해야 하는지 정하는 순간부터 트랜잭션 설계가 시작됩니다.외부 API 호출은 조심해서 넣습니다트랜잭션 안에 오래 걸리는 외부 API 호출을 넣으면 DB 락을 오래 잡을 수 있습니다.결제사 호출, 이메일 발송, 웹훅 전송은 DB 트랜잭션과 같은 방식으로 되돌릴 수 없습니다.이런 작업은 outbox 패턴이..

느린 API 앞에 캐시를 붙이면 응답이 빨라집니다.DB 부하도 줄고, 화면도 빨리 뜹니다.여기까지는 쉽습니다.진짜 문제는 원본 값이 바뀐 뒤에 시작합니다.캐시는 빠른 값이 아니라 “언제까지 믿어도 되는 값”입니다.TTL은 정답이 아니라 타협입니다TTL을 5분으로 두면 최대 5분 동안 낡은 값을 보여줄 수 있습니다.5초로 줄이면 부하는 다시 늘어납니다.그래서 TTL은 기술값이 아니라 제품 판단입니다.가격, 권한, 결제 상태처럼 틀리면 위험한 값은 짧게 두거나 명시적으로 지워야 합니다.추천 목록이나 인기 글 순위처럼 조금 늦어도 되는 값은 길게 둘 수 있습니다.무효화 경로가 없으면 캐시는 복사본이 됩니다원본이 바뀔 때 관련 캐시를 지우는 경로가 있어야 합니다.사용자 프로필이 바뀌면 프로필 캐시만 지울지, 사..

처음엔 문장을 세게 쓰면 될 줄 알았습니다.“절대 완료라고 말하지 마라.”“반드시 검증하고 넘어가라.”“실패하면 멈춰라.”이렇게 적어두면 에이전트도, 저도, 파이프라인도 조금 더 조심해질 거라고 생각했습니다.근데 실제 작업에서는 그 문장들이 생각보다 약했습니다.화면에는 PASS가 떴고, 채팅에는 “완료했습니다”가 남았고, 다음 단계는 시작됐는데 정작 확인해야 할 파일은 비어 있었습니다.그날 배운 건 단순했습니다.규칙은 읽히는 문장이 아니라, 실패할 수 있는 프로그램이어야 합니다.완료했다는 말이 너무 쉽게 나왔습니다제가 처음 믿은 건 체크리스트였습니다.목표를 만들고, 단계별 완료 기준을 적고, 마지막에 “검증 후 진행”이라고 붙였습니다.사람이 읽기엔 충분히 엄격해 보였습니다.문제는 그 엄격함이 어디에서도 ..

서버가 메시지를 초당 1,000개 만들 수 있는데 처리기는 초당 100개만 처리한다면, 처음 몇 초는 멀쩡해 보입니다.큐가 버퍼 역할을 하기 때문입니다.하지만 큐가 계속 쌓이면 메모리가 늘고, 지연이 커지고, 결국 장애는 엉뚱한 곳에서 터집니다.큐는 해결책이면서 경고등입니다큐를 넣으면 순간적인 트래픽을 흡수할 수 있습니다.하지만 큐 길이가 계속 증가한다면 그건 안정성이 아니라 빚입니다.백프레셔는 이때 생산자에게 “지금은 천천히 보내라” 또는 “더 받지 않겠다”고 말하는 장치입니다.속도 제한, 429 응답, 스트림 pause, 작업 거절이 모두 백프레셔의 표현입니다.드롭할 수 있는 일과 없는 일을 나눕니다모든 작업을 끝까지 보존하려고 하면 시스템이 먼저 죽을 수 있습니다.검색 자동완성 이벤트는 일부 버려도..

소스 파일에서는 A 다음에 B가 있습니다.그래서 사람은 자연스럽게 A가 끝난 뒤 B가 실행된다고 생각합니다.문제는 실제 서버가 여러 요청을 동시에 받는다는 점입니다.두 요청이 같은 값을 읽고, 각자 괜찮다고 판단한 뒤, 거의 동시에 저장하면 파일에 적힌 순서는 별 도움이 안 됩니다.읽기와 쓰기 사이가 벌어질수록 위험합니다대표적인 예는 재고 차감입니다.재고가 1개 남았습니다.요청 1이 재고를 읽고 “구매 가능”이라고 판단합니다.요청 2도 같은 값을 읽고 똑같이 판단합니다.둘 다 1을 빼서 저장하면 결과는 음수거나, 한쪽 구매가 사라집니다.버그는 계산식이 틀려서가 아니라 읽은 시점과 쓴 시점 사이에 세상이 바뀌어서 생깁니다.락보다 먼저 불변식을 봅니다해결책을 바로 락으로 시작하면 시스템이 불필요하게 무거워집..

사용자는 버튼을 한 번만 누르지 않습니다.네트워크가 느리면 다시 누르고, 브라우저가 멈춘 것 같으면 새로고침하고, 모바일 앱은 같은 요청을 재전송합니다.서버 입장에서는 “같은 의도”가 여러 번 도착합니다.멱등성은 여기서 시작합니다.같은 의도의 요청이 두 번 들어와도 결과가 두 배가 되지 않게 하는 성질입니다.멱등성 키는 요청의 이름표입니다가장 흔한 방법은 클라이언트가 요청마다 고유한 멱등성 키를 보내는 것입니다.서버는 그 키로 이미 처리한 요청인지 확인합니다.처음 온 요청이면 처리하고 결과를 저장합니다.같은 키가 다시 오면 작업을 다시 하지 않고 저장된 결과를 돌려줍니다.핵심은 “중복 요청을 막는다”가 아닙니다.중복 요청이 와도 같은 결과를 돌려주는 것입니다.POST도 멱등하게 만들 수 있습니다GET이나..

오래 걸릴 것 같은 작업이라, 저는 그걸 서브에이전트한테 맡겨두고 있었습니다.대단한 일은 아니었습니다.같은 헬퍼 함수를 부르는 자리가 코드 곳곳에 흩어져 있었는데, 그 호출부를 전부 바뀐 시그니처에 맞추는 작업.손은 단순하고 양만 많았습니다.getRows(id)를 getRows(id, opts)로 바꾸고, 새로 생긴 인자를 한 줄씩 채워 넣는 식이었습니다.한 군데면 십 초인데 그게 여기저기 흩어져 있으니, 직접 하기엔 지루하고 맡기기엔 딱 좋아 보였습니다.서브에이전트가 한 줄만 남기고 종료했습니다."백그라운드에서 작업을 진행 중입니다.끝나면 보고드리겠습니다." 터미널 커서가 한 번 깜빡이고는 프롬프트가 제게 돌아왔습니다.저는 그 문장을 '보고'로 읽었습니다.솔직히 좀 마음이 놓였습니다.알아서 돌아가고 있..