- 제약이 많은 환경에서 확장성과 복구 가능성을 고려한 서버 구조를 설계해왔습니다.
- 기술적 근거뿐 아니라 비즈니스 맥락을 반영해 엔지니어링합니다.
Java/Kotlin Spring JPA MySQL MongoDB Redis RabbitMQ Docker
아이템 대량 개봉 어드민 기능을 맡아 클러스터 내의 부하 분산 시스템을 설계해 부하를 절반 이상 감축했습니다.
- 경험: 인프라 제약 속에서도 안정성을 전제로 한 100만 건 처리 구조를 설계하며 대용량 처리/구조 설계 역량을 쌓았습니다.
- 배운점: “기술적으로 맞다”만으로는 부족하고, 운영·비즈니스 기준(리스크/우선순위/검증) 이 설계를 완성시킨다는 걸 체감했습니다.
3개 서비스의 메인 개발·운영을 맡으며, 레거시 개선과 관측성·복구 가능성 중심의 안정성을 더하고 있습니다.
- 연결성: 대용량·안정성 요구가 큰 도메인에서 강점을 확장하고, 운영으로 우선순위 판단/비즈니스 기준을 체화하고 있습니다.
- 경험: 레거시 개선으로 운영 리스크를 낮추고, 관측성·복구 가능성 중심의 플랫폼적 개선으로 안정성을 더했습니다.
- 배운점: 운영 이슈를 통해 무엇을 먼저/왜 해야 하는지, 비즈니스 기준으로 판단하는 감각을 길렀습니다.
- 평균 처리 시간 3h 32m → 1m 13s (x174)
- 단계별 트랜잭션 분리 + 실패 지점 추적/재시도 가능한 복구 구조 설계
- 운영 리스크(실패/재처리) 제거
비즈니스를 위한 고민 과정: ohksj77.tistory.com/283
- “100만 건 부하를 줄이는 방법”이 아니라 서버가 처리 여부를 자율 판단하도록 문제 재정의
- 사내 첫 RPC 기반 자율 판단 알고리즘/시스템 설계 및 대용량 처리 구현
- 100만 건 9분 처리, CPU 100% → 45%, Memory 60% → 20%
상세 설계와 기술적 탐구: ohksj77.tistory.com/274
- 설정 Heap 대비 1GB 추가 점유 원인을 off-heap 메모리 레벨에서 추적
- Lettuce 커넥션 600+개 누수 발견, 레거시 기능의 SCAN cursor 순회 후 RedisConnection 미반납이 근본 원인
- try-with-resources로 커넥션 반납을 강제하여 off-heap 1GB 추가 할당 제거
- requeue 메트릭 + 수집 API 추가로 재처리 상황 관측 가능성 향상
- 기존 인터페이스 호환성 유지, 변경 범위 최소화
- misfired trigger 예외 시 무한 실패 해결
- 에러 핸들링 개선으로 롤백/재시도 무한 루프 방지