Backend Engineer

김효현

서비스 기획부터 백엔드 아키텍처 설계, 인프라 구축, 성능 최적화까지 end-to-end로 수행해온 백엔드 개발자입니다.

실시간 시스템, 알림 시스템, 자체 인프라 구축 경험을 보유하고 있으며, 부하 테스트 기반 병목 개선과 배포 자동화를 통해 안정적인 서비스 운영 경험을 쌓았습니다.

또한 AI를 단순 생성 도구가 아닌 개발 생산성과 품질을 높이는 방향으로 활용하며, 반복 작업 자동화와 개발 흐름 최적화에 지속적으로 적용해왔습니다.

Github LinkdIn Blog Email

01 / Selected Work

Meezy.

온라인 회의를 진행하며, AI 기반 자동 요약과 피드백을 제공하고 발화·채팅·참여 시간을 분석해 참여도를 수치화하는 서비스

Period 2026.01.05 — 04.05

Role 백엔드 & PM

Repository GITHUB ↗

Tech Stack Java · Spring Boot · Spring AI · WebSocket · RabbitMQ · Redis · MySQL · Docker

프로젝트 개선 과정

AI EXPO에 BLIP이라는 이름으로 출품했으나, 일정 관리와 팀 운영, 커뮤니케이션의 한계로 인해 서비스 완성 단계까지 도달하지 못하고 기능 중심의 발표에 그쳤습니다.

그러나 이 과정에서 여러 기업 관계자들로부터 피드백을 받으며 프로젝트의 실질적 가치와 시장성을 검증할 수 있었습니다.

이를 계기로 프로젝트를 재정비하며 협업 구조를 우선적으로 설계했습니다. 역할 분담을 명확히 정의하고, 정기 공유 프로세스와 이슈 트래킹 체계를 구축한 뒤 Meezy.로 리브랜딩하여 프로젝트를 재개했습니다.

해당 운영 구조를 기반으로 1월 5일 프로젝트를 다시 시작했으며, 기술 구현뿐만 아니라 협업 프로세스 개선까지 포함한 개발 경험을 체계적으로 확장했습니다.

이 경험을 통해 협업 구조 설계가 프로젝트 초기 단계에서 선행되어야 한다는 점을 인식하게 되었고, 이후 모든 프로젝트에서 커뮤니케이션 체계를 우선적으로 수립하는 방식으로 개발 프로세스를 개선하고 있습니다.

아키텍처

Layered Architecture 기반, 변경 가능성이 높은 외부 인프라 영역에만 Out Port/Adapter 패턴을 선택적으로 적용
도메인 영역은 매퍼 계층의 반복적인 변환 비용을 제거하고 비즈니스 로직에 집중하기 위해 JPA 종속 설계를 수용

Bounded Context 및 Aggregate Root를 기준으로 패키지 구조를 설계여 도메인 단위의 변경 범위를 명확히 분리
도메인 객체가 유스케이스와 규칙을 직접 표현하도록 구성하여 코드만으로 시스템의 흐름과 설계 의도를 파악 가능한 구조 설계
비즈니스 규칙을 엔티티 내부에 캡슐화하는 Rich Domain Model을 적용하여 서비스 레이어에 로직이 분산되는 문제를 방지

주요 기여

화상 시스템 전환 (Jitsi API → WebRTC)

Jitsi API의 커스터마이징 한계로 WebRTC 기반 P2P 구조로 전환
참여도 측정·음성 데이터 수집 등 서비스 고유 기능과의 연동이 전환 이유
전용 Signaling 서버를 구현하고 coturn 기반 STUN/TURN 서버를 구축하여 안정적인 P2P 연결을 확보

회의 요약 전환 (Python AI → Spring AI)

팀 7명 → 2명 축소에 따라 별도 Python 서버의 운영 부담 증가
참여도 측정·음성 데이터 수집 등 서비스 고유 기능과의 연동이 전환 이유
Spring AI 기반 단일 파이프라인으로 통합해 배포 포인트 제거 및 운영 비용 절감

ArchUnit 아키텍처 테스트

아키텍처 설계 원칙이 문서에만 머무르지 않도록 계층 간 의존성과 패키지 규칙을 테스트 코드로 구체화
개발 과정에서 발생할 수 있는 설계 위반을 빌드 단계에서 조기에 탐지
설계와 구현 간 불일치를 사전에 방지

참여도 산출 모델 설계

단순 접속 시간이 아닌 실제 기여도를 반영하기 위해 참여율 산출 모델 설계
채팅(0.01)·발화(0.5)·참여시간(0.49) 가중치 기반으로 참여도 계산
Redis 기반 이벤트 저장 구조를 도입하여 장애 상황에서도 데이터 유실 방지

채팅 시스템

WebSocket을 통해 실시간 메시지 송수신 처리
RabbitMQ를 활용해 메시지 전달과 처리를 비동기적으로 분리
메시지 수신(WebSocket)과 저장/처리(RabbitMQ Consumer)를 분리하여 서버 장애 상황에서도 메시지 유실 최소화

협업 프로세스 & 문서 관리

정기 공유 프로세스와 이슈 트래킹 체계를 도입하여 정보 전달 누락과 작업 중복 문제 개선
Overview(목표·일정) / Team Docs(운영 규칙) / Tech Docs(아키텍처·API) 3단 구조로 문서 중앙화
프로젝트 온보딩 비용 최소화

트러블슈팅

비동기 환경에서 파일 데이터 유실 발생

Async / MultipartFile Lifecycle Issue

문제

비동기 처리 구조에서 MultipartFile 전달하는 과정에서 FileNotFoundException 발생

원인 분석

MultipartFile은 서블릿 컨테이너가 관리하는 임시 파일 참조로, HTTP 요청 종료 시 자동 삭제 → @Async 스레드와의 생명주기 불일치가 원인

해결 방법

요청 생명주기에 종속되지 않도록 파일 데이터를 메모리 기반 byte[]로 복사하는 방식으로 구조를 변경

성능 최적화

녹음 업로드 성능 최적화

140명 동시 접속 / 41.2MB 음성 파일 업로드 / Gatling

배경

S3 업로드를 @Transactional 내부에서 수행하여 네트워크 I/O 동안 DB 커넥션이 장시간 점유되었고, 동시 요청 시 커넥션 풀 고갈로 요청 대기 및 타임아웃이 발생. 또한 비동기 처리 경로는 무제한 스레드 생성 구조로 인해 과부하 시 작업 유실 위험 존재.

접근

트랜잭션과 외부 I/O를 분리하는 과정에서 드러난 병목을 기반으로, 비동기 실행 구조를 점검하고 스레드 풀 제한 및 업로드 경로 비동기화를 단계적으로 적용.

해결

S3 업로드를 비동기 처리로 전환하고 요청-응답 경로를 경량화했으며, bounded thread pool과 CallerRunsPolicy를 적용해 과부하 상황에서도 작업 유실 없이 처리되도록 개선.

성공률

93.6 → 100%

+6.4%p

P50 응답시간

18,107 → 321ms

56× 개선

처리량

0.95 → 1.59 TPS

1.7× 향상

결과

병목 제거
운영 안정성 확보

회고

Retrospective — Meezy.

이번 Meezy. 프로젝트는 단순히 기술 경험을 넘어, 제가 프로젝트와 개발을 바라보는 관점을 크게 바꾸게 된 경험이었습니다.

Meezy. 프로젝트는 기존 BLIP 프로젝트를 기반으로 현재 서비스 상황과 요구사항에 맞춰 구조를 재설계하며 재개발한 프로젝트입니다. 기존 Jitsi API 기반 구조를 WebRTC 기반으로 전환하면서 실시간 통신 구조를 깊이 있게 학습할 수 있었으며, Python AI Server를 Spring AI Server로 이전하며 운영 효율성과 유지보수성을 함께 고려한 구조 개선을 경험할 수 있었습니다.

프로젝트를 진행하면서 저는 단순히 잘 작동하는 서비스가 좋은 프로젝트라고 생각했던 관점이 바뀌게 된 계기가 되었습니다. 이제는 사용자뿐 아니라 개발자 입장에서도 잘 동작하는 프로젝트가 중요하다고 생각합니다. 사용자는 안정적으로 서비스를 이용할 수 있어야 하고, 개발자는 지속 가능한 코드와 구조 위에서 원활하게 협업할 수 있어야 한다고 느꼈습니다.

특히 이번 프로젝트를 통해 협업 구조의 중요성을 크게 느꼈습니다. 기존 BLIP 프로젝트에서는 문제가 발생했을 때 프론트엔드와 백엔드 간 충분한 소통 없이 각자 해결하려는 방식이 반복되었고, 그 과정에서 일정 지연과 의사결정 문제가 발생했습니다. 결국 AI EXPO에서는 완성된 서비스를 선보이지 못해 아쉬움도 컸지만, 동시에 여러 기업 관계자들로부터 시장성과 가능성에 대한 긍정적인 피드백을 받으며 프로젝트를 다시 제대로 완성해보고 싶다는 동기부여를 얻을 수 있었습니다.

이후 Meezy. 프로젝트에서는 역할 분담, 정기 공유, 이슈 트래킹 체계 등을 새롭게 설계하며 협업 구조를 우선적으로 개선했습니다. 이 경험을 통해 저는 좋은 개발자는 단순히 코드를 잘 작성하는 사람이 아니라, 함께 일하는 개발자들까지 편안하게 만들 수 있는 사람이라고 생각하게 되었습니다.

02 / In Progress

Movra.

매일 무너지는 계획의 원인을 신경과학적 메커니즘으로 분석하고, 그에 대응하는 행동 루프를 설계하여 학생이 정한 계획을 끝까지 실행하도록 유도하는 학습 행동 지속 서비스

Period 2026.03.13 ~ 알파 테스트 단계

Role Backend & Frontend & Infra

Repository GITHUB ↗

Tech Stack Spring Boot · WebSocket · MySQL · Redis · React 18.3 · TypeScript · Vite · TanStack Query · Docker · Cloudflare Tunnel

문제 재정의

Movra 프로젝트는 단순히 알정 관리 서비스가 아닌, "계획은 세우지만 반복적으로 실행에 실패하는 문제"를 뇌 과학 기반으로 접근하여 해결하기 위한 프로젝트입니다.

기존 생산성 서비스들은 일정 기록, 시간 관리, 할 일 분류 기능에 집중되어 있지만, 실제 사용자들은 계획을 세운 이후 실행 단계에서 더 큰 어려움을 겪고 있었습니다. 특히 고등학생 사용자들은 해야 할 일이 많아질수록 무엇부터 시작해야 할지 결정하지 못하거나, 계획을 실패한 이후 다시 올바르게 계획을 실천하지 못하는 패턴을 반복하고 있었습니다.

저는 이 문제를 단순한 기능 부족이 아니라, "뇌가 목표를 인식하고 행동으로 이어가는 과정"이라는 관점에서 문제를 재해석하여 행동 전환 구조의 문제로 바라봤습니다. 그래서 Movra 프로젝트는 단순 TODO 관리가 아닌 머릿속 계획을 외부로 꺼내는 과정, 오늘 반드시 해야 할 행동 하나를 선택하는 과정, 작은 행동부터 즉시 시작하도록 만드는 과정, 실패 이후 다시 복귀할 수 있도록 돕는 과정들을 통해서 사용자의 행동 지속을 지원하는 개인화 행동 지속 시스템을 목표로 프로젝트를 설계했습니다.

뇌 과학 기반 행동 설계

기능	설명
MindSweep + TopPick	사용자들은 해야 할 일이 많아질수록 오히려 행동을 시작하지 못하는 선택 피로 상태에 빠지는 경우가 많았습니다. 이를 해결하기 위해 MindSweep으로 머릿속 계획을 자유롭게 기록하게 하고, 그중 오늘 반드시 수행할 행동 하나를 TopPick으로 선택하도록 설계했습니다. 이 구조를 통해 계획 입력보다 "행동 시작 기준점"을 만드는 데 집중했습니다.
Recovery Card	기존 생산성 앱들은 연속 기록 유지나 실패 여부를 강조하는 구조가 많았지만, Movra 서비스는 실패를 자연스러운 행동 과정으로 바라봤습니다. 사용자가 하루 계획을 수행하지 못하더라도, 죄책감을 유발하기보다 다시 작은 행동부터 시작할 수 있도록 Recovery Card와 복귀 중심 UX를 설계했습니다.
Future Vision	사용자들이 목표를 세우더라도, 일상 속에서는 그 목표를 자주 잊고 현재 자극에 쉽게 휩쓸리는 문제가 있었습니다. 이를 해결하기 위해 Future Vision 기능을 설계했습니다. 이 기능은 단순 동기부여 요소가 아니라, 뇌의 RAS 기반 주의 필터 메커니즘을 참고해 설계했습니다. 특정 목표를 반복적으로 시각화하면 뇌가 해당 목표를 중요한 정보로 인식하고 일상 속 행동 선택에서도 목표 관련 자극을 더 자주 떠올리게 되는 효과를 기대할 수 있다고 판단했습니다.
감시자 시스템	혼자 공부할 때 쉽게 미루거나 흐름이 끊기는 문제를 해결하기 위해, 상호 동의 기반 감시자 시스템을 설계했습니다. 이 기능은 단순 소셜 기능이 아니라, 누군가 보고 있다는 인식만으로 행동 빈도와 집중도가 증가하는 호손 효과를 기반으로 설계했습니다.

주요 기여

Harness Engineering

AI 기반 개발 생산성을 높이면서도, 무분별한 코드 생성과 컨텍스트 오염 문제를 방지하기 위해 Harness Engineering 구조 설계
Layer Harness 아키텍처
- Layer 1: 규칙 문서(AGENT.md) : 자연어 기반 규칙 문서를 통해 AI 작업 범위와 구현 우선순위를 명시
- Layer 2: 작업 프로토콜(docs/workflow.md) : 구현 이전에 범위 분석, 성공 조건, 검증 계획을 먼저 정의하도록 작업 흐름 표준화
- Layer 3: 자동 검증(scripts/agent-verify.ps1) : lint/type-check/test·위험 코드 스캔까지 코드 레벨 검증 자동화
- Layer 4: Git Hook / 커밋 규칙 : 검증되지 않은 코드와 잘못된 커밋 메시지가 저장소에 반영되지 않도록 Git 단계에서 강제

Cloudflare Tunnel + 미니 PC 인프라

Infra 구조와 서비스 운영 과정을 직접 학습하기 위해 미니 PC 기반 자체 인프라 환경 구축
Docker 기반으로 백엔드 및 부가 서비스 운영
Cloudflare Tunnel을 활용해 공인 IP 없이 외부 HTTPS 접근 환경 구성

FCM 기반 알림 게이트웨이

여러 도메인에 흩어질 수 있는 알림 발송 로직을 NotificationGateway로 통합
사용자 알림 설정, 학교 시간/수면 시간 차단, 일일 발송 제한, 알림 타입별 발송 제한 등 공통 정책을 Gateway 레벨에서 일관되게 처리
Firebase Admin SDK 기반 FCM 발송 모듈을 구현하고 사용자별 다중 디바이스 토큰 순차 발송 지원
FCM 응답 중 만료되거나 해지된 토큰을 감지해 DB에서 자동 삭제하도록 구현해 토큰 생명주기 관리 안정화
알림 발송 실패가 핵심 비즈니스 로직 실패로 전파되지 않도록 sendSafely()와 발송 결과 enum 도입

DDD 기반 행동 지속 도메인 설계

단순 CRUD 구조가 아니라 "계획 → 실행 → 회고 → 복귀" 흐름 중심 서비스가 되도록 행동 지속 도메인 구조 설계
계획 변경이 실행 흐름에 자연스럽게 반영될 수 있도록 Domain Event 기반 동기화 구조 적용
Aggregate 간 결합도를 낮추고 장기적으로 회고/추천/통계 기능까지 확장 가능한 기반 구축

집중 세션 통계 & 추천 파이프라인

집중 세션 데이터를 단순 기록이 아니라 일일 요약/기간별 통계/추천 기능으로 확장 가능한 데이터 파이프라인으로 설계
FocusSession 원천 데이터를 DailyFocusSummary 스냅샷으로 집계하고 주간/월간 통계와 집중 시간대 추천 계산 구조 구현
raw 데이터와 summary 데이터를 함께 활용하는 조회 구조를 적용해 상세 기록 확인과 통계 조회 성능을 모두 고려

성능 최적화 I

Home 조회 기능 성능 최적화

홈 화면 API / Cache & Query Optimization & Exception Flow / Gatling

배경

홈 API에서 동일 데이터를 여러 서비스가 중복 조회하며 DB 왕복이 10회 이상 발생했고, 정상 흐름까지 Exception 기반으로 처리되어 응답 지연 발생.

접근

병목 원인을 단순 쿼리 수가 아닌 조회 구조의 문제로 파악하고, 서비스 간 중복 조회 흐름을 분석. 조회 목적에 맞게 Exception 기반 API를 Optional 반환 구조로 분리하고, 변경 빈도가 낮은 데이터는 Redis 캐시 대상으로 선정. 동시에 DailyPlan 중심 조회 구조를 재설계하며 fetch join 및 단일 조회 흐름으로 통합.

해결

FutureVision, ExamSchedule, NotificationPreference에 Redis Cache 도입. 사용자·날짜 기반 캐시 키 전략 및 TTL을 설계. DailyPlan + Task + Timetable 조회를 단일 흐름으로 통합하여 중복 로딩 제거 및 fetch join으로 N+1 차단. AccountabilityRelation 이중 조회를 단일 쿼리로 통합. 정상 상태 조회에서는 Optional 반환 구조를 적용해 Exception 생성 비용 제거.

Mean 응답

248 → 159ms

35.9% ↓

P95

404 → 204ms

49.5% ↓

P99

2790 → 1206ms

56.8% ↓

처리량

1.27 → 1.43 RPS

향상

성능 최적화 II

집중 통계 API 성능 최적화

Query Optimization & Redis Cache / Gatling

배경

집중 통계 API에서 집계되지 않은 날짜 구간(rawPeriods)마다 세션 데이터를 반복 조회하면서 N+1 문제가 발생했고, monthly 통계 기준 최대 16회 이상의 DB 왕복이 발생. 또한 이미 확정된 과거 날짜 통계도 매 요청마다 동일한 집계 쿼리가 재실행되어 응답 지연 발생.

접근

병목 원인을 단순 계산 로직이 아닌 DB 조회 구조 문제로 분석하고, daily/weekly/monthly별 조회 흐름을 분석. rawPeriod별 반복 조회를 전체 범위 단일 조회로 통합하고, 조회된 세션을 메모리에서 기간별로 필터링 및 overlap 계산하도록 변경해 DB 왕복을 최소화. 변경되지 않는 FINAL 상태 통계는 Redis 캐시 대상으로 선정하고, PARTIAL 상태는 캐시 제외하여 데이터 정합성 유지.

해결

FocusPeriodStatisticsCalculator의 rawPeriod별 N회 세션 조회를 findSessionsInRange 기반 단일 범위 쿼리로 통합. daily, weekly, monthly 집중 통계에 Redis Cache 도입. FINAL 상태 판별 로직을 StatsCacheKey로 분리하고 Clock 주입을 통해 테스트 가능한 구조로 개선. TTL 24시간을 적용해 반복 조회 시 DB를 우회하고 Redis hit 중심으로 응답하도록 최적화.

Mean 응답

84 → 26ms

69.0% ↓

P95

145 → 38ms

73.8% ↓

P99

170 → 47ms

72.4% ↓

20명 부하

100%

P95 50ms

회고

Retrospective — Movra

이번 Movra 프로젝트를 통해 단순히 기능을 구현하는 것을 넘어, 문제를 새로운 관점에서 정의하고 해결하는 경험을 할 수 있었습니다.

프로젝트는 저와 주변 사람들이 계획을 세워도 반복적으로 실패하는 모습을 보며 시작되었습니다. 저는 이를 단순한 의지의 문제가 아니라 소프트웨어적으로 해결할 수 있는 문제라고 생각했습니다. 하지만 기존 일정 관리 서비스와 같은 방식으로는 결국 같은 실패가 반복될 것이라 판단했고, 문제를 다른 관점에서 바라보고자 했습니다.

그 과정에서 "사람의 행동은 현재 뇌의 상태에 영향을 받는 것이 아닐까?"라는 생각을 하게 되었습니다. 단순히 습관이나 의지 부족이 아니라, 감정과 행동 흐름의 관점에서 문제를 접근해보고자 했고, AI Searching을 활용해 관련 논문과 자료를 조사하며 서비스 구조를 설계했습니다. 이를 통해 행동 지속 방식과 개인별 동기 요인 등을 분석하며 기능 방향성을 구체화할 수 있었습니다.

또한 이번 프로젝트를 통해 개발자의 역할에 대해서도 다시 고민하게 되었습니다. 단순히 요구사항을 구현하는 것이 아니라, 문제의 본질을 이해하고 해결 방향을 설계하는 과정 역시 개발자의 중요한 역할이라는 점을 깨닫게 되었습니다.

구현 과정에서는 문서와 실제 코드 간 차이, 높은 구현 난이도 등 여러 어려움도 있었습니다. 이를 해결하기 위해 AI Agent를 단순 자동화 도구가 아니라 문제를 함께 분석하고 검증하는 협업 도구로 활용했습니다. 다만 AI 결과를 그대로 사용하는 것이 아니라, 동작 원리와 구조를 직접 이해하고 개선하며 개발을 진행하고자 노력했습니다. 특히 프론트엔드 영역에서는 Harness 구조 기반으로 개발 프로세스를 정리하고, 큰 구조와 기준을 먼저 설계한 뒤 점진적으로 구현하는 방식으로 프로젝트를 진행했습니다.

이번 프로젝트는 기술적 성장뿐 아니라, 문제를 바라보는 시각과 AI를 활용하는 태도까지 다시 고민해볼 수 있었던 경험이었습니다. 현재 Movra는 알파 테스트를 진행 중이며, 고등학생 대상 정식 출시를 목표로 서비스를 준비하고 있습니다.