길현준
Backend Engineer / Platform Part Leader
Flex — 제약을 숨기지 않는 근무 계획기
결정론적 월간 allocator · 날짜별 제약 · Python/React 이중 검증
인정시간·실제 근무·휴가·일/주 상한을 하나의 결정론적 배분 계약으로 묶고, 달성 불가능한 목표는 초과 배정 대신 부족분과 이유로 표시하는 로컬 우선 근무 계획기
PythonReactTypeScriptFastAPIPlaywrightProperty TestingGitHub Actions
| 성과 지표 | 이전 | 이후 |
|---|---|---|
| 불가능 상태 | 강제 배정 위험 | insufficient_slots + gap (hard limit 유지) |
| 날짜 변경 범위 | 월 전체 재계산 위험 | 고정 날짜 + 나머지 재배분 (preview·재배분 경계) |
문제 해결 과정
목표 시간이 남은 가용 슬롯보다 커도 강제로 초과 배정하면 계획이 현실을 숨기는 문제
일·주 상한과 고정 계획을 먼저 적용하고 배정 가능한 시간을 계산한 뒤 부족분을 명시적 상태로 반환
→ 상한을 깨지 않고 insufficient_slots와 부족 시간을 화면에 표시
특정 날짜 변경이 월 전체 계획을 예기치 않게 덮어쓸 수 있는 문제
고정 날짜를 우선 잠그고 충돌 preview 후 나머지 날짜에만 결정론적 재배분 적용
→ 외부 시스템 쓰기 없이 preview에서 변경 범위와 충돌 경계를 표시
기술 선택 근거
- •기존 _minimum_activation 흐름을 복원해 최소 근무시간을 의무 시드가 아닌 선택적 활성화 하한으로 유지
- •외부 시스템 연동을 추가하지 않고 URL/로컬 상태로 재현 가능한 판단 표면 제공
주요 내용
- •고정 계획 우선·선택적 최소 활성화·hard-limit 유지의 단일 allocator 계약
- •달성 불가능 상태를 부족 시간과 원인으로 노출
- •날짜 override preview와 나머지 날짜 재배분 계산
- •synthetic scenario·공개 경계 scan·Python/Playwright CI
깨달은 점
- •최적화보다 먼저 불가능 상태를 정확히 모델링해야 계획기가 현실을 왜곡하지 않는다.
- •사용자 override는 전체 재계산보다 고정 범위와 나머지 배분 경계를 분리해야 예측 가능하다.
프로젝트별 AI CLI 런타임을 분리하고 검증하는 공개 런처
공개 런처 · AI CLI 3종 · contract demo
Claude Code·Codex·Kiro의 전역 상태를 프로젝트별 실행 경계로 분리하고, 잘못된 작업 경계와 설정 드리프트를 시작 전에 차단하는 공개 런처입니다.
| 성과 지표 | 이전 | 이후 |
|---|---|---|
| 런타임 격리 | 프로젝트가 전역 CLI 상태를 공유 | 등록 프로젝트별 런타임 홈 (세션·스킬·MCP·정책을 작업 경계별로 분리) |
| 경계 선택 | 이름·원격 저장소 기반 프로필 추정 위험 | 정규화 경로의 단일 소유 경계 선택 (경계 밖·이탈·모호함은 AI CLI 시작 전 중단) |
| 공개 검증 | 비공개 환경 설명에 의존 | 공개 launcher + contract demo + CI (로그인 없이 핵심 계약과 실패 동작 재현) |
문제 해결 과정
AI CLI의 전역 홈을 여러 프로젝트가 공유하면 세션·도구·규칙이 다른 작업 경계로 섞일 수 있었습니다.
등록한 프로젝트마다 Codex·Kiro 런타임 홈을 생성하고, 프로필 명령과 harness-exec가 같은 실행 정책을 사용하도록 통합했습니다.
→ 프로젝트별 런타임 상태를 분리하고, 공개 저장소의 설치·프로필·런타임 테스트로 동작을 검증합니다.
워크트리 실행기가 프로필을 이름이나 원격 저장소로 추정하면 잘못된 권한·도구 경계에서 에이전트를 시작할 수 있었습니다.
harness-auto가 현재 경로를 정규화하고 가장 구체적인 단일 등록 경계만 선택하도록 했습니다. 경계 밖·심볼릭 링크 이탈·동일 우선순위 중복은 거부합니다.
→ 프로필 추정 대신 경로 소유권을 사용하며, 선택이 확정되지 않으면 AI CLI를 실행하지 않습니다.
비공개 운영 환경만으로 설명하면 방문자가 프로필 분리와 근거 재확인 계약을 독립적으로 검증할 수 없었습니다.
공개 harness-launcher 구현·테스트와 별도 public contract demo를 연결했습니다. 데모는 프로필 고유성, 경로 이탈, 원문 SHA-256 드리프트, 관계 무결성을 표준 라이브러리 테스트로 확인합니다.
→ 로그인 없이 README·소스·CI에서 핵심 경계와 실패 동작을 재현할 수 있으며, 비공개 회사 데이터와 운영 인덱스는 공개 근거에서 제외했습니다.
콘서트 예약 서비스
GitHub ↗상세 ↗JPA 비관적 락과 낙관적 락 및 재시도 ↗Spring Boot 콘서트 예약 시나리오 동시성 문제 분석 ↗Spring Boot Redis를 활용한 분산 락 구현 ↗캐시(Cache)와 캐싱 전략(Caching Strategy) ↗
k6 설정값 3,000 requests/s · 최대 2,400 VU · 관측 예약 오류율 0.64% · Prometheus+Grafana
동일 좌석·사용자 지갑 동시성 테스트로 좌석에는 낙관적 락, 결제·충전에는 사용자 단위 Redisson 락을 적용하고, 공개 k6 보고서에서 캐시 스탬피드 p95를 5.74초에서 676ms로 낮춘 콘서트 예약 프로젝트
JavaSpring BootJPARedisMySQLKafkaDockerK6
| 성과 지표 | 이전 | 이후 |
|---|---|---|
| 예약 p95 | 5.74s | 676ms (캐시 워밍 + TTL 2분→5분) |
| 예약 오류율 | - | 0.64% (예약 시나리오 394건 실패 기록) |
| 대기열 p95 | - | 62.5ms (대기열 시나리오 오류율 0%) |
문제 해결 과정
동일 좌석에 100개 thread가 동시에 예약을 시도할 때 중복 예약 위험
ConcertSeat @Version 낙관적 락과 100-thread Spring 통합 테스트로 충돌 경로 검증
→ 테스트 종료 후 예약 행 1개와 reserved 상태를 assertion으로 확인
포인트 충전과 결제의 동시 실행 시 잔액 정합성 붕괴
Redisson 분산 락(userWalletLock:{userId})으로 사용자 단위 충전·결제 경로를 직렬화
→ 100-thread 충전 테스트에서 최종 잔액을 기대 합계와 비교하고 결제 테스트에서 단일 결제 상태를 확인
예약 부하 테스트에서 캐시 만료 구간의 stampede와 p95 5.74s 지연 관측
예약 시작 3분 전 캐시 워밍과 TTL 2분→5분 조정을 적용
→ 공개 보고서 기준 예약 p95 5.74s → 676ms, 설정 SLO 1s 이내
결제 이벤트의 저장·발행·실패 재시도 상태를 하나의 동기 호출에서 분리해야 했다
Kafka Transactional Outbox 패턴으로 결제 TX 내 PENDING outbox_event를 저장하고 scheduler가 비동기 발행
→ 결제 트랜잭션의 PENDING outbox 생성과 발행 실패 상태·재시도 경로를 코드와 테스트로 분리
기술 선택 근거
- •좌석 선점에 @Version 낙관적 락: 100-thread 동일 좌석 통합 테스트가 예약 행 1개를 assertion
- •결제·충전에 Redisson 사용자 단위 락: 100-thread 테스트가 결제 상태와 최종 잔액을 기대값과 비교
- •Redis Sorted Set 대기열: 입장 순서와 만료 상태를 score로 관리
- •결제 TX에서 PENDING outbox 생성 후 scheduler가 발행 실패 상태와 재시도 경로를 관리
주요 내용
- •동일 좌석 100-thread 통합 테스트에서 예약 행 1개 확인
- •사용자 지갑·결제를 Redisson 사용자 단위 락으로 직렬화
- •캐시 워밍·TTL 조정 후 공개 보고서 p95 5.74s → 676ms
- •결제 TX의 PENDING outbox와 scheduler 발행·재시도 경로 구현
- •k6 설정값 3,000 requests/s와 최대 2,400 VU를 관측 성과와 분리
깨달은 점
- •동일 좌석과 사용자 지갑의 경합 범위에 따라 낙관적 락과 사용자 단위 분산 락을 구분
- •k6 설정값·최대 VU와 보고서의 관측 결과를 분리해 성능 수치의 범위를 명확히 기록
Family Budget — 함께 기록하고 월말을 닫는 부부 가계부
매일의 수입·지출을 빠르게 기록하고, 공동·개인 부담과 목적통장, 예상 수입·고정지출·저축을 한 달의 판단으로 연결하는 부부 공용 가계부입니다.
TypeScriptNext.jsReactVitestVercel
| 핵심 시스템 설계 | 이전 | 이후 |
|---|---|---|
| 운영 정본 전환 | 스프레드시트 중심 입력과 해석 | 애플리케이션 정본 (과거 시트는 읽기 전용 가져오기 경계로 분리) |
| 계획 ≠ 실제 | 예상 규칙과 실제 입금·지출 혼동 | 규칙 · occurrence · actual 분리 (예상·실제·차이를 각각 추적) |
| 중복·불확실성 차단 | 후보가 있어도 새 실제 내역을 만들 위험 | 연결 우선 · 승인 · read-back (부분 성공과 reopen까지 명시적으로 처리) |
핵심 문제 해결
계획 항목을 실제 거래처럼 다루면 수입·지출이 중복 집계되고 월별 차이를 설명할 수 없었습니다.
→ 대시보드는 예상·실제·차이를 독립 계산하며 “계획은 실제 거래가 아니다”라는 계약을 유지합니다.
추가 백엔드 프로젝트
Gamebang — 서버 권위형 실시간 게임 공방(개인)— TypeScript, React, WebSocket, Cloudflare Workers상세 ↗
모바일 클라이언트는 행동만 요청하고 방별 Durable Object가 phase·turn·숨은 정보·재접속을 판정하는 5종 실시간 미니게임 서비스
임상병리사 채용 의사결정 대시보드(개인)— Python, FastAPI, SQLite, React상세 ↗
채용 플랫폼과 병원 채용 페이지 원천을 정규화해 탐색하고, 마감·지역·고용형태 추천 이유와 계정별 지원 상태를 함께 관리하는 모바일 우선 대시보드
대신물류 배차 운영 원장(개인)— TypeScript, Express, Next.js, React상세 ↗
외부 배차 정보를 오늘 날짜로 수집해 노선·차량 검색과 통계를 제공하고, 수집 중복과 브라우저 데이터 경계를 분리한 운영 원장
냠냠위듀 — 구내식당 식단 알림 봇(개인)— TypeScript, Playwright, Slack Bot API, Express상세 ↗
판교 이노밸리 구내식당 주간 식단표를 카카오 채널에서 Playwright로 크롤링하여 Slack으로 자동 발송하는 봇 — Clean Architecture + TSyringe DI, Slack Bot API 슬래시 커맨드, 재시도 최대 6회, DeliveryHistory 중복 방지
스타트업풀(팀)— NestJS, TypeScript, PostgreSQL, JavaScript상세 ↗
8인 크로스펑셔널 팀에서 창업 버티컬 네트워크 플랫폼의 백엔드를 전담 — NestJS 기반 커뮤니티 핵심 API 설계·구현, OAuth 2.0 소셜 로그인 4종 통합, 어드민 백엔드 독립 구축, 2개월 스프린트 협업