01 — 전문 분야
infrastructure
어떤 문제를 다루는가
트래픽이 몰리면 느려지고, 한 컴포넌트의 장애가 전체로 번지고, 클라우드 비용은 왜 나가는지 알 수 없는 상태. 규모가 커질수록 구조의 빚이 드러납니다.
어떻게 접근하는가
장애 전파 경로를 먼저 그리고, 격리 단위를 기준으로 구조를 나눕니다. 모든 리소스는 IaC로 코드화해 재현 가능하게 만들고, 관측 지표를 붙여 비용과 성능을 같은 화면에서 봅니다.
할 수 있는 일
backend
어떤 문제를 다루는가
기능은 계속 늘어나는데 코드는 서로 얽혀 있어, 하나를 고치면 다른 곳이 깨지는 상태. 배포가 두려워지는 순간이 설계를 다시 볼 때입니다.
어떻게 접근하는가
도메인 경계를 먼저 정의하고, 경계 사이는 명시적인 API 계약과 비동기 메시징으로만 통신하게 합니다. 팀이 서로를 기다리지 않고 배포할 수 있는 구조가 목표입니다.
할 수 있는 일
database
어떤 문제를 다루는가
특정 화면만 유독 느리고, 새벽 배치가 낮 트래픽과 충돌하고, 락 경합으로 타임아웃이 발생하는 상태. 대부분 쿼리가 아니라 접근 패턴의 문제입니다.
어떻게 접근하는가
실행 계획과 슬로우 쿼리 로그로 병목을 수치로 특정한 뒤, 인덱스·스키마·캐시 계층 순으로 개입합니다. 개선 전후를 항상 같은 지표로 비교해 보고합니다.
할 수 있는 일
apm / observability
어떤 문제를 다루는가
장애가 나면 원인을 찾는 데 시간이 더 걸리고, 느리다는 제보는 있는데 어디가 느린지 아무도 특정하지 못하는 상태. 지표가 없으면 개선했는지도 증명할 수 없습니다.
어떻게 접근하는가
요청 단위 추적과 핵심 지표를 먼저 심어 병목을 눈으로 보이게 만듭니다. 대시보드는 담당자가 볼 화면 기준으로 구성하고, 알림은 실제로 대응이 필요한 조건만 남겨 피로도를 낮춥니다.
할 수 있는 일
02 — 아키텍처
NDA로 실제 프로젝트명은 공개할 수 없어 구조만 익명화해 남겼습니다. 결과 수치는 아래 사례 섹션에 있고, 여기서는 그 구조를 고른 이유를 보여드립니다.
diagram a — write buffering
case A — traffic spike
선택지는 세 가지였습니다 — 인스턴스 증설, 커넥션 풀 확대, 큐 완충. 증설은 피크 5분을 위해 상시 비용을 키우고, 풀 확대는 압력을 DB로 넘길 뿐입니다. 접수와 처리를 분리하는 큐가 가장 작은 변경으로 가장 오래 버티는 선택이었습니다. 워커 소비 속도가 조절판이 되어, 이후 트래픽이 더 늘어도 구조는 그대로 유지됩니다.
관련 사례 보기 — 프로모션 트래픽diagram b — read / write split
Cache
hot pathRead Replica ×2
readsPrimary DB
writescase B — read path offloading
정산 배치와 목록 조회, 두 건에서 같은 판단을 했습니다. 스키마 재설계가 정석이지만 마이그레이션 리스크와 팀의 운영 부담이 개선 폭보다 컸습니다. 읽기 경로를 복제본과 캐시로 덜어내고 실행 계획 기준으로 인덱스만 재구성해도 목표 지연에 도달한다고 봤고, 실제로 그렇게 끝났습니다. 되돌릴 수 있는 변경만 쓴 것이 핵심입니다.
관련 사례 보기 — 정산 배치 · 인프라 재구성03 — 사례
의뢰는 대부분 소개로 이어져 건수가 많지는 않습니다. 회사명은 밝히기 어려워 업종과 규모만 남겼습니다.
수천만 트래픽을 가정한 구조를 3인 팀에 그대로 얹으면 반년 뒤 아무도 손대지 못하는 시스템이 됩니다. 트래픽·인력·예산을 먼저 확인하고, 그 범위에서 가장 오래 버티는 선택을 제안합니다.
주요 사례
상황
MAU 500만 규모의 커머스였습니다. 프로모션 오픈 직후 몇 분간 요청이 평시의 수십 배로 몰려 결제 타임아웃과 중복 주문이 발생했습니다. 상주 인프라 담당자가 없고, 백엔드 4명이 기능 개발과 운영을 함께 맡고 있었습니다.
개입
큐 한 단계와 멱등키로 접수와 처리를 분리하는 구조를 제안했고, 적용은 팀이 하되 PR 리뷰와 페어 작업으로 같이 했습니다. 마이크로서비스 분리나 이벤트 소싱 같은 큰 구조 변경은 제안하지 않았습니다 — 이 인원이 계속 유지보수할 수 있는 최소 변경이 우선이었습니다. 대신 큐가 밀릴 때 주문 확정이 몇 초 늦어지는 건 팀과 합의하고 받아들였습니다.
결과
다음 프로모션에서 평시 대비 약 40배의 피크를 주문 유실 없이 흡수했고, 결제 p95는 1.2초를 유지했습니다. 인스턴스 증설이나 신규 운영 컴포넌트 추가는 없었습니다.
상황
일 2,000만 건을 정산하는 시스템에서, 배치가 새벽에 끝나지 않아 낮 트래픽과 겹치고, 락 경합으로 서비스 쿼리까지 느려졌습니다. 새 시스템을 만들 예산은 없고, 기존 스키마도 유지해야 하는 조건이었습니다.
개입
전체 재계산을 증분 처리로 바꾸고 집계를 파티션 단위로 병렬화하는 설계를 제안했고, 팀이 적용하는 동안 예시 구현과 리뷰로 함께했습니다. 배치 읽기는 전용 복제본으로 분리했으며, 스키마 변경은 없었습니다. 정산 외의 다른 배치 구간은 손대지 않았습니다.
결과
정산 배치 완료가 6시간에서 40분으로 줄었고, 지연 알림이 사라졌습니다. 인수인계 문서와 재현 가능한 실행 절차를 함께 남겼습니다.
상황
동시 접속 8만까지 오르는 서비스에서, 트래픽 대비 상시 확보된 인스턴스가 많았고, 목록 API는 캐시 없이 반복 조회되고 있었습니다. 운영 전담이 없어 '더 좋은 구조'보다 '손이 덜 가는 구조'가 필요했습니다.
개입
쿠버네티스 도입 대신 관리형 서비스 위에서 오토스케일 정책만 다시 잡는 방향을 제안했습니다. 목록 조회의 캐시 이전과 유휴 리소스 정리는 팀이 수행했고, 최종 구성은 IaC로 함께 고정했습니다.
결과
월 클라우드 비용이 34% 줄었고, 목록 API p95는 3분의 1이 되었습니다. 새로 운영해야 하는 컴포넌트는 캐시 하나뿐이었습니다.
단기 · 스팟 작업
* 모든 지표는 계약상 공개 가능한 범위로 반올림·일반화했습니다.
nda & confidentiality
지금까지의 모든 작업은 NDA 아래 진행되었고, 이 페이지에도 회사명·서비스명·실제 스키마·코드는 어디에도 포함되어 있지 않습니다. 다이어그램은 구조만 남기고 익명화했으며, 트래픽 규모와 개선 지표는 원본 대신 반올림·일반화한 값만 적었습니다.
04 — 작업 방식
1인으로 일하기 때문에 고객사 인프라를 직접 상시 운영하지는 않습니다. 문제를 진단하고 구조를 설계해 적용 가능한 형태로 넘기고, 팀이 실행하는 동안 옆에서 검토합니다. 떠난 뒤에도 팀이 운영할 수 있는 상태가 목표입니다.
01
지표·로그·코드와 팀 상황을 함께 확인해 병목과 제약을 문서로 정리합니다. 보통 3일에서 2주.
02
선택지를 2~3개로 좁혀 비용·인력·리스크를 함께 제시합니다. 권하지 않는 안도 이유와 함께 적습니다.
03
실제 변경은 팀이 수행하고, 저는 PR 리뷰·페어 작업·의사결정 지원으로 붙습니다. 필요하면 예시 구현을 제공합니다.
04
구조도·운영 절차·모니터링 기준을 문서로 남깁니다. 종료 후 일정 기간 질문에는 답합니다.
제가 하는 일
하지 않는 일
05 — 기술 스택
아래는 실제로 설계 판단에 쓰는 것만 남긴 목록입니다. 주력과 보조를 구분해 표기했고, 보조는 담당 팀과 대화가 되는 수준이라는 뜻입니다. 화면에서 어떤 호출이 일어나는지, 기기에서 어떤 데이터가 어떤 주기로 올라오는지까지 같은 기준으로 볼 수 있어, 서버만 보고 내리기 어려운 판단에서 차이가 납니다.
클라우드
cloud·주력백엔드
backend·주력데이터베이스
database·주력인프라 도구
infra tools·주력모니터링 · APM
monitoring·실무 경험프론트엔드
frontend·보조임베디드 · 펌웨어
embedded·보조06 — 연락처
지금 겪고 있는 상황을 간단히 적어 보내주셔도 좋아요. 요구사항이 아직 정리되지 않았어도, 어떤 구조가 필요한지 함께 정리하는 것부터 시작합니다. 작게는 3일 진단부터 가능합니다.