백엔드 개발자

윤동준 (Dongjun Yun)

고등학교를 필리핀에서 마치고, 정규 CS 학위 과정 없이 독학으로 개발을 시작했습니다. 2020년 인플루언서 매칭 플랫폼을 창업해 0부터 혼자 만들어 가입자 3,000명까지 운영했고, 이후 배차·공동주택·학원 ERP 백엔드를 거쳐 경력 6년 4개월이 됐습니다. 현재는 청주시배드민턴협회의 회원관리·전자결재 시스템을 혼자 설계·개발·운영하고 있습니다. (컴퓨터공학 학위는 학점은행제로 2026년 취득 예정)

문제를 발견하면 알림을 붙이고, 반복되면 자동화합니다. 그래서 2026년에는 운영 서버의 에러를 LLM이 분석해 수정 PR까지 자동으로 올리는 파이프라인을 직접 만들어 실무에 투입했습니다.

백엔드 설계부터 배포·모니터링까지 혼자 세울 수 있습니다. 팀이 작고 맡을 범위가 넓을 때 가장 빠르게 기여합니다.

대표 성과

  • 장애 대응 공수 90% 절감 — 수동으로 분석·수정하던 PHP Fatal Error를 LLM 자동 분석 + PR 자동 생성 파이프라인으로 대체 (직접 만든 오픈소스 auto-code-fixer를 실무 투입)
  • 레거시 PHP를 Java/Spring으로 무중단 이관 — 10년 넘은 레거시를 멈추지 않고 차세대 시스템으로 전환 (고객 학원 400여 곳, 사용자 1만 명)

  • 4 vCPU / 4 GB 단일 서버에서 상시 메모리 1.9 GB(여유 52%) 유지 — 앱·DB·모니터링을 한 대에 올린 1인 운영 환경

  • Email: ydj0617@gmail.com
  • GitHub: github.com/yuneast
  • Blog: yuneast.github.io

기술 스택

Backend: Java, Spring Boot, JPA, QueryDSL, Python, FastAPI, Celery, PHP

Frontend: TypeScript, React, Next.js (App Router)

Database: PostgreSQL, MySQL, Redis, Flyway

운영: Docker, AWS, GitHub Actions, Caddy, Uptime Kuma, pg_stat_statements

대표 프로젝트

auto-code-fixer — LLM 장애 자동 수정 파이프라인

github.com/yuneast/auto-code-fixer · Python, Claude Code SDK, GitHub API

운영 서버에서 에러가 발생하면 오류 로그를 수신해 레포를 clone하고, LLM이 코드를 분석·수정한 뒤 브랜치·커밋·PR까지 자동으로 올리는 서버입니다.

사람이 로그를 열어보기 전에 수정 PR이 먼저 올라와 있는 상태를 목표로 만들었습니다. 실무(공부선배)에서는 AWS CloudWatch Logs의 오류를 탐지 트리거로 붙이고, Celery 비동기 큐로 분석 요청을 처리하도록 연동했습니다. 같은 오류가 반복될 때 알림과 PR이 쏟아지는 문제는 TTL 기반 중복 제거로 막았습니다. → PHP Fatal Error 대응 공수 90% 절감

  • [선택 근거] Slack 알림만 붙이는 방식(여전히 사람이 수동 처리) · 애플리케이션 내부에 자동화를 넣는 방식(배포와 결합도 상승) 대비, DevOps 전담 인력이 없는 환경에서는 독립 서버로 분리한 파이프라인이 운영 부담이 가장 작다고 판단해 채택

경력

청주시배드민턴협회 — 백엔드·풀스택 (2026.02 ~ 재직 중)

회원관리 + 이적동의서 전자결재 시스템 · cjbadminton.kr

청주시 전역의 배드민턴 동호회·회원을 협회가 전수 온보딩하는 시스템입니다. 기획·설계·개발·배포·운영을 혼자 합니다. 서버는 단일 VPS 4 vCPU / 4 GB — 스케일아웃 없이 이 안에서 버티는 것이 전제입니다.

핵심 성과:

  • 이적동의서가 종이 서명 → 카카오톡 전달 → 협회 카페 업로드로 처리되던 탓에 이력 추적이 불가능하고, 기존 동호회가 승인을 거부하거나 방치하면 절차 자체가 멈췄습니다 (지역 언론에 보도된 반복적 갈등) → 4단계 전자결재 워크플로우로 전환하고 7일 미응답 시 협회 직권처리 + 사유 입력 필수화를 규칙으로 못박음 → 분쟁이 교착되지 않고, 거부·직권처리 사유가 모두 이력에 남는 구조
    • [선택 근거] 단순 서류 업로드 게시판(이력 추적 여전히 불가) · 범용 전자결재 SaaS(협회 직권처리 같은 도메인 규칙 반영 불가) 대비, 분쟁 해결 권한을 워크플로우에 내장할 수 있는 자체 구축을 선택
  • 회원명부 엑셀 대량 업로드 중 메모리가 피크 3.1 GB / 4 GB까지 치솟는 것을 직접 붙인 Netdata로 관측 → 행마다 반복 실행되는 매칭 쿼리를 원인으로 특정 → 쿼리 배치 처리 + 응답 비동기 전환, 처리자명 조회를 루프당 1회로 축소(N+1 제거) → 업로드 응답 지연 해소, 피크 메모리 완화
  • 협회가 미리 올려둔 회원 명단과 본인이 만든 계정이 분리되어 이력이 끊김 → 이름+연락처 정확 일치만 자동 연동해 기존 소속·이적 이력을 신규 계정이 승계. 부분 일치까지 허용하면 타인의 이적 이력이 섞이므로 가입 편의보다 데이터 무결성을 우선하고, 미일치 건은 가입을 막지 않고 관리자가 사후 배정

주요 업무:

  • 백엔드 13개 도메인 설계·구현, 권한 4단계 RBAC, SMS 본인인증(회원가입·아이디/비밀번호 찾기)
  • 친선경기(랜덤 복식)·토너먼트·조별리그 대진표 생성 엔진 — 급수 반영 자동 팀 편성, 동시 점수 제출 시 중복 방지
  • Next.js App Router 프론트엔드 전체 (공개 페이지 / 인증 / 3종 관리자 대시보드)
  • 운영 기반 직접 구축 — 상태페이지·텔레그램 장애 알림·슬로우 쿼리 로깅·리소스 대시보드, prod DB를 앱과 별도 lifecycle로 격리(재배포가 DB 무영향), Caddy 자동 HTTPS, 매일 pg_dump → Cloudflare R2 백업, Flyway 마이그레이션 45개
  • 설계 문서 29건을 먼저 쓰고 구현, 커밋 832건, 백엔드 테스트 114개

기술: Java, Spring Boot, Gradle, PostgreSQL, Flyway, Next.js, TypeScript, Docker, Caddy

(주)공부선배 — 백엔드 (2024.08 ~ 2025.12)

학원 운영관리 ERP · 고객 학원 400여 곳, 사용자 1만 명 B2B 멀티테넌트 · 인증·알림·대시보드 도메인 90% 담당

등·하원 시간대에 요청이 몰리는 피크 구조라, 평소에 괜찮던 쿼리가 그 시간에 터집니다.

핵심 성과:

  • 10년 넘은 PHP 레거시 위에 기능을 계속 쌓던 상황 → 레거시 PHP를 Java/Spring으로 이관하는 차세대 시스템 구축을 주도 (해당 레포 최다 기여) → 서비스를 멈추지 않고 레거시와 신규 시스템을 병행 운영하며 전환
    • [선택 근거] 전면 재작성(서비스 중단 + 일정 리스크) 대비, 레거시 PHP의 동작을 100% 호환하는 신규 Java API를 먼저 만들고, PHP가 DB를 직접 조회하던 지점을 신규 API 호출로 하나씩 바꿔 끼우는 방식을 택해 무중단으로 전환
  • PHP Fatal Error를 매번 사람이 열어보고 고치던 구조 → LLM 자동 오류 분석 + 수정 PR 생성 파이프라인 구축 → 장애 대응 공수 90% 절감 (위 auto-code-fixer)
  • 3개 서비스(ERP, 입시설계, 마켓)의 로그인 정보가 각각 다른 테이블에 흩어져 있었음 → 중앙 인증 서버 분리를 직접 제안하고 타팀과 협업해 쿠키 기반 통합 인증 구축 → 1시간 점검으로 무중단 전환. 전환 후 Refresh 토큰 동시 요청으로 401이 발생하자 Redis 싱글플라이트로 갱신을 1회로 단일화하고 토큰을 원자 연산(GET+DEL)으로 소비해 멱등 처리 → 동시 요청 시 401·중복 발급 차단
  • 슬로우 쿼리 다수 → 실행 계획을 보고 원인별로 다르게 처리: 날짜 필터의 YEAR()/MONTH() 함수 때문에 인덱스를 못 타던 쿼리를 range 조회로 전환, 중첩 서브쿼리는 CTE + EXISTS로 재작성, 출석 조회는 Derived Table로 튜닝 → 슬로우 쿼리 0건 유지

주요 업무:

  • 크론 서버 헬스 체크 + 스케줄러 로그 모니터링, 타임아웃 시 Naver Works 자동 알림 → 장애 대응 시간 50% 단축
  • 정상 사용자가 WAF에 차단되는 원인을 즉시 알 수 없던 문제 → 차단 이벤트 발생 시 CloudWatch Logs Insights로 차단 룰을 조회해 사유까지 함께 알리는 운영 도구 구축
  • 반복되던 SQL 에러를 Repository 계층 Prepared Statement 적용으로 제거, 컨트롤러에 몰린 로직을 Service-Repository 패턴으로 리팩토링
  • 요구사항이 불명확하면 PM에게 직접 확인하고 팀 미팅을 주도해 스펙 확정, PR 자동 어사인 기반 코드 리뷰

기술: Java, Spring Boot, JPA, QueryDSL, Python, Celery, PHP, MySQL, Redis, Docker, AWS CloudWatch

가나다콜 — 백엔드 단독 (2023.03 ~ 2024.07)

고소작업차 실시간 배차 서비스 · 기사 2,000명, 일 배차 30~40건 · 백엔드 전체를 혼자 담당

수주 요청이 뜨면 조건에 맞는 기사 여러 명에게 동시에 뿌려지고, 먼저 누른 한 명에게만 배차되는 구조입니다.

핵심 성과:

  • 하나의 배차 건에 기사 20~30명이 동시에 수주를 눌러 중복 수락이 발생했습니다 → Redis 분산 락으로 동시성 제어 → 중복 수락 재발 없음
    • [선택 근거] DB 트랜잭션 락(락 보유 시간 증가, DB 부하) · 낙관적 락(충돌 시 재시도로 기사 쪽 UX 저하) 대비, 이미 쓰던 Redis 인프라를 활용하면서 ms 단위 TTL 제어가 가능한 분산 락을 채택
  • 기사 앱이 새 수주를 알려면 주기적으로 서버를 찔러야 했고, 그만큼 배차가 늦게 떴습니다 → SSE로 서버에서 기사 앱으로 수주를 밀어주고, 앱이 닫혀 있을 때는 FCM 푸시로 보완 → 새 수주를 즉시 전달
  • 차고지 기준으로 알림을 일괄 발송해 무관한 지역 기사에게도 알림이 갔음 → 사용자 실시간 위치 기반 GIS + 반경 설정 구현 → 불필요한 알림 60% 감소

주요 업무:

  • 배차 아키텍처와 매칭 엔진 설계, 주문·배차·정산 도메인 구현 (엔티티 26개, API 66개)
  • 백엔드 외에 기사용 Flutter 앱과 관리자 웹(React)까지 직접 개발
  • JWT + Spring Security 인증, 로그인 실패까지 남기는 감사 로그, SpringDoc API 문서화

퇴사 후 유지보수: Python/FastAPI로 돌던 서버를 Java/Spring Boot로 전면 이관하고 레거시 7,722줄 제거. 백엔드·관리자·앱을 모노레포로 통합해 Docker Compose + Makefile로 배포를 단일화.

기술: Java, Spring Boot, JPA, QueryDSL, MySQL, Redis, SSE, FCM, Flutter, React

(주)유토빌 — 백엔드 (2021.09 ~ 2023.02)

공동주택 관리 서비스 · 20개 단지, 단지당 수백~수천 세대 · 개발팀 3명 중 백엔드 주도 · 필리핀 시장 서비스

입주민·관리사무소·경비실·본사 네 역할이 같은 데이터를 다르게 보는 시스템입니다. 백엔드를 혼자 맡아 21개 도메인, API 209개를 설계·구현했습니다.

핵심 성과:

  • 필리핀 현지 입주민이 관리비를 낼 수단이 없었음 → 현지 PG사(DragonPay)를 연동해야 했으나 REST가 아닌 SOAP/WSDL만 제공 → zeep으로 WSDL 클라이언트를 구성하고 SHA1 digest 서명·결제 토큰 발급 흐름을 직접 구현 → 페소 결제 처리
  • 역할이 4종인데 도메인이 21개로 늘어나며 라우터 등록과 권한 분기가 흩어짐 → 도메인·라우터를 선언만 하면 import_module로 자동 등록되는 구조와 역할별 라우터 분리 규칙을 세움 → 도메인을 추가해도 진입점 수정 불필요
  • 코드 리뷰 절차가 없고 주니어 2명이 기능을 단독으로 끝내지 못하는 상태 → PR 기반 리뷰 도입 + 멘토링 → 주니어 2명 독립 개발 가능 수준으로 성장

주요 업무:

  • 팀 기술 스택(Python/FastAPI) 선정과 백엔드 아키텍처 설계 주도
  • 방문차량 출입 관리 — QR 코드 발급, 경비실 입·출차 처리, 체류시간 산정, 주차비 정산 여부 관리
  • 시설 예약(최다 규모)·민원 처리(입주민 접수 → 경비·관리실 처리 3자 흐름)·관리비 조회/대납·택배 수령 알림·단지 투표·공지/게시판·중고 장터·부동산 매물
  • 수동 배포를 GitHub Actions CI/CD로 전환하고 배포 트리거를 PR 머지로 단일화, 홈케어 이커머스 추가 시 쿠키 기반 통합 인증으로 무중단 전환
  • Google Geocoding 연동(주소 → 위·경도), 업로드 10MB 초과를 본문 읽기 전에 차단하는 커스텀 미들웨어

기술: Python, FastAPI, SQLAlchemy, Pydantic, MySQL, JWT, Docker, GitHub Actions, PHP

콘디 — 창업자 / 풀스택 (2020.06 ~ 2021.08)

인플루언서-광고주 매칭 플랫폼 · 0부터 기획·설계·단독 개발, 가입자 3,000명

핵심 성과:

  • 블로거 지수 분석은 블로그 글 50개의 검색 노출을 각각 조회해야 했고, 초기에는 요청 안에서 글마다 프로세스를 띄워 병렬 조회하고 전부 끝날 때까지 기다리는 구조였습니다 → 분석이 도는 동안 Django 워커가 점유돼 동시 요청이 들어오면 서버 전체가 멈춤 → Celery 비동기 큐로 분석을 요청 처리에서 분리 → 동시 분석 요청 시 502 에러 제거
    • [선택 근거] 프로세스 수를 줄이는 방식(분석 시간만 길어짐) · 요청 타임아웃 연장(원인 미해결) 대비, 분석을 요청 생명주기에서 떼어내는 것만이 워커 점유를 없앤다고 판단해 큐 분리 채택
  • 같은 블로그를 다시 조회할 때마다 글 50개를 전부 다시 크롤링 → 분석 결과를 3일간 재사용하는 캐시 계층 도입(Redis) → API 응답 시간 5초 → 즉시 응답

주요 업무:

  • 블로거 지수 산출 알고리즘 설계·구현 — 네이버 블로그 RSS 파싱 → 글 수 부족에 페널티 가산 → 글별 태그를 키워드로 꺼내 검색 노출 조회 → 점수 합산 → 최적 / 준최 / 일반 3등급 판정
  • 아임포트 PG 연동 — 결제 완료 후 서버에서 결제 정보를 재조회해 금액·상태를 대조한 뒤에만 캠페인을 활성화해 위변조로 무료 등록되는 경로 차단
  • 구독 + 크레딧 하이브리드 과금 — 무료는 조회권 차감, 유료 플랜은 무제한, 만료 시 자동 강등
  • 캠페인 매칭·회원·문의·관리자 기능까지 백엔드·프론트엔드(Django 템플릿 + SCSS) 전부 단독 개발

기술: Python, Django, MySQL, Celery, Redis, BeautifulSoup, 아임포트(PG), uWSGI

기술 블로그

yuneast.github.io — 실무에서 겪은 장애와 병목의 원인 분석, 그리고 그때 왜 그 방법을 골랐는지를 기록합니다. Redis 분산 락, SSE 실시간 처리, 레거시 PHP→Java 이관, LLM 자동 오류 수정 파이프라인, 4GB 단일 서버 운영 등 20편 이상.

학력 · 자격 · 병역

  • 학점은행제 컴퓨터공학 전공 (2025.04 ~ , 2026년 학위 취득 예정)
  • 브렌트 인터내셔널 스쿨 수빅 졸업 (2015.06 ~ 2016.12)
  • 네트워크관리사 2급 (2025.12)
  • 병역 면제 (장기대기 면제)