Backend

API는 계약이다, 그런데 우리는 왜 매번 같은 실수를 반복할까 "/v1/users"를 만들고, 에러가 나면 { error: "메시지" } 를 대충 반환하고, 나중에 필드 하나를 지웠다가 모바일 클라이언트가 크래시 나는 경험. 이건 특정 팀만의 문제가 아닙니다.

통합 테스트만으로는 배포 타이밍을 막기 어렵다 프론트엔드와 백엔드가 독립적으로 배포되는 팀에서는 API 변경이 가장 흔한 장애 원인 중 하나입니다.

@Transactional은 왜 예상대로 작동하지 않는가 Spring을 처음 배울 때 @Transactional 은 마법처럼 보입니다. 메서드 위에 어노테이션 하나를 붙이면 DB 작업이 원자적으로 묶인다고 배우고, 실제로 기본 케이스에서는 그렇게 동작합니다.

스키마 계약 없이 Kafka를 운영하면 어떤 일이 생기는가 이벤트 기반 파이프라인에서 Producer와 Consumer는 서로 다른 팀이 관리하는 경우가 대부분입니다.

메시지가 사라진 순간, 브로커를 탓하기 전에 설계를 봐야 한다 결제 완료 이벤트를 발행했는데 알림이 가지 않고, 재고 차감도 되지 않으며, 고객은 결제 화면에서 로딩만 보는 상황을 경험한 적이 있을 것입니다.

비동기 Python, 제대로 쓰지 않으면 오히려 더 느리다 FastAPI는 현재 Python 백엔드 생태계에서 가장 빠르게 채택되는 웹 프레임워크입니다. async def 를 라우트 핸들러에 붙이면 비동기 API가 완성된다는 인상이 있지만, 실제 프로덕션 환경에서는 그렇지 않습니다.

내부 서비스 통신을 바꾼다는 것의 실제 무게 이 시점에, 대부분의 백엔드 팀은 서비스 간 통신을 JSON over HTTP/1.1 REST로 운영합니다. 빠르게 검증하고 배포하기에는 이보다 편한 선택이 없습니다.

페이지네이션은 목록을 자르는 문제가 아니다 목록 API를 만들 때 page와 size만 받으면 충분해 보입니다. 데이터가 적을 때는 offset 기반 페이지네이션이 단순하고 편합니다. 하지만 데이터가 늘고, 사용자가 무한 스크롤을 하고, 목록 중간에 새 데이터가 계속 들어오면 문제가 드러납니다.

Node.js가 느린 것이 아니라 이벤트 루프가 막힌다 Node.js는 I/O 중심 서비스에 강합니다. 하지만 이미지 리사이징, CSV 파싱, 암호화, 대용량 JSON 변환, 리포트 생성처럼 CPU를 오래 쓰는 작업을 요청 처리 경로에서 실행하면 이벤트 루프가 막힙니다. 한 요청의 무거운 계산이 다른 모든 요청의 응답 지연으로 번집니다.

GraphQL은 느린 것이 아니라 쉽게 느려진다 GraphQL을 처음 도입하면 프론트엔드 개발 속도가 빨라집니다. 필요한 필드만 요청하고, 여러 REST API를 조합하지 않아도 되고, 화면 단위 데이터 요구사항을 스키마로 표현할 수 있습니다. 문제는 서비스가 커진 뒤에 나타납니다.

Lag는 숫자가 아니라 사용자 지연이다 Kafka를 쓰는 시스템에서 consumer lag는 가장 먼저 보는 지표입니다. 하지만 lag를 단순히 "남은 메시지 수"로만 보면 중요한 맥락을 놓칩니다. 10만 건의 lag가 있어도 초당 5만 건을 처리한다면 곧 회복됩니다.

장애는 실패한 API 하나에서 끝나지 않는다 마이크로서비스 환경에서 장애는 거의 항상 전파됩니다. 결제 서비스의 응답이 느려졌을 뿐인데 주문 API의 스레드가 대기하고, 주문 API가 느려지자 게이트웨이의 커넥션이 쌓이고, 결국 로그인이나 상품 조회처럼 결제와 직접 관련 없는 API까지 함께 느려집니다.

Node.js 베테랑이 Rust로 백엔드를 옮기며 깨진 가정 7가지 저희 백엔드 팀은 5년 동안 Node.js + TypeScript 위에서 트래픽을 견뎌왔습니다.

모던 백엔드 개발에서 고도로 확장 가능하고 유연한 시스템을 구축하기 위한 핵심 패러다임이 이벤트 기반 아키텍처(Event-Driven Architecture, EDA) 입니다.