seuthootdev 님의 블로그

항해+ 백엔드 코드 9주차 회고 : Kafka 메세지 큐

seuthootdev — Tue, 9 Sep 2025 19:11:56 +0900

항해 20만원 할인 추천인코드: NYFKU8

이번 주 과제는 기존에 구현된 이벤트 기반 로직을 Kafka 메세지 큐를 활용하여 리팩토링 하는 과제였습니다.

Kafka는 대규모 실시간 데이터 스트리밍을 위한 분산 메시징 시스템으로, 높은 처리량과 안정성을 제공하는 것이 특징입니다. 특히 이벤트 기반 아키텍처에서 서비스 간 결합도를 낮추고, 장애가 발생했을 때에도 메시지를 안정적으로 처리할 수 있도록 설계되어 있습니다

Kafka Overview

Producer & Consumer
- Producer는 메시지를 Kafka 브로커에 발행하는 주체입니다.
- Consumer는 브로커에 적재된 메시지를 읽어오는 서비스입니다.
- Consumer는 메시지의 처리 위치를 추적하기 위해 offset을 사용하며, 이를 커밋하여 재처리나 누락을 방지합니다.
Broker
- Kafka 서버의 단위로, Producer의 메시지를 받아 디스크에 저장하고 Consumer 요청에 따라 전달합니다.
- 클러스터 내부에서는 Controller(장애 브로커 감지 및 리더 파티션 재분배), Coordinator(컨슈머 그룹 모니터링 및 파티션 재할당) 같은 역할을 수행합니다.
Topic & Partition
- 메시지는 토픽 단위로 분류되고, 각 토픽은 여러 개의 파티션으로 나뉩니다.
- 파티션을 활용하면 병렬 처리가 가능해 대용량 트래픽을 빠르게 처리할 수 있으며, 같은 파티션 내에서는 순차성이 보장됩니다.
- 메시지 키를 활용하면 특정 자원(ID 등)에 대해 순서가 중요한 이벤트는 순차성을 보장할 수 있습니다.
Consumer Group
- 하나의 토픽을 여러 서비스가 구독할 수 있도록 그룹화한 개념입니다.
- 같은 토픽의 메시지를 결제 서비스, 상품 서비스 등 여러 애플리케이션이 동시에 처리할 수 있으며, 그룹 내에서 파티션은 컨슈머에게 분배됩니다.
Rebalancing
- 새로운 Consumer가 추가되거나 장애가 발생했을 때 파티션의 소유권을 재분배하는 과정입니다.
- 단, 리밸런싱이 일어나는 동안에는 메시지 처리가 중단되므로 주의가 필요합니다.
Cluster & Replication
- Kafka는 고가용성을 위해 여러 Broker를 묶어 클러스터를 구성합니다.
- 각 파티션은 리더(Leader) Replica와 팔로워(Follower) Replica를 두어 장애 시에도 안정성을 확보합니다.

STEP 17 카프카 기초 학습 및 활용

실시간 주문정보(이커머스) & 예약정보(콘서트)를 카프카 메시지로 발행하도록 변경합니다.
- 카프카에 대한 기초 개념을 학습하고 문서로 작성합니다.
  - 로컬에서 카프카를 설치하고 기본적인 기능을 수행해봅니다.
  - 어플리케이션에서 카프카를 연결하여 Producer & Consumer를 동작시켜봅니다.

STEP 18 카프카를 활용하여 비즈니스 프로세스 개선

각 프로젝트의 대용량 트래픽 프로세스를 카프카를 활용하도록 변경해봅니다.
개선한 내용에 대한 설계 문서(비즈니스 시퀀스 다이어그램, 카프카 구성 등)를 작성합니다.

Step18 by seuthootDev · Pull Request #19 · seuthootDev/hanghae-plus-backend

PR 제목 규칙 [STEP18] 정승훈 - (e-commerce) STEP 17 카프카 기초 학습 및 활용 [✅] 카프카에 대한 기본 개념 학습 문서 작성 문서작성 7d898fa | kafka 기본예제 ed4b46b | kafka 토픽,스트림 예제 36df67b [✅]

github.com

Step17 by seuthootDev · Pull Request #18 · seuthootDev/hanghae-plus-backend

PR 제목 규칙 [STEP17] 정승훈 - (e-commerce) STEP 17 카프카 기초 학습 및 활용 [✅] 카프카에 대한 기본 개념 학습 문서 작성 문서작성 7d898fa | kafka 기본예제 ed4b46b | kafka 토픽,스트림 예제 36df67b [✅]

github.com

회고

Kafka를 적용하면서 단순한 메시지 큐를 넘어 대용량 트래픽 처리와 서비스 간 책임 분리에 강점이 있다는 걸 느꼈습니다. 파티션과 Consumer Group 설계가 성능과 직결된다는 점이 인상 깊었고, 리밸런싱과 같은 운영 이슈도 고민할 필요가 있다는 걸 배웠습니다.

항해+ 백엔드 코드 8주차 회고 : Event 기반 Transaction

seuthootdev — Sun, 31 Aug 2025 21:29:05 +0900

항해 20만원 할인 추천인코드: NYFKU8

이번 주 과제는 기존에 구현된 비즈니스 로직을 이벤트 기반 아키텍처로 리팩토링하는 것이었습니다. 단순히 하나의 트랜잭션으로 처리하던 복잡한 로직을 이벤트 발행과 구독 모델로 분리하면서, 트랜잭션 범위를 축소하고 관심사를 분리하였습니다.

애플리케이션 이벤트를 통한 관심사 분리

Event 기반 흐름 제어

Event 를 발행 및 구독하는 모델링을 통해 코드의 강한 결합을 분리함
Event 에 의해 본인의 관심사만 수행하도록 하여 비즈니스 로직간의 의존을 느슨하게 함

활용 방안

비대해진 트랜잭션 내의 각 작업을 작은 단위의 트랜잭션으로 분리할 수 있음
특정 작업이 완료되었을 때, 후속 작업이 이벤트에 의해 trigger 되도록 구성함으로써 과도하게 많은 비즈니스 로직을 알고 있을 필요 없음
외부 API 호출 및 부가 로직의 실패나 지연이 주요 비즈니스 로직(트랜잭션)에 영향을 주지 않도록 구성할 수 있음

class OrderPaymentService {
	Transaction {
		fun 주문_결제() {
			유저_포인트_차감();
			결제_정보_저장();
			주문_상태_변경();
			
			결제_완료_이벤트_발행();
		}
	}
}


class OrderPaymentEventListener {

	TransactionEventListener(AFTER_COMMIT) {
		Async {
		  // Notify Service
			fun 주문_정보_전달(결제_완료_이벤트)
		}
	}
	
	TransactionEventListener(AFTER_COMMIT) {
		Async {
			fun 결제_완료_알림톡_발송(결제_완료_이벤트)
		}
	}
}

OrderPaymentService에서 핵심 로직의 가독성이 훨씬 좋아졌습니다.
결제 완료에 대한 부가 로직에 대한 관심사를 분리했습니다.

Implementation

이벤트를 활용해서 단순히 부가 로직을 분리할 뿐만 아니라, 여러 도메인이 결합하여 구성된 핵심 로직을 각 도메인별로 관심사와 트랜잭션을 분리하도록 구성할 수도 있습니다.

주의할 점

각 작업의 논리적 의존이나 관계를 잘 파악해야 함
- Service A 로직이 수행된 이후에 이벤트를 발행하여 Service B와 Service C가 각각 로직을 수행함
- 만약 Service B 로직을 수행한 이후에 Service C 로직을 수행해야 한다면?
만약 이벤트에 의해 파생된 작업이 실패하였을 때, 원본 작업 또한 실패 처리를 해야 한다면 이를 위한 처리가 필요함 ( keyword : 보상 트랜잭션, SAGA 패턴 )
이벤트에 의해 각 작업이 영향을 주고 있는지, 혹은 이벤트가 발생하면 안되는 상황에서 이벤트가 발행되고 있지는 않은지 등

이번주 과제 내용

STEP 15 Application Event

실시간 주문정보(이커머스) & 예약정보(콘서트)를 데이터 플랫폼에 전송(mock API 호출)하는 요구사항을 이벤트를 활용하여 트랜잭션과 관심사를 분리하여 서비스를 개선합니다.

STEP 16 Transaction Diagnosis

서비스의 확장에 따라 어플리케이션 서버와 DB를 도메인별로 분리했을때, 트랜잭션 처리의 한계와 대응 방안에 대한 설계 문서 제출

Step15 by seuthootDev · Pull Request #16 · seuthootDev/hanghae-plus-backend

PR 제목 규칙 [STEP15] 정승훈 - (e-commerce) STEP 15 Application Event [✔️] 주문/예약 정보를 원 트랜잭션이 종료된 이후에 전송 [✔️] 주문/예약 정보를 전달하는 부가 로직에 대한 관심사를 메인 서

github.com

Step16 by seuthootDev · Pull Request #17 · seuthootDev/hanghae-plus-backend

github.com

항해 20만원 할인 추천인코드: NYFKU8

항해+ 백엔드 코드 7주차 회고 : Redis의 자료구조와 활용

seuthootdev — Mon, 25 Aug 2025 10:24:17 +0900

이번 주 과제는 기존에 구현된 선착순 쿠폰 발급과 인기상품 조회 기능을 Redis의 자료구조를 활용하여 리팩토링하는 것이었습니다. 단순히 캐시로만 알고 있던 Redis가 사실은 다양한 컬렉션 자료구조를 지원하고, 이를 통해 현업에서 랭킹 시스템, 이벤트 처리, 중복 제어 등 다양한 문제를 효율적으로 해결할 수 있다는 점을 새롭게 알게 되었습니다.

특히 Redis의 Sorted Set은 굉장히 강력한 기능이라고 느꼈습니다. 원래는 직접 구현해야 하는 실시간 랭킹 기능을 단 몇 개의 명령어로 처리할 수 있다는 점이 인상적이었습니다.

레디스 자료구조

Redis 는 기본적으로 Key-Value 기반의 데이터 저장소입니다.

Value 로는 단순히 String 뿐 아니라 다양한 데이터 타입 ( Collections )를 지원하는데, 이를 활용해 현업에서 단순히 캐시 뿐 아니라 다양한 용도로 활용하고 있어요.

Strings

일반 문자열 ( 최대 512MB )
단순 증감 연산 혹은 문자열로 표현 가능한 모든 자료 저장하는 목적으로 활용
주요 명령어
- 수정 계열 : set, setnx, ..
- 조회 계열 : get, mget, ..
- INCR 계열 ( 단순 증감 )

Sets

저장된 원소의 Unique 함을 보장하는 자료구조
Set 은 정렬을 보장하지 않음
Set 자료구조를 위한 연산 지원 ( 교집합 / 합집합 / 차집합 등 )
주요 명령어
- 수정 계열 : sadd, smove
- 조회 계열 : smembers, scard, ..
- 제거 계열 : spop, srem
- 집합 계열 : sunion, sinter, sdif, ..

Sorted Sets

set + score 가중치 필드가 추가된 자료구조
데이터 저장시, score 기반 오름차순 정렬로 저장됨
score 값이 같은 경우, 사전순으로 정렬
주요 명령어
- 수정 계열 : ZADD
- 조회 계열 : ZRANGE, ZRANGEBYSCORE, ZRANK, ZSCORE, ..
- 제거 계열 : ZPOPMIN, ZPOPMAX, ZREM, ..
- 증감 계열 : ZINCRBY
- 집합 계열 : ZUNIONSTORE, ZINTERSTORE

Redis 기반의 랭킹 시스템

개요

실시간 랭킹이 필요한 시스템(게임 점수, 인기 콘텐츠, 상품 조회 등)에 적합
Redis의 Sorted Set을 활용하여 효율적이고 빠른 랭킹 처리 가능

핵심 개념: Redis Sorted Set

구조: ZADD key score member
정렬: score 기준 오름차순 (낮은 점수 → 높은 점수)
특징:
- 같은 점수면 사전순 정렬
- 점수 기반으로 순위 계산이 가능함
- 조회 및 수정이 매우 빠름 (O(log N))

기본 명령어 예시

1. 점수 추가 및 갱신

ZADD game_ranking 1500 user123
ZADD game_ranking 3000 user456
ZADD game_ranking 2500 user789

2. 특정 사용자 점수 조회

ZSCORE game_ranking user123

3. 전체 랭킹 조회 (높은 점수가 1등)

ZREVRANGE game_ranking 0 9 WITHSCORES  # Top 10

4. 특정 사용자 순위 조회

ZREVRANK game_ranking user123

5. 점수 증가 (예: 게임 승리 시 점수 부여)

ZINCRBY game_ranking 100 user123

응용 예시: 일간 / 주간 랭킹 분리

키 구성 전략

ranking:daily:20240429
ranking:weekly:2024-W18

TTL 설정

일간 랭킹은 하루 후 자동 만료
주간 랭킹은 일주일 후 만료

EXPIRE ranking:daily:20240429 86400

⚠️ 주의할 점

Sorted Set에 너무 많은 데이터를 넣으면 메모리 부담 ↑
TTL 없이 데이터 계속 쌓이면 만료 누락 가능성 존재
동일 점수 처리 로직(예: 마지막 갱신 시간 기준 정렬 등) 필요 시 보완 로직 필요

실전 활용 예시

사용자 게임 랭킹

ZADD game:ranking:user 5000 userA
클라이언트에게 ZREVRANK 결과 전달하여 등수 노출

시각화 전략

Redis에서 Top N을 가져와 DB 캐싱 → 사용자에게 제공
그래프 구성: 시간대별 랭킹 변동, 내 순위 추이 등 추가 분석 가능

✅ 요약

기능 Redis 명령어

점수 등록/수정	ZADD, ZINCRBY
순위 조회	ZREVRANK, ZREVRANGE
점수 조회	ZSCORE
데이터 만료	EXPIRE

참고

Redis 공식 문서: https://redis.io/commands/zadd/
Redis TTL 관리: https://redis.io/docs/manual/key-expiration/

과제

Step14 by seuthootDev · Pull Request #14 · seuthootDev/hanghae-plus-backend

PR 제목 규칙 [STEP14] 정승훈 - (e-commerce) 핵심 체크리스트 ✅ one: ranking design [✔] 적절한 설계를 기반으로 랭킹기능이 개발되었는가? [✔] 적절한 자료구조를 선택하였는가? 05c2b9c f625a44 8590803 67

github.com

과제는 다음과 같은 방식으로 구현했습니다:

선착순 쿠폰 발급 기능은 사용자 요청이 발생하면 Sorted Set으로 순위를 기록하고, 그 결과를 기반으로 실제 DB에 쿠폰을 발급하도록 했습니다.
단, 랭킹 기록 이후 DB 저장 직전에 장애가 발생할 수 있다는 리스크가 있어, 랭킹 기록과 로그 저장을 비동기적으로 처리하도록 설계했습니다. 이렇게 함으로써 장애 상황에서도 최소한 발급 순위 정보는 Redis에 안전하게 남길 수 있도록 했습니다.
또한, 인기 상품 조회 기능 역시 클릭 수를 Sorted Set에 누적하는 방식으로 구현해, 실시간으로 상품의 인기도를 반영할 수 있었습니다.

이번 과제를 통해 Redis가 단순 캐시 도구를 넘어 데이터를 구조적으로 다루고 실시간성을 보장하는 핵심 인프라가 될 수 있음을 체감했습니다. 앞으로도 이런 자료구조적 특성을 잘 이해하고 활용하면, 더 많은 비즈니스 로직을 단순화하면서도 성능을 확보할 수 있을 것 같습니다.

항해+ 백엔드 코드 6주차 회고 : 분산락 + 캐시

seuthootdev — Mon, 18 Aug 2025 20:14:04 +0900

항해 20만원 할인 추천인코드: NYFKU8

분산락 & 캐시 정리

1. 왜 필요한가?

대용량 트래픽 환경에서는 **한정된 자원(쿠폰, 좌석, 재고 등)**에 동시에 접근하는 문제가 자주 발생합니다.
단순히 DB 트랜잭션만으로는 성능 한계가 있어 Redis 기반 분산락 + 캐시 전략이 효과적입니다.

2. Redis 기반 분산락

Redis는 Key-Value 저장소이자 원자적 연산을 지원하기 때문에, 락 관리에 적합합니다.

동작 방식

락 획득: SETNX key value 로 키가 없을 때만 등록
비즈니스 로직 수행
락 해제: DEL key 로 해제
TTL 설정: 장애 시 자동 해제 보장

구현 방식

Simple Lock
- 실패 즉시 예외 발생 → 빠른 실패 처리
- 단점: 재시도 로직 별도 구현 필요
Spin Lock
- 실패 시 일정 횟수/시간 동안 재시도
- 장점: 결국 락 획득 확률↑
- 단점: 네트워크 비용 & 스레드 점유 문제
Pub/Sub Lock
- Redis Pub/Sub 활용 → 락 해제 이벤트 구독 후 대기
- 장점: Spin Lock 대비 효율적
- 단점: 구현 난이도↑

올바른 순서

락 획득 → 트랜잭션 시작 → 로직 실행 → 트랜잭션 종료 → 락 해제

잘못된 순서(트랜잭션 먼저 시작 / 락 먼저 해제)는 데이터 정합성 깨뜨림.

3. 캐시(Cache) 활용

Redis는 단순 캐시뿐만 아니라 분산락 인프라 역할도 수행.
캐시 장점
- DB 부하 감소 → 성능(Throughput) 향상
- TTL 활용 → 데이터 최신성 보장
- 락과 함께 → 정합성 + 성능 동시 달성

4. 정리

분산락: 데이터 정합성을 지키기 위한 핵심 기술
캐시: 성능 최적화 및 부하 분산
Redis는 두 역할을 모두 수행할 수 있음
결국, 대규모 트래픽 환경에서는
Redis 분산락 + 캐시 전략이 안정적인 서비스 운영의 핵심

과제 링크

Step12 by seuthootDev · Pull Request #12 · seuthootDev/hanghae-plus-backend

PR 제목 규칙 [STEP12] 정승훈 - e-commerce 핵심 체크리스트 ✅ 1️⃣ 분산락 적용 (3개) [✔️] 적절한 곳에 분산락이 사용되었는가? 79a61a7 0f4c3c0 [✔️] 트랜젝션 순서와 락순서가 보장되었는가? ae2

github.com

Step11 by seuthootDev · Pull Request #11 · seuthootDev/hanghae-plus-backend

PR 제목 규칙 [STEP11] 정승훈 - e-commerce 핵심 체크리스트 ✅ 1️⃣ 분산락 적용 (3개) [✔️] 적절한 곳에 분산락이 사용되었는가? 79a61a7 0f4c3c0 [✔️] 트랜젝션 순서와 락순서가 보장되었는가? ae2

github.com

항해+ 백엔드 코드 5주차 회고 : 동시성 처리(Concurrency Control) 과제 정리 – 데이터 정합성과 성능 동시 확보하기 (항해 부트캠프 할인코드 있음)

seuthootdev — Sat, 9 Aug 2025 19:12:01 +0900

이번 주차의 메인 주제는 동시성 처리 였습니다.

항해 20만원 할인 추천인코드: NYFKU8

안녕하세요!

이번 포스팅에서는 제가 진행한 동시성 처리(Concurrency Control) 과제에 대해 정리해보려고 합니다.
실제 서비스 환경에서 자주 발생하는 경쟁 상황에서도 데이터 정합성을 지키면서 동시에 높은 성능을 내는 것이 목표였는데요,
제가 어떤 전략을 선택했고 어떻게 구현했는지, 그리고 검증 결과까지 자세히 공유합니다.

1. 과제 개요 및 목표

이번 과제의 주제는 바로 동시성 처리 입니다.
서비스가 커지고 여러 사용자가 동시에 요청할 때, 발생할 수 있는 데이터 충돌 문제를 방지하는 것이 핵심입니다.
목표는 경쟁 상황에서도 데이터 정합성(Consistency) 을 보장하고, 동시에 성능 저하를 최소화하는 것입니다.

2. 동시성 관련 기본 개념

트랜잭션과 ACID
데이터 정합성을 보장하기 위해 트랜잭션은 반드시 ACID 원칙을 따라야 합니다.
- Atomicity (원자성): 모두 성공하거나 모두 실패
- Consistency (일관성): 데이터 일관성 유지
- Isolation (고립성): 트랜잭션 간 간섭 방지
- Durability (지속성): 완료된 트랜잭션 결과 영구 저장
격리 수준 (Isolation Level)
성능과 안정성 사이 균형을 위해 보통 아래 중 선택합니다.
- Read Committed
- Repeatable Read
- Serializable
동시성 문제 유형
- Lost Update
- Dirty Read
- Non-Repeatable Read
- Phantom Read

3. 전략 선택과 도메인 매핑

락 전략
- 비관적 락: 충돌을 미리 방지하기 위해 선잠금, 안정적이지만 성능 부담 큼
- 낙관적 락: 버전 비교 후 재시도 방식, 충돌 적으면 성능 우수
도메인별 전략 선택 기준

도메인충돌 빈도중요도락 전략

쿠폰 발급 (선착순 보장)	높음	순서/수량 보장 필수	비관적 락
포인트 충전/차감	중간	성능 중요	낙관적 락
주문 생성, 회원가입, 결제	중간	성능 + 재시도 용이성	낙관적 락

4. 3계층 락 구현 방식

애플리케이션 레벨 락
- @OptimisticLock, @PessimisticLock 데코레이터와 인터셉터로 적용
Redis 분산 락
- 다중 서버 환경에서의 동시성 이슈 방지용
- RedisPessimisticLockInterceptor
DB 물리적 락(보조적 사용)
- FOR UPDATE 행 단위 락
- 낙관적 락용 버전 컬럼 활용

5. 주요 코드 위치 및 테스트

데코레이터 & 인터셉터:
src/common/decorators/*
src/common/interceptors/*
레포지토리 적용:
src/infrastructure/repositories/*.repository.ts
테스트:
test/it/integration/concurrency.integration.spec.ts 외 다수

6. 검증 및 성능 결과

통합 테스트 59개 항목 모두 통과!
핵심 시나리오 검증 결과:
- 동시 포인트 충전(10건) → 모두 성공 (낙관적 락 재시도 포함)
- 동시 주문 생성(5건) → 재고 및 쿠폰 일관성 보장 성공
- 중복 결제 방지 → 1건 성공, 2건 실패 (중복 차단 정상 작동)
- 동시 쿠폰 발급(5건) → 선착순 순서 및 수량 보존
- 트랜잭션 롤백 시 잔액 정상 복구
성능 측정 요약

작업요청수평균 처리 시간TPS(초당 처리량)

포인트 충전 (10건)	10	57.4 ms	174 req/s
주문 생성 (5건)	5	32.49 ms	154 req/s
결제 (3건)	3	19.47 ms	154 req/s
쿠폰 발급 (5건)	5	28.11 ms	178 req/s
선착순 쿠폰 (3건 순차)	3	7.92 ms	379 req/s
대량 처리 (포인트20/주문10/쿠폰15)	45	53~63 ms	159~318 req/s

7. 왜 이 전략이 타당한가?

쿠폰은 정확한 순서와 수량 보장이 비즈니스 핵심이므로,
충돌을 즉시 제거하는 비관적 락이 적합합니다.
반면 포인트, 주문, 결제, 회원가입 등은 성능과 재시도 용이성이 중요하여,
낙관적 락으로 처리량을 최적화하였습니다.
Redis 분산락으로 다중 서버 환경에서도 확장성을 확보했고,
DB 물리적 락은 보조적으로 사용해 병목 현상을 최소화했습니다.

8. 한계와 향후 계획

고경합 구간에 한해 물리적 락 강화 (NOWAIT/WAIT, 타임아웃 정책 적용)
분산 락 키 및 TTL 정책을 더 정교하게 설계
부하 테스트 자동화
EXPLAIN 쿼리 및 인덱스 튜닝 주기적 실시
배치 작업 및 메시지 큐 도입 검토

마무리 한 줄 요약

“도메인 특성별 맞춤 락 전략과 애플리케이션/분산/DB 3계층 보호로 동시성과 성능을 모두 잡았다.”

궁금한 점이나 추가로 알고 싶은 부분이 있으면 댓글로 남겨주세요!
읽어주셔서 감사합니다.

과제 링크

Step09 by seuthootDev · Pull Request #9 · seuthootDev/hanghae-plus-backend

PR 제목 규칙 [STEP09] 정승훈 - e-commerce 동시성 처리가 필요하다고 느낀 서비스 비관적 락 (Pessimistic Lock) 쿠폰 발급 선착순 쿠폰의 정확한 순서 보장이 필수 쿠폰 수량이 제한적이고 선착순 원

github.com

Step10 by seuthootDev · Pull Request #10 · seuthootDev/hanghae-plus-backend

PR 제목 규칙 [STEP10] 정승훈 - e-commerce 동시성 처리가 필요하다고 느낀 서비스 비관적 락 (Pessimistic Lock) 쿠폰 발급 선착순 쿠폰의 정확한 순서 보장이 필수 쿠폰 수량이 제한적이고 선착순 원

github.com

항해+ 백엔드 코드 4주차 회고

seuthootdev — Sat, 2 Aug 2025 15:57:59 +0900

이번주의 주된 과제는 '데이터베이스'였다. 이미 구현한 데이터베이스도 있지만, 인덱스 튜닝 등 더 보완해 나가는 주 였다.

항해 추천인코드: NYFKU8

✍️ 이번 주 주제: 데이터베이스

이번 주의 메인 과제는 **'데이터베이스'**였습니다.
이미 지난주에 데이터베이스까지 구현하였지만, 인덱싱 등 더 보완하는 시간을 가졌습니다.

과제 링크

️ 과제 요약

STEP07 - Integration
- (선택) 기존 설계된 테이블 구조의 개선이 필요한 점을 식별하고 ERD에 반영
- Infrastructure Layer 작성
- 기능별 통합 테스트 작성
STEP08 - DB
- Infrastructure 는 RDBMS ( MySQL ) 기반으로 작성합니다.
  - 조회 성능 저하가 발생할 수 있는 기능을 식별하고, 해당 원인을 분석하여 쿼리 재설계 / 인덱스 설계 등 최적화 방안을 제안하는 보고서 작성

데이터베이스 설계 원칙

동일 위상의 데이터만 한 테이블에 구성 (ex. 상품과 리뷰는 분리)
컬럼 제약조건 엄격히 설정 (NOT NULL, UNIQUE, DEFAULT 등)
초기 설계부터 인덱싱 고려 (자주 사용되는 컬럼 기준)
정규화로 일관성과 중복 최소화, 반정규화로 조회 성능 향상

인덱스 & 쿼리 최적화 핵심

인덱스 설계 기준

조회에 자주 사용되는 컬럼 우선
중복이 적고 변경이 적은 컬럼에 설정
복합 인덱스 설계 시, 선행 컬럼의 카디널리티 고려
LIKE, IN, 범위 조건의 인덱스 활용 주의

쿼리 실행 계획 (Query Plan)

EXPLAIN을 통해 인덱스 활용 여부, 풀 테이블 스캔 여부 확인
Using filesort, Using temporary 발생 시 성능 저하 가능성

Covering Index

조회에 필요한 모든 컬럼이 인덱스에 포함되어 있으면 Index Only Scan 가능

동적 확장성 고려

상품 옵션이 다양해질 경우 옵션 테이블 분리 구조로 확장성 확보
범용적인 옵션 설계 필요 시 키-값 형태 또는 옵션 유형 분리 고려

Sync Schedule 전략

실시간 정합성보다 주기적인 배치 처리로 조회 성능 극대화
통계 데이터는 별도 테이블에 저장하여 조회 쿼리 단순화

데이터베이스 설계에 대한 소회

이번 주 멘토링에서 코치님의 인사이트가 특히 기억에 남는다.

"비정규화와 정규화는 각각 어떤 상황에 필요할까?"
이에 대해 코치님은 이렇게 말씀하셨다.

"정규화는 더 이상 정규화할 수 없을 때까지 진행하고,
성능 문제가 발생했을 때 그제서야 비정규화를 고려한다."

이 말이 인상 깊었던 이유는,

코치님은 항상 정해진 답이 없는 문제에도 불구하고,
생각하는 방법과 판단 기준을 세워주는 분이라는 느낌을 받았기 때문이다.

항해+ 백엔드 코드 3주차 회고

seuthootdev — Sat, 26 Jul 2025 19:37:56 +0900

이번주의 주된 과제는 '아키텍처'였다. 총 4개의 아키텍처 중 원하는 아키텍처를 선택하고,
지난주에 선택한 시나리오(이커머스 웹)를 선택한 아키텍처로 구현해보는 과제였다.

항해 추천인코드: NYFKU8

✍️ 이번 주 주제: 아키텍처

이번 주의 메인 과제는 **'아키텍처'**였습니다.
총 4개의 아키텍처(레이어드, 릴레이션 레이어드, 클린, 헥사고날) 중 하나를 선택하고,
지난주에 설정한 이커머스 웹 시나리오를 기반으로 해당 아키텍처를 적용해 구현하는 것이 목표였습니다.

과제 링크

️ 과제 요약

STEP 05

선택한 아키텍처에 맞춰 패키지 구조 설계
핵심 비즈니스 로직 구현
시나리오 기반 필수 기능 구현
단위 테스트 작성(Mocking/Stub 활용)
→ 단위 테스트는 외부 의존성 없이 해당 기능 자체에 집중

STEP 06

시나리오 기반 추가 기능 구현
각 레이어의 책임을 README에 명시
아키텍처 설계 원칙에 맞춰 책임 분리 및 유지보수성 고려한 구조 개선

아키텍처별 핵심 요약

1. 레이어드 아키텍처 (Layered Architecture)

Layered Architecture

가장 전통적인 구조
Controller → Service → Repository → DB
단순한 CRUD 시스템에 적합
단점: 계층 건너뛰기 유혹, 테스트 어려움, 도메인 로직 분산

2. 릴레이션 레이어드 (Layered + Interface / DIP 적용)

레이어드는 유지하되, 인터페이스로 추상화
Repository → Interface → 구현체
DIP 일부 적용 (Service는 인터페이스에만 의존)
장점: 유연한 구조, DB 교체 용이, 테스트 가능
단점: 도메인 모델 여전히 빈약

3. 헥사고날 아키텍처 (Hexagonal Architecture)

도메인 로직을 중심으로, 외부 시스템은 어댑터로 처리
REST, gRPC, MQ 등 다양한 입출력 대응 가능
포트(Port): 도메인이 요구하는 인터페이스
어댑터(Adapter): 외부 시스템을 연결하는 구현체
장점: 도메인 독립성, 테스트 용이
단점: 작은 프로젝트에 과도할 수 있음

4. 클린 아키텍처 (Clean Architecture)

UseCase 중심 설계, 도메인 모델과 유스케이스가 핵심
모든 외부 의존성은 내부를 향함
도메인 → UseCase → Interface → Adapter
DIP 완전 적용, OCP 준수
장점: 유지보수성, 확장성 최고
단점: 인터페이스 과다, 복잡도 높음

내가 선택한 아키텍처: 클린 아키텍처

클린 아키텍처를 선택한 이유는 다음과 같습니다:

비즈니스 로직의 독립성과 테스트 용이성을 확보할 수 있음
확장성과 유지보수성이 뛰어나고, 명확한 책임 분리가 가능
다양한 UI나 인프라 변경에도 도메인 로직이 영향을 받지 않음

어려웠던 점 & 해결 방법

❗ 가장 어려웠던 점

처음에는 클린 아키텍처의 구조 자체가 모호하게 느껴졌습니다.
각 레이어가 어디까지 책임져야 하는지, 어떤 방향으로 의존성이 향해야 하는지 혼란스러웠습니다.

✅ 해결 전략

핵심 원칙인 의존성 역전(Dependency Inversion Principle) 을 중심으로 구조를 이해하고 구현했습니다.
아키텍처 전반에 걸쳐 의존성의 방향을 도메인 → 인터페이스 → 외부로 유지하려 노력했습니다.

아쉬운 점 & 보완할 부분

분명 의존성 역전은 구현했지만, 결과적으로 1:1로 매핑된 인터페이스와 구현체가 많아졌습니다.
→ 실제로 인터페이스의 추상화 역할이 퇴색된 느낌도 들었습니다.
파사드 패턴(Facade)에 대한 이해 부족으로, 중간 조율 역할을 해주는 파사드를 적용하지 못했습니다.
→ 몇몇 레이어는 파사드를 활용해 더 깔끔하게 연결할 수 있었을 것으로 생각합니다.
전체 구조가 다소 복잡해졌고, 오히려 개발 생산성이 떨어진 부분도 있음.
→ 이후에는 복잡성과 실용성 사이의 균형에 대해 고민해봐야 할 것 같습니다.

‍ 팀 코드리뷰 소회

팀원들의 구조와 설계를 보며 같은 클린 아키텍처를 선택해도 구현 방식이 다양하다는 점을 체감했습니다.
특히, 도메인 설계와 추상화 정도에서 차이가 났는데, 이를 통해 제 코드가 과하게 복잡했는지 돌아보게 됐습니다.
다른 사람의 설계를 보며 실용적이고 간결한 방식의 장점도 배울 수 있었습니다.

✅ 한 줄 회고

“클린 아키텍처의 핵심은 구조가 아니라 방향성과 책임 분리에 있다는 것을 깨달은 한 주였다.”

항해+ 백엔드 코드 2주차 회고

seuthootdev — Sun, 20 Jul 2025 13:07:09 +0900

이번주의 주된 과제는 '문서화'였다. 총 8개의 문서를 작성해보았는데,
구현 과정에서 문서랑 코드랑 왔다갔다 하면서 자주 업데이트를 하게 되었다.
완벽한 문서는 있을 수 없겠지만, 그래도 너무 익숙하지 않아서 힘들었다....

항해 추천인코드: NYFKU8

✍️ 이번 주 주제: 문서화

이번 주의 메인 과제는 '문서화’였습니다.
총 8개의 문서를 작성하며, 비즈니스 로직을 분석하고 명확히 표현하는 데 집중했습니다.

또 모든 문서가 일관적이도록 하기 위해서 노력했습니다.

과제 링크
Step03 PR
Step04 PR

️ 과제 내용 요약

STEP 03 - 분석
- 시나리오 요구사항 분석 및 문서 작성 (e.g. 시퀀스 다이어그램, ERD 등)
STEP 04 - 실행
- Mock API 및 Swagger 문서 작성
- (선택 과제) API E2E 테스트 작성

작성한 문서 목록

총 8개의 문서를 docs/ 디렉토리 내 .md 파일로 작성했습니다.

요구사항 명세서
유스케이스
정책 문서
API 명세서
ERD
클래스 다이어그램
상태 다이어그램
시퀀스 다이어그램

Mermaid 도입기

처음으로 Mermaid라는 도구를 써봤는데, 정말 강력했습니다.

Mermaid란?
Markdown 기반으로 플로우차트, ERD, 시퀀스 다이어그램 등을 코드로 그릴 수 있게 해주는 문서화 도구

회사에서는 이전까지 문서를 주로 Figma로 작성했었는데, 이미지로 저장 후 프로젝트에 넣다 보니 수정 시 다시 Figma를 열어야 했고, 최신화도 어렵고 귀찮은 작업이었습니다.

하지만 Mermaid는 Markdown 문서에서 바로 수정 및 커밋이 가능하기 때문에 문서 수정이 간편하고, 협업 시에도 효율적입니다.
이 좋은 걸 이제야 알았다니... 늦게나마 알게 돼서 다행입니다.

어려웠던 점과 해결 방법

❗ 가장 어려웠던 점

비즈니스 로직을 잘 몰라서 어떤 정책이 필요한지, 어떤 문서를 작성해야 하는지 감을 잡기 어려웠습니다.

✅ 해결 전략

큰 틀 → 작은 틀 순서로 접근
- 예) 요구사항 명세서 → API 명세서 → ERD → 시퀀스/상태 다이어그램
점점 비즈니스 로직이 눈에 들어오기 시작했고, 문서 작성 속도도 점차 빨라졌습니다.

Swagger와 E2E 테스트

Swagger나 E2E 테스트 코드는 처음 작성해봐서 익숙하지 않았지만,
문서화 덕분에 로직을 이해한 상태였기에 Mock API로 구현 자체는 무난하게 진행할 수 있었습니다.

멘토의 한마디에서 얻은 인사이트

"문서화가 필요 없게 하는 것이 가장 좋다."

처음엔 문서화 과제 주간에 이런 말씀을 들어서 놀랐지만, 곧 이 말에 공감됐습니다.
문서는 결국 또 하나의 유지보수 대상이기 때문에, 코드만 보고도 이해할 수 있는 구조를 만든다면 가장 이상적이겠죠.

다음 프로젝트에서는 Plasma Markdown, Nestia 같은 자동 문서화 툴도 활용해보고 싶습니다.

‍ 팀 코드리뷰 소회

1. 동시성 처리 문서화의 부족

팀원들의 문서를 살펴보면서 내가 놓친 부분들이 눈에 띄었는데,
그 중 가장 아쉬웠던 점은 동시성 처리에 대한 문서화가 부족했다는 점입니다.

사실 동시성 처리에 대해서 아직 잘 이해하지 못한 상태여서,
문서에서는 단순히 "동시성 처리가 필요하다" 정도로만 추상적으로 언급했었습니다.

2. 주문 생성 vs 결제 처리 - 서비스 분리 여부

또 하나 흥미로웠던 점은 서비스 분리 방식이었습니다.
저는 주문 생성과 결제 처리를 별도의 서비스로 분리했는데,
대부분 팀원들은 주문 서비스 하나에서 둘 다 처리하는 방식을 택하셨습니다.

제가 서비스 분리를 선택한 이유는 다음과 같습니다:

사용자가 결제를 나중에 진행할 수도 있다고 생각함
결제 도중 페이지 이탈이나 PG사 에러와 같은 예외 상황 발생 가능성 고려

따라서 저는 주문은 먼저 생성하고, 결제는 별도 절차로 처리하는 구조가 더 유연하다고 판단했습니다.

다음 주 목표 & 다짐

이번 주는 기본 과제와 심화 과제 모두 PASS!

다음 주에도 좋은 결과를 얻으려면
일요일~화요일까지 시간을 어떻게 쓰느냐가 핵심이라고 생각합니다.

화요일 전까지 기본 과제 마무리
남은 시간엔 심화 과제에 깊이 있게 집중
멘토링 전에 사전 학습과 질문 준비 철저히

지난주엔 준비가 부족해서 멘토링 시간 이후 아쉬움이 남았기에,
이번에는 훨씬 더 알차게 준비해보려고 합니다.

✅ 한 줄 회고

"문서를 작성하며 비즈니스 로직을 자연스럽게 이해했고, Mermaid 덕분에 협업 가능한 문서화 경험을 얻을 수 있었다.
이제는 코드만으로도 문서가 되는 구조를 꿈꾼다."

항해+ 백엔드 코드 1주차 회고

seuthootdev — Sat, 12 Jul 2025 22:17:45 +0900

정말 바쁜 한 주가 지나갔다. 물론 이제 시작이고 앞으로 9주가 더 남았다......

나는 웹 개발자가 아니라서 학습하는 거의 대부분이 생소한 개념들이라 과제도 바로 시작을 못하고, 개념부터 학습하는 방식으로 작업하다 보니, 정말 많은 시간이 필요했고, 이번주엔 회식도 겹치는 바람에 더 시간이 없었다. ㅜㅜ
과제에서 얻을 수 있었던게 100이라면, 난 30만 얻은 것 같다. 하지만 30이라도 확실히 내 것으로 만들었다는 것이 중요한 거 같다.

1. 과제내용

STEP01 - 기능 추가 및 테스트 구현

포인트 충전, 사용에 대한 정책 추가 (잔고 부족, 최대 잔고 등)
4가지 기본 기능 (포인트 조회, 포인트 충전/사용 내역 조회, 충전, 사용)에 대한 구현
4가지 기본 기능에 대한 테스트 작성
단, 이때 /database 패키지의 구현체는 수정하지 않고, 이를 활용해 기능을 구현함

STEP02- 동시성 학습 및 구현

동일한 사용자에 대한 동시 요청에 대한 테스트를 먼저 작성함
이후 해당 테스트가 정상적으로 처리될 수 있도록 개선함
선택한 언어에 대한 동시성 제어 방식 및 각 적용의 장/단점을 기술한 보고서 작성 ( README.md )

https://github.com/seuthootDev/hanghae99-backend-week1/pull/1

Step01 by seuthootDev · Pull Request #1 · seuthootDev/hanghae99-backend-week1

커밋 링크 서비스 테스트 코드 완료 : a6be6b5 레포지토리 테스트 코드 완료 : 03d7c51 컨트롤러 테스트 코드 완료 : 3a64440 통합 테스트 코드 완료 : 15741d8 리뷰 포인트(질문) 리뷰 포인트: 테스트에서

github.com

https://github.com/seuthootDev/hanghae99-backend-week1/pull/2

Step02 by seuthootDev · Pull Request #2 · seuthootDev/hanghae99-backend-week1

커밋 링크 tset: 동시성 테스트 케이스 추가 : dd5fb01 tset : 서비스 동시성 제어 : 3562bea 리뷰 포인트(질문) 리뷰 포인트: 동시성 제어 구현 현재 포인트 시스템에 사용자별 뮤텍스를 적용하여 동시성

github.com

과제는 기본, 심화 2가지 step이 있었고, 개별 브랜치로 pr해서 링크를 제출하는 방식으로 제출했다.

2. 과제 진행 과정

이번 과제는 TTD 기반의 포인트 충전 API 작성 + 동시성 제어였다

TDD란 Test Driven Development의 약자로 ‘테스트 주도 개발’이라고 한다.

반복 테스트를 이용한 소프트웨어 방법론으로 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다. 특징적인 것은 "테스트 코드를 먼저 작성하는 개발 방법론"이라는 것이다.

이번 과제에서는 동시성 제어보다 TDD에 더 많은 시간을 쏟게 되었다. 웹 개발 자체에 익숙하지 않다 보니 기능 구현에 많은 시간이 필요했고, 테스트 코드를 작성하는 데에도 상당한 시간을 투자하게 되었기 때문이다.

이번 과제를 통해 테스트 코드의 필요성과 유용성에 대해 깊이 생각해보는 계기가 되었다. 항해 본 과정을 시작하기 전에 동기들과 함께한 사전 스터디에서는 Postman을 사용해 수동으로 테스트를 진행했었는데, 테스트 코드를 작성해서 자동화하는 방식이 훨씬 효율적이였다.

사실 지금 다니는 회사에서는 테스트 코드를 따로 작성하지 않고 있었지만, 지난주에는 내가 작성한 모든 파일에 테스트 코드를 작성했다. 테스트 도구를 활용한 것은 아니지만, Python 프로젝트에서 main.py를 실행하는 방식 대신, 의존성 있는 파일을 직접 실행해서 테스트할 수 있도록 구성했다. 이 과정에서 직접 Mock 클래스를 구현해 사용했는데, 과제를 통해 처음 접한 ‘모킹’이라는 개념을 바로 실무에 적용했다는 것이 신기했다. 실무 환경은 웹 개발이 아니지만, 테스트라는 개념은 개발 전반에 걸쳐 통용될 수 있다는 점에서, 나만의 개발 철학이 하나 생긴 것 같았다.

심화 과제였던 동시성 제어는 async-mutex 라이브러리를 활용해 구현해보았지만, 시간 부족으로 깊이 있게 학습하지는 못했다. 다행히 3~4주차 과제에서 다시 다룰 기회가 있다고 하니, 그때는 더 시간을 들여 제대로 학습해보고 싶다.

3. 어려웠던 점 & 해결 방법

TDD 관련해서 어려웠던게 몇가지 있는데,
- TDD 싸이클은 얼마나 지켜야 하지?
- 테스트 커버리지는 목표를 어느정도로 잡아야하지?
- 모킹은 언제 활용하고 또 언제 활용하면 안 되지?

이 외에도 고민이 많았지만, 공통점은 모두 '명확한 정답이 없는 문제'라는 점이다.

항해에서는 매주 팀별로 코치님과의 온라인 멘토링 시간이 주어지며, 다른 팀의 멘토링을 청강하는 것도 허용된다. 나 또한 우리 팀뿐만 아니라 다른 팀의 멘토링, 전체 Q&A 시간을 적극 활용하면서 여러 인사이트를 얻었고, 결국 나만의 결론에 도달했다.

그 결론은 바로 "비즈니스적 가치를 기준으로 판단하자"였다.
TDD 사이클처럼 ‘방식’ 자체에 너무 얽매일 필요는 없고, 상황과 조건에 따라 유연하게 접근하는 것이 더 중요하다고 느꼈다. 테스트 커버리지나 모킹 여부도 마찬가지다. 정답이 아닌 ‘적합한 선택’을 하는 것이 핵심이다.

물론 아직 나는 상황 판단의 눈이 충분히 갖춰져 있진 않다. 그래서 이번에는 기본을 최대한 지키되, 생산성과 효율을 고려한 융통성을 곁들이는 방식으로 접근했다.
예를 들어, TDD의 원칙은 ‘레드-그린-리팩터’ 순서지만, 작업 중에는 먼저 그린 단계(기능 구현)를 진행한 뒤 테스트 코드를 작성하는 경우도 있었다. 그 방식이 개발 흐름과 생산성을 더 잘 살려준다고 판단했기 때문이다.

4. TypeScript 팀 화이팅

우리 팀은 정말 실력자들로만 구성된 것 같다. 물론... 나를 제외하고 말이다.
이게 팔이 안으로 굽는게 아니라, 진심으로 그렇게 생각하고 있다. TypeScript 언어는 물론, NestJS 프레임워크 활용 능력이나 개발에 대한 철학까지 모두 다들 뛰어난 분들이다.

항해에서는 사용하는 언어 기준으로 팀을 나누는데, TS를 사용하는 팀은 우리 팀이 유일하다. 이유는 정확히 모르겠지만, 우리나라에서는 아직 TypeScript를 사용하는 회사가 별로 없기 때문이라고 생각한다.

그런데 솔직히 말하면, 지금 이 상황이 나에게는 오히려 좋은 기회다.
항해에서는 매주 랜덤 코드 리뷰를 진행하는데, 팀을 섞어서 다른 사람들과 코드 리뷰를 하게 된다. 실력자들은 다양한 시각과 네트워킹을 위해 매주 새로운 사람들과 리뷰하는 걸 좋아할 수 있지만, 나는 아직 초심자라서 내 실력을 잘 파악하고, 정확한 피드백을 줄 수 있는 우리 팀원들과 꾸준히 리뷰를 할 수 있는 점이 오히려 더 큰 행운이라고 느낀다. 오늘도 팀원들로부터 정말 많은 피드백을 받았고, 하나하나가 큰 도움이 되었다. 팀원들에게 진심으로 감사하다.

회사에서는 주로 혼자 개발을 하다 보니 협업의 경험이 부족했는데, 이번 과제를 하며 팀원들이 실무에서 협업하는 방식, 코드 리뷰에서 나오는 다양한 시각들을 접하면서 많은 인사이트를 얻고 있다. 단순히 기술적인 성장을 넘어, 협업하는 개발자로서도 한 걸음 나아가고 있는 느낌이다.

5. 다음 주 목표 & 다짐

이번 주 과제는 다행히 기본 과제와 심화 과제 모두 PASS를 받았다.

다음 주에도 좋은 결과를 얻기 위해서는 일요일부터 화요일까지의 시간을 어떻게 쓰느냐가 정말 중요하다고 생각한다. 특히, 코치님과의 멘토링 시간을 효과적으로 활용하려면 사전 학습이 필수다.
사실 지난주 멘토링 때는 준비가 부족해서, 멘토링이 끝난 뒤에야 "아, 그때 이걸 물어봤어야 했는데..." 하는 아쉬움이 많았다.

또한 애초에 과제를 하는 시간이 넉넉하지는 않다. 그래서 이번 주는 화요일 전까지 기본 과제를 마무리하고, 남은 시간 동안 심화 과제를 더 깊이 있게 학습하는 것을 목표로 삼았다.
이번에는 더 효율적인 시간 활용과 준비를 통해, 더 의미 있는 한 주를 만들어보고 싶다.

항해 추천인코드:NYFKU8

20만원 할인 받으세요~

항해 플러스 백엔드 9기를 시작하는 마음(항해 추천인코드 있음)

seuthootdev — Sat, 5 Jul 2025 23:49:43 +0900

1. 지금까지의 개발자 커리어 회고

나는 약 2년간 영업관리직으로 근무하다, 현재는 파이썬 기반의 데스크톱 애플리케이션 개발자로 1년 넘게 일하고 있다.

영업직을 그만두고 새로운 직장을 찾던 중 문득 이런 생각이 들었다.
“전 회사에서 배운 생산라인, 공정, 물류 시스템, 전산, 상품 지식들이 다른 회사에서는 무용지물 아닌가? 내가 정말 영업에서 내세울 만한 게 있을까?”

이러한 고민 끝에, 변화가 많은 환경에서도 통용될 수 있는 ‘기술’을 가진 사람이 되고 싶다는 결심을 하게 되었고, 그렇게 개발자의 길에 들어섰다. 늦은 나이에 시작했지만 운이 좋게도 취업에 성공했고, 개발자로서의 인생을 시작하게 되었다.

2. 항해 플러스 참여 계기

하지만 개발자로 일하며 깨달은 것이 있다.
분야도 매우 넓고, 커리어의 방향성을 명확히 잡지 않으면 쉽게 헤맬 수 있다는 것이다.
또한 개발자라고 해서 자연스럽게 실력이 쌓이는 것이 아니라는 점이다.

특히나 우리 회사는 전문 IT 기업이 아니다 보니, 성장에 한계가 있음을 느꼈고,
혼자 독학으로 IT 관련 자격증 9개 취득하는 등 나름의 노력을 했지만, 한계가 있었다.
그래서 더 체계적으로 배우고 싶은 마음에 항해99 플러스에 지원하게 되었다.

3. 향후 5년 뒤 커리어 방향성

내가 개발자라는 직업에서 가장 매력을 느끼는 부분은 “혼자서도 서비스를 만들어 낼 수 있다”는 점이다.
사업은 보통 물리적인 공간, 재고, 사람이 필요하다. 하지만 IT 서비스는 상대적으로 훨씬 덜하다.

난 5년 뒤에는 나만의 서비스를 직접 만들었거나, 만들 수 있는 사람이 되고 싶다.
난 특히 서버리스 아키텍처에 관심이 많고, 가능한 한 운영과 유지보수가 필요 없는 시스템을 구축하고 싶다.

항해에서는 TDD 기반의 개발 방식을 제대로 익혀, 배포 전 높은 테스트 커버리지를 확보한 안정적인 서버리스 서비스를 만드는 것이 목표이다.

4. 10주간의 목표

매주 1회의 WIL작성:
매주 기록하며 생각을 정리하는 습관을 들이고 싶다.
과제는 마감기한 전까지 반드시 제출:
잘하든 못하든 끝을 보고 싶다.
토요일 오프라인 스터디 전회 참석:
우리팀은 매주 토요일 항해 회의실에서 오프라인 스터디를 진행한다. 모든 회차 참석하는 것을 목표로 하고 있다.
특히 난 발제 의도를 혼자서 온전히 이해하긴 어렵기 때문에, 팀원들의 도움이 절실히 필요할 것이라 생각한다.

5. 최종 목표 배지

블랙 배지를 목표로 하려고 한다.

작년 자격증 공부를 할 땐 “커트라인만 넘자”는 마음으로 임했다가 탈락하고 n수한 경험이 많았다.
이번 항해에서는 그때의 아쉬움을 반면교사 삼아, 처음부터 가장 높은 목표를 잡고 도전하려고 한다.

항해 추천인코드:NYFKU8

20만원 할인 받으세요~

seuthootdev 님의 블로그

항해+ 백엔드 코드 9주차 회고 : Kafka 메세지 큐

Kafka Overview

STEP 17 카프카 기초 학습 및 활용

STEP 18 카프카를 활용하여 비즈니스 프로세스 개선

회고

항해+ 백엔드 코드 8주차 회고 : Event 기반 Transaction

Implementation

STEP 15 Application Event

STEP 16 Transaction Diagnosis

항해+ 백엔드 코드 7주차 회고 : Redis의 자료구조와 활용

Strings

Sets

Sorted Sets

Redis 기반의 랭킹 시스템

개요

핵심 개념: Redis Sorted Set

기본 명령어 예시

1. 점수 추가 및 갱신

2. 특정 사용자 점수 조회

3. 전체 랭킹 조회 (높은 점수가 1등)

4. 특정 사용자 순위 조회

5. 점수 증가 (예: 게임 승리 시 점수 부여)

응용 예시: 일간 / 주간 랭킹 분리

키 구성 전략

TTL 설정

⚠️ 주의할 점

실전 활용 예시

인기 상품 조회 랭킹 (24시간 클릭 수 기준)

사용자 게임 랭킹

시각화 전략

✅ 요약

참고

과제

항해+ 백엔드 코드 6주차 회고 : 분산락 + 캐시

분산락 & 캐시 정리

1. 왜 필요한가?

2. Redis 기반 분산락

동작 방식

구현 방식

올바른 순서

3. 캐시(Cache) 활용

4. 정리

과제 링크

항해+ 백엔드 코드 5주차 회고 : 동시성 처리(Concurrency Control) 과제 정리 – 데이터 정합성과 성능 동시 확보하기 (항해 부트캠프 할인코드 있음)

목차

1. 과제 개요 및 목표

2. 동시성 관련 기본 개념

3. 전략 선택과 도메인 매핑

4. 3계층 락 구현 방식

5. 주요 코드 위치 및 테스트

6. 검증 및 성능 결과

7. 왜 이 전략이 타당한가?

8. 한계와 향후 계획

마무리 한 줄 요약

과제 링크

항해+ 백엔드 코드 4주차 회고

✍️ 이번 주 주제: 데이터베이스

과제 링크

️ 과제 요약

데이터베이스 설계 원칙

인덱스 & 쿼리 최적화 핵심

인덱스 설계 기준

쿼리 실행 계획 (Query Plan)

Covering Index

동적 확장성 고려

Sync Schedule 전략

데이터베이스 설계에 대한 소회

항해+ 백엔드 코드 3주차 회고

✍️ 이번 주 주제: 아키텍처

과제 링크

️ 과제 요약

STEP 05

STEP 06

아키텍처별 핵심 요약

1. 레이어드 아키텍처 (Layered Architecture)

2. 릴레이션 레이어드 (Layered + Interface / DIP 적용)

3. 헥사고날 아키텍처 (Hexagonal Architecture)

4. 클린 아키텍처 (Clean Architecture)

내가 선택한 아키텍처: 클린 아키텍처