💭

[고찰] 기본기를 갖춘 백엔드 개발자가 되려면

생성일

2025/09/13 12:02

태그

Thinking

들어가는 글

1. DB와 쿼리 최적화: 백엔드의 핵심

캐싱 전략(Write-through/Write-behind)

들어가는 글

백엔드 개발은 단순히 API를 작성하고 DB에 데이터를 넣고 빼는 일에 그치지 않는다. 서비스의 성능, 확장성, 보안, 운영까지 고려해야 진짜 실무형 백엔드 개발자라고 할 수 있다. 지난 3년 반동안 실무와 개인 프로젝트를 통해 내가 중요하게 생각하는 백엔드 개발자의 기본기와 실무 경험을 통해 배운 핵심 지식을 정리해보려고 한다.

1. DB와 쿼리 최적화: 백엔드의 핵심

sequenceDiagram
  autonumber
  participant C as Client
  participant N as Nginx/ALB
  participant A as App(Server)
  participant R as Redis(Cache)
  participant D as DB(RDBMS)

  C->>N: HTTPS 요청 (GET /api/v1/books?category=...)
  N->>A: 프록시 전달
  A->>R: 캐시 조회 (Key: books:category:...)
  alt Cache Hit
    R-->>A: 캐시 결과 반환
    A-->>C: 200 OK (응답, TTL 표시)
  else Cache Miss
    A->>D: SELECT ... (인덱스/페이징)
    D-->>A: 결과 반환
    A->>R: 캐시 적재 (TTL, 압축)
    A-->>C: 200 OK (신선 데이터)
  end
Mermaid
복사

실무에서 가장 큰 병목 지점은 종종 DB에서 발생한다. 흔히 부트캠프나 국비 교육에서 경험할 수 없는 DB 에러를 실무에서는 빈번하게 경험할 수 있다. 코드를 다루기도 하지만 실질적으로는 DB 쿼리와 트래픽, 부하에 대한 이슈를 많이 다룬다.

•

인덱스 설계: 단순히 WHERE 조건에 컬럼 하나 추가한다고 해결되지 않는다. 조인 쿼리의 실행 계획(EXPLAIN)을 분석하고, 카디널리티(Cardinality)를 고려한 인덱스 설계가 필수다.

•

N+1 문제 해결: JPA를 사용할 때 Fetch Join 이나 Batch Size 튜닝을 통해 해결하는 것은 필수 역량이다.

•

캐싱 도입: Redis를 통해 조회성 API 성능을 개선할 수 있어야 한다. 

캐싱 전략(Write-through/Write-behind)

graph LR
  A[App] -->|Read| R[(Redis)]
  A -->|Read Miss| D[(DB)]
  D -->|Result| A
  A -->|Set TTL| R

  subgraph Write-through
    A -->|Create/Update| D
    A -->|Same key update| R
  end

  subgraph Write-behind
    A --> Q[[Queue]]
    Q --> WR[Async Writer]
    WR --> D
    WR --> R
  end
Mermaid
복사

2. 대규모 트래픽을 고려한 설계

graph TD
  U[사용자/브라우저·모바일] -->|HTTPS| CDN[CDN/Static]
  U -->|HTTPS| WAF[WAF/보안 게이트웨이]
  WAF --> NLB[(Nginx/ALB)]
  NLB -->|Round-robin| APP1[(App Pod 1)]
  NLB -->|Round-robin| APP2[(App Pod 2)]
  subgraph Application Layer
    APP1 -.-> APM[APM/Tracing]
    APP2 -.-> APM
  end

  APP1 --> REDIS[(Redis 캐시)]
  APP2 --> REDIS
  APP1 --> DB[(RDBMS)]
  APP2 --> DB
  APP1 --> MQ[(Message Queue: Kafka/RabbitMQ)]
  APP2 --> MQ

  MQ --> C1[(Consumer 1)]
  MQ --> C2[(Consumer 2)]
  C1 --> S3[(Object Storage)]
  C2 --> EXT[외부 API/서드파티]

  subgraph Observability
    APP1 -. 로그 .-> LS[Logstash/Fluentd]
    APP2 -. 로그 .-> LS
    LS --> ES[(Elasticsearch)]
    ES --> K[키바나]
    APP1 -. 메트릭 .-> PROM[Prometheus]
    APP2 -. 메트릭 .-> PROM
    PROM --> G[Grafana]
    PROM --> AM[Alertmanager]
    AM -->|Webhook| CHAT[Slack/Discord]
  end
Mermaid
복사

서비스의 규모가 커지면 트래픽이 폭증할 수 있기 때문에 이를 대비하기 위한 설계는 백엔드 개발자의 책임이다.

•

무중단 배포와 수평 확장을 위해 Nginx, AWS ELB 등을 활용할 수 있어야 한다.

•

세션 관리

◦

Stateless 구조를 기반으로 JWT + RefreshToken(캐시 저장소 연동) 방식을 구현할 수 있어야 한다.

•

CQRS/이벤트 기반 아키텍처

◦

읽기/쓰기 분리와 메시지 큐(Kafka, RabbitMQ)로 트래픽을 흡수하는 구조를 설계할 수 있어야 한다.

3. 운영 환경과 모니터링

코드가 잘 돌아가는 것만큼 중요한 것은 문제가 생겼을 때 빨리 파악하고 대응할 수 있는 역량이다.

•

로그 수집/분석: ELK 스택으로 분산 환경 로그를 모니터링

•

지표 기반 모니터링: Prometheus + Grafana로 API Latency, DB Connection, 서버 자원 사용량을 추적

•

알림 체계: 장애 발생 시 Slack/Discord Webhook으로 알림을 받아 빠르게 대응

4. 보안과 안정성

sequenceDiagram
  autonumber
  participant U as User
  participant A as App(Server)
  participant RR as Redis(RefreshToken 저장)

  U->>A: POST /auth/login (id/pw)
  A->>A: 인증/비밀번호 검증(BCrypt)
  A->>RR: Refresh 토큰 저장(setex, jti)
  A-->>U: 200 (accessToken, refreshToken)

  U->>A: 보호 API 요청 (Authorization: Bearer access)
  A->>A: access 검증 & 권한 확인
  A-->>U: 200 (리소스)

  Note over U,A: Access 만료 시
  U->>A: POST /auth/refresh (refreshToken)
  A->>RR: refresh 유효성/블랙리스트 검사
  A-->>U: 200 (새 access, 필요 시 새 refresh)
Mermaid
복사

•

JWT 토큰 인증 + RefreshToken 관리

•

SQL Injection, XSS, CSRF 방어 같은 보안 기본기 적용

•

OWASP Top 10 보안 취약점 숙지 및 실무 반영

•

시큐어 코딩 반영

5. 팀워크와 코드 품질

기술 역량뿐 아니라 협업 역량도 중요하다.

•

코드 리뷰를 통한 품질 확보

•

테스트 코드(JUnit, Mockito) 기반의 신뢰성 있는 코드 작성

•

CI/CD 파이프라인(Jenkins, Github Actions, Docker)을 통한 자동화된 배포

graph LR
  Dev[Developer] --> GH[GitHub]
  GH --> CI[Jenkins/GitHub Actions]
  CI --> B[JUnit/Mockito]
  B --> IMG[Docker Image Build]
  IMG --> REG[(Container Registry)]
  REG --> CD[(ArgoCD/Ansible)]
  CD --> K8S[(Kubernetes/EC2)]
  K8S --> LB[Service/Ingress]
  LB --> Users[End Users]

  subgraph Deployment Strategy
    BG[Blue-Green] --- ROLL[Rolling Update]
    H[Health/Readiness Probe]
  end
  CD -.uses .-> BG
  CD -.uses .-> ROLL
  K8S -.exposes .-> H
Mermaid
복사

graph TD
  App[App/Exporter] --> PR[Prometheus]
  PR --> G[Grafana 대시보드]
  PR --> AM[Alertmanager]
  AM -->|사전 정의 규칙| Noti[Slack/Discord/PagerDuty]

  Logs[App Logs] --> F[Fluentd/Vector]
  F --> ES[Elasticsearch]
  ES --> K[Kibana 탐색/대시보드]
Mermaid
복사

sequenceDiagram
  autonumber
  participant A as App
  participant S as 외부 서비스
  participant CB as Circuit Breaker

  A->>CB: 호출 요청
  alt Closed (정상)
    CB->>S: 요청 전달
    S-->>CB: 200 OK (성공/지연)
    CB-->>A: 응답 전달
  else Open (연속 오류)
    CB-->>A: 즉시 실패(fallback)
    A-->>A: 캐시/대체경로 사용
  end

  Note over CB: 실패율, 타임아웃 기준으로 Half-Open 전환 및 재시도
Mermaid
복사