백엔드

Java API와 Python 음성 엔진은 서로 다른 프로세스이므로, 문자열 기반 내부 호출보다 protobuf 계약이 변경과 장애를 더 분명하게 만든다. voice/v1/voice.proto는 음성 합성·voice catalog·capability를 하나의 버전 경계로 묶고, Java client는 요청 deadlin…

HTTP 요청은 응답을 돌려주고 끝나지만 Kafka 작업은 나중에 처리됩니다. 이 둘을 같은 업무 payload로 억지로 묶지 않고, 별도의 correlation header를 전달하면 JSON 계약을 보존하면서 한 요청의 흐름을 따라갈 수 있습니다.

스케줄러 작업이 예외를 던지지 않았다는 사실은 성공을 뜻하지 않는다. 내부에서 오류를 잡고 None, error, 처리 수, partial을 반환하는 작업이 섞이면 관제는 정상·빈 결과·부분 실패를 구분하지 못한다.

WebRTC는 Java API가 미디어를 전달하지 않아도 브라우저 간 연결·NAT·릴레이 설정이 필요하다. 그래서 예시 서비스는 텍스트 방을 원본으로 유지하고, 음성 리뷰는 opt-in 가능한 P2P 보조 경로로만 구현한다.

공공기관·외부 사업자가 제공하는 OpenAPI 를 프론트엔드에서 직접 호출 하면 첫 화면은 빠르게 만들 수 있습니다. 그러나 운영을 며칠 굴려 보면 같은 자리에서 같은 종류의 사고가 반복됩니다 — 키 노출, 응답 코드 해석, 프로토콜 미스매치. 그래서 외부 API 는 우리쪽 BFF 한 겹 을 사이에 두는 게 거의 항상…

회원 가입 확인, 비밀번호 재설정, 일회용 인증 코드 — 서비스가 사용자에게 직접 무언가를 보내야 할 때 가장 먼저 닿는 채널이 이메일입니다. 푸시 알림과 달리 별도 권한 동의가 필요 없고, 사실상 모든 사용자가 주소를 하나씩 가지고 있기 때문입니다.

관리자 기능을 갖춘 백엔드에서 "누가 · 언제 · 무엇을 · 왜" 의 네 축을 기록하는 감사로그 (audit log) 는 단순한 관행 이상입니다. 개인정보보호법 · GDPR 같은 규정 준수, 사고 조사, 권한 오남용 방지의 실질 수단.

스키마는 어디에서 진실을 가질 것인가. ORM 모델·마이그레이션 파일·DDL SQL — 후보가 여럿입니다. 누적 마이그레이션 모델과 단일 SQL 파일 + CREATE IF NOT EXISTS 모델을 비교합니다.

TypeORM 은 한때 Node 진영의 대표적 ORM 이었고 NestJS 와 함께 널리 쓰였습니다. 새 ORM 들이 등장하면서 위치가 다소 바뀌었지만 여전히 많은 코드베이스에서 운영됩니다.

Spring 에는 두 가지 웹 스택이 공존합니다. 오래된 Spring MVC (Servlet 기반, 동기 블로킹) 와 비교적 새로운 Spring WebFlux (Reactor 기반, 비동기 논블로킹).

공개된 웹 데이터를 수집하는 작업은 기술뿐 아니라 윤리·법규에 닿습니다. 너무 자주 두드리면 상대 서버에 부담을 주고, 약관을 읽지 않으면 법적 문제로 번질 수 있습니다.

Python 웹 백엔드의 폴더 구조는 프레임워크가 강제하지 않는 만큼 팀의 합의에 맡겨집니다. 잘 정렬된 구조는 신규 인력의 온보딩 시간을 줄이고, 그렇지 않으면 같은 패턴이 여러 곳에 흩어집니다.

FastAPI 는 비교적 짧은 시간 안에 Python 웹 프레임워크의 주류로 자리 잡았습니다. 빠른 등장의 배후에는 type hint · Pydantic · async 를 일관된 한 문장으로 엮은 설계가 있습니다.

HTTP 는 본래 한 번 요청 → 한 번 응답의 모델입니다. 서버가 클라이언트에게 먼저 말 걸기 어렵습니다. 채팅·알림·라이브 업데이트 같은 자리에서는 서버가 능동적으로 데이터를 보낼 수 있어야 합니다.

하나의 저장소 안에 여러 Spring 애플리케이션을 함께 두면 공통 코드의 위치·빌드 단위·의존 방향을 정해야 합니다. Gradle 의 멀티 프로젝트 빌드는 이런 구조를 다루기 위한 표준 도구입니다.

정기 작업은 어느 백엔드든 등장합니다. 야간 집계·외부 데이터 수집·만료 토큰 정리. 작은 규모에서는 cron 이나 인프로세스 스케줄러로 충분하고, 커지면 분산 큐와 워커가 등장합니다.

HTTP API 를 짜다 보면 핸들러 본체보다 그 주변 (인증·검증·로깅·에러 변환·rate limit) 코드가 더 많아질 때가 있습니다. 이 횡단 관심사를 어디에 어떻게 두느냐가 일관성과 유지비를 가릅니다.

HTTP 위에 API 를 짤 때 가장 자주 등장하는 단어가 REST 입니다. 뜻은 Representational State Transfer 로, Roy Fielding 의 2000 년 박사 논문에서 정리됐습니다.

서버가 제공하는 HTTP API 의 모양을 기계 읽기 가능한 문서로 표현하는 표준이 있습니다. OpenAPI Specification (OAS) 입니다. 한 번 잘 적어 두면 문서 페이지·클라이언트 SDK·모킹·계약 테스트가 같은 출처에서 흘러나옵니다.