김영민

일하는 사람들과 함께, 더 나은 워크플로우를 만드는 개발자

자기소개

7년 경력의 소프트웨어 엔지니어 김영민입니다. 운영 중인 레거시 시스템에서 전환 경계를 식별하고, 서비스 연속성을 유지하며 단계적으로 현대화해왔습니다. 15개로 분산된 코드베이스를 설정 기반의 단일 구조로 통합하고, 보안 침해 사고가 발생한 취약 시스템을 2주 만에 전환한 경험이 있습니다.

TypeScript/NestJS를 주력으로 하며, 문제에 따라 Java, Bash, Python, PHP, C/C++, Lua를 가리지 않습니다. 보안 인증 제품, 메타버스 플랫폼, 교육 서비스, 비대면 결제까지 도메인을 넘나들며 구조적 문제를 해결해왔습니다. 정규식의 한계를 파서로 재설계하고, 레거시 개선 대신 전면 재구축을 비용·리스크로 판단하는 등 문제에 맞는 기술적 방향을 선택합니다.

구현 전에 사업적으로 필요한 수준을 먼저 판단합니다. 비개발 직군이 감수하던 불편함에서 개선점을 찾아, 콘텐츠 등록 소요를 1주에서 당일로, 운영팀의 개발 의존을 제거하는 방식으로 풀어왔습니다. 연동하는 동료가 직관적으로 이해할 수 있는 API를 지향합니다.

포트폴리오

바로가기

강점

문제의 구조를 먼저 파악하고 접근 방식을 재설계합니다 — 수정할수록 문제가 늘어나는 구조를 재설계하고, 서비스 간 강결합을 도메인 분리로 해결하는 등 근본 원인에 맞는 기술적 방향을 판단합니다
반복되는 비용을 구조로 제거합니다 — 동일한 수정을 15곳에 반복해야 하는 코드베이스를 단일 구조로 통합하고, 4개 앱을 하나로 합쳐 중복 작업을 근본적으로 없앴습니다
위기 상황에서 빠르게 판단하고 실행합니다 — 보안 침해가 발생한 시스템을 2주 만에 전면 재구축, 서비스 중단 없이 전환했습니다
비개발 직군의 개발팀 의존을 제거합니다 — 매번 개발팀을 거쳐야 했던 운영 업무를 담당자가 직접 처리할 수 있는 도구와 구조로 전환했습니다
연동 난이도가 낮은 시스템을 설계합니다 — 외부 파트너가 문서 전달 후 하루 만에 연동을 완료했고, 추가 판매처 확장 시 별도 개발 없이 적용 가능한 구조를 만들었습니다

핵심 기술:

언어: TypeScript, Node.js, Python, C/C++, PHP, Lua, SQL
프레임워크: Next.js, React, NestJS, FastAPI, Prisma, Expo/EAS
인프라: AWS, GCP, Docker, Nginx, Jenkins, GitHub Actions, Linux
설계: DDD, TDD, REST API 설계, 아키텍처 설계

경력 (총 7년)

(주)스마트러닝코리아 | 팀장 / 개발기획본부 (2025.03 ~ 현재)

구독 취소 관리 페이지 통합

[문제 및 배경] 운영팀의 반복적인 라이선스 회수 요청으로 문제를 인지. 인터뷰 결과 PG사 결제 취소가 자체 시스템에 연동되지 않고 운영팀용 라이선스 관리 도구가 없어 개발팀 개입이 반복적으로 필요했음.

[역할 및 해결 과정]

반복 요청 패턴을 보고 직접 미팅 요청, 운영팀이 결제사 사이트에서 취소 후 개발팀에 라이선스 회수를 요청하는 워크플로우 확인
"취소 자동화" 요청이 아닌 시스템 간 연동 부재가 근본 원인임을 파악
결제/라이선스 시스템 먼저 이관 후 단위 테스트로 검증
구독 시스템은 며칠간 수동 갱신으로 모니터링한 후 자동화

[성과 및 영향]

개발팀에 전달되던 취소/환불/라이선스 관련 요청이 더 이상 발생하지 않음
운영팀이 개발팀 개입 없이 취소·환불·구독 관리 자체 처리
결제 취소 후 서비스 접근 가능했던 보안 리스크 해소

[기술적 의사결정]

한 번에 전체 자동화하지 않은 이유: 결제/라이선스는 단위 테스트로 검증 가능하나, 매일 실행되는 구독 배치는 실제 운영 데이터로 모니터링 필요
단계적 접근으로 각 시스템의 안정성을 확인한 후 자동화 범위 확장

[스택] Next.js, TypeScript, PostgreSQL

영어 교육 콘텐츠 관리 시스템(CMS) 구축

[문제 및 배경] 영어 듣기 콘텐츠가 재생되지 않거나 이상하게 표시되는 오류가 반복 발생. 콘텐츠 운영팀이 SFTP로 파일 업로드 → URL 확인 → DBeaver로 JSON 데이터 입력하는 구조로 작업 중이었음. 전체 업로드 매뉴얼을 분석한 결과, 비개발자가 이 구조를 따라하는 것 자체가 문제임을 발견. 담당자들은 이 불편함을 당연하게 여기고 있었음.

[역할 및 해결 과정]

콘텐츠 담당자가 인식하지 못한 구조적 문제를 파악하고 개선안 제안
담당자들이 익숙한 엑셀 기반 작업 방식 유지, 100개 이상 대량 처리 패턴 고려
Next.js 기반 CMS 구현: CSV 템플릿 다운로드 → 미디어 업로드 → 데이터 입력 → 실시간 검증 → DB 반영
에러 메시지 한글화, 입력 시점에 스키마 검증으로 학습 곡선 최소화

[성과 및 영향]

콘텐츠 등록 시간: 1주일 → 당일 즉시
개발팀 검증 프로세스 불필요, 운영 업무 부담 80% 감소
담당자가 개발팀 개입 없이 자립적으로 콘텐츠 운영

[기술적 의사결정]

CSV 선택 이유: 담당자들이 교재를 데이터로 전환할 때 이미 엑셀 사용 중, 대량 처리에 적합
실시간 검증: 업로드 전 즉각 피드백으로 오류 사전 차단, SFTP/DBeaver 완전 제거

[스택] Next.js, Tailwind CSS, TanStack Query, Prisma, NCP Object Storage

멀티 판매처 쿠폰 API

[문제 및 배경] 기존 쿠폰 시스템은 파일로 생성 후 메일로 외부 판매처에 전달하는 방식. 쿠폰 라이프사이클 중 발급과 등록/사용 시점은 추적 가능하나, 그 사이 구간(판매·환불 등)은 전혀 추적되지 않아 정산 시 "실제로 몇 건이 팔렸는가"를 검증할 방법이 없었음. KB스타뱅킹 연동 기회에 사업 담당자에게 정산 가능 여부를 선제적으로 질문하여 API 신규 설계 착수.

[역할 및 해결 과정]

정산 신뢰성 문제를 먼저 예측하고 사업 담당자와 대화로 검증
연동하는 KB 개발자 입장에서 자연스러운 문장으로 읽히는 REST API 설계
엔드포인트 구성: POST /coupon(생성), GET /coupon/:id(상태 확인), PUT /coupon/:id/deactivate(비활성화) 등 엔티티와 행위가 명확한 구조
스토어 단위 API 키 생성·구분 기능으로 멀티 판매처 대응

[성과 및 영향]

KB 연동 테스트 하루 만에 완료 (문서 전달 → 즉시 연동 가능)
실시간 판매 추적, 환불 정책 지원으로 정산 신뢰성 확보
추가 판매처 연동 시 추가 개발 없이 즉시 적용 가능

[기술적 의사결정]

REST 설계 원칙: 엔티티(coupon)와 행위(deactivate, activate, cancel)를 분리해 직관적 이해 가능
API 키 구조: 스토어별 키 분리로 판매처별 매출 추적 및 권한 관리 용이

[스택] TypeScript, REST API

20년 레거시. 15개 저장소 통합으로 개발 속도 향상

[문제 및 배경] 동일한 버그 수정을 15개 저장소에 각각 반영해야 하는 상황. 20년 경과한 PHP 5.3 교육 플랫폼이 유료/테스트/무료 3개 버전 x 5개 모듈로 분리되어 SVN 15개로 관리 중. FTP 수동 배포로 긴급 패치에 하루 이상 소요, 재해 복구 체계 부재.

[역할 및 해결 과정]

개발팀원들과 각 저장소별 실제 배포 프로세스 확인, 중복 코드와 분기 로직 전수조사
15개 저장소 분석 후 단일 Git 저장소로 통합, 도메인별 분기 로직을 환경변수 기반으로 추상화
공통 모듈부터 통합 시작, 각 버전별 동작 검증 후 순차 확장
PHP 5.3/Apache2 → PHP 5.6/Nginx+PHP-FPM 전환

[성과 및 영향]

동일 수정 작업: 15회 반복 → 1회 (단일 코드베이스)
코드 중복 70% 제거, 신규 기능 개발 시간 66% 단축
긴급 패치 대응: 하루 이상 → 1시간 내 전체 버전 동시 배포
재해 복구 체계 확립

[기술적 의사결정]

Git 전환: 사내 SVN 인프라 부재, 브랜치 전략과 코드 리뷰 도입 용이
Nginx 도입: Apache 대비 30% 성능 향상, 동시 접속 처리 개선

[스택] PHP 5.6, Git, Nginx, Docker

2주 만에 보안 위협 제거 - EOL 스택 전면 재구축

[문제 및 배경] EOL 스택(CI 2.x, PHP 5.6)에서 실제 SQL 인젝션 공격 성공. 보안팀, 운영팀과 긴급 미팅을 통해 피해 범위와 추가 공격 가능성 파악. 레거시 부분 개선(예상 3개월)은 그 사이 추가 공격에 노출되는 리스크가 있다고 판단.

[역할 및 해결 과정]

레거시 개선 vs 재구축 비용·리스크 분석 후 경영진에 2주 재구축안 제안 및 승인
인증/인가 시스템을 사용하는 서비스 담당자들과 현재 연동 방식 파악
Next.js 15 + Prisma 기반 독립 API 서비스 설계, 타입 안전성 확보
다층 보안 아키텍처: JWT 인증, SQL Prepared Statement, XSS 방지, HTTPS 강제
Blue-Green 배포, 데이터 정합성 자동 검증, 롤백 플랜 수립

[성과 및 영향]

2주 내 완성으로 추가 공격 차단, 법적 리스크 제거
기존 서비스 무중단 전환 완료
최신 LTS 스택으로 향후 5년간 보안 패치 적용 가능 환경 구축

[기술적 의사결정]

Next.js 선택: 인증 API와 관리 페이지를 동시에 구축해야 하는 상황, 풀스택 프레임워크로 2주 내 완성 가능
Prisma 도입: Prepared Statement 기본 적용으로 SQL 인젝션 원천 차단, 타입 안전성과 마이그레이션 자동화

[스택] Next.js 15, Tailwind CSS, TanStack Query, Prisma

다중 브랜드 앱을 단일 프로젝트로 통합

[문제 및 배경] 동일한 버그 수정을 4개 앱에 각각 반영하다 일부 앱에만 적용되는 휴먼 에러 반복 발생. 개발팀원들과 배포 과정을 리뷰한 결과, 4개 React Native 프로젝트를 개별 관리하는 구조 자체가 문제임을 확인. 버그 추적 시 "어느 앱에서 발생한 건지" 파악하는 데만 시간 소요.

[역할 및 해결 과정]

각 테넌트별 실제 차이점(OAuth 키, 브랜딩, 리소스) 전수 조사, 공통 로직과 분기점 식별
공통 모듈부터 통합 시작, 한 테넌트씩 검증 후 순차 확장
Expo Config 활용: 테넌트별 차별화 요소를 환경변수로 추상화
npm 스크립트 기반 원터치 빌드 및 EAS 파이프라인 통합

[성과 및 영향]

동일 수정 작업: 4회 반복 → 1회 (단일 코드베이스)
배포 시간: 4시간 → 40분 (70% 단축)
휴먼 에러로 인한 앱별 버전 불일치 문제 해소
EAS Update로 긴급 패치 즉시 배포 (스토어 심사 대기 불필요)

[기술적 의사결정]

Expo 선택: 네이티브 모듈 추상화로 멀티 테넌트 관리 용이, EAS 생태계로 빌드·배포 일원화
환경변수 전략: 빌드타임(OAuth 키) vs 런타임(피처 플래그) 분리로 보안성과 유연성 확보

[스택] React Native, Expo, EAS, Firebase

주식회사비엔제트 | 소프트웨어 엔지니어 (2024.03 ~ 2025.03)

LLM 생성 콘텐츠의 편집 가능성 확보 - AI 교육 서비스 UX 개선

[문제 및 배경] LLM 기반 유사문제 생성 서비스에서 AI가 생성한 수학 문제를 선생님들이 실제 수업에 활용할 수 없는 문제. 결과물이 이미지로만 제공되어 한글(hwpx)에서 수식 편집이 불가능했고, 이로 인해 AI 서비스의 실사용 전환율이 낮았음.

[역할 및 해결 과정]

AI 생성 콘텐츠의 실사용성 문제를 전달받아 LLM 출력물과 사용자 워크플로우 간 간극 분석
초기 요청은 "hwpx로 변환"이었으나, "수정 가능해야 하나요?" 역질문으로 선생님들이 문제를 직접 편집해야 한다는 실제 니즈 확인
기존 오픈소스(한글→LaTeX)를 역방향으로 활용 시도했으나 구조상 불가능 확인, 문법 케이스만 참고하여 LaTeX→hwpx 변환 알고리즘 새롭게 설계
FastAPI 기반 변환 API 엔드포인트 설계 및 구현, 변환 로직 모듈화 및 단위 테스트 작성

[성과 및 영향]

정의된 지원 수식 범위 내 변환 검증 100% 통과
AI 생성 콘텐츠의 편집 가능성 확보로 서비스 실사용 전환율 향상
LLM 출력물을 사용자 워크플로우에 자연스럽게 통합하는 UX 개선 사례 확립

[기술적 의사결정]

수식 범위를 제한하고 시작한 이유: LaTeX와 한글 수식의 문법 체계가 상이하여, 전체 커버리지보다 핵심 수식 유형의 정확한 변환을 우선. 안정성 확보 후 범위 확장 가능하도록 모듈화 구조 설계
오픈소스를 그대로 쓰지 않은 이유: 한글→LaTeX 방향의 오픈소스는 역방향 변환에 구조적으로 맞지 않아, 문법 케이스 정보만 추출하여 새로운 방식으로 재설계

[스택] Python, FastAPI

LLM 출력 데이터의 신뢰성 확보 - AI 수학 풀이 서비스 안정화

[문제 및 배경] AI 기반 수학 풀이 서비스에서 LLM이 생성한 수학 풀이의 LaTeX 수식이 렌더링되지 않아 사용자가 AI의 답변을 확인할 수 없었고, 서비스 신뢰도가 저하되는 상황. 수동 수정도 불가능해 대응 방법이 없었음.

[역할 및 해결 과정]

요청자와 대화하며 구체적인 실패 케이스를 듣고, 기존에 시도했던 정규식 코드를 함께 분석
"정규식 패턴 추가/수정" 요청이었으나, 정규식 수정 시 다른 유형에서 연쇄적 오류가 발생하는 구조적 한계를 발견
이전 정규식 시도의 적용 순서를 분석하여 주요 오류 패턴 도출
정규식 대신 모듈화된 파서를 설계·구현

[성과 및 영향]

LLM 출력 데이터 500건 테스트 케이스 100% 정상 렌더링 달성
AI 서비스의 출력 신뢰성 확보로 사용자 이탈 방지
LLM 출력물 후처리 파이프라인 패턴 확립

[기술적 의사결정]

정규식 대신 파서를 선택한 이유: LaTeX의 중첩 구조는 정규식으로 완전히 처리할 수 없음. 패턴 수정 시 다른 유형에서 연쇄적 오류 발생. 파서 기반 접근으로 구조를 정확히 파싱하여 근본적으로 해결

[스택] TypeScript

교육 도메인 보일러플레이트 구축

[문제 및 배경] 신규 교육 서비스를 시작할 때마다 인프라 설정, 인증, 배포 파이프라인을 매번 처음부터 구축해야 하는 반복 비용 발생. 교육 도메인 특유의 요구사항(사용자 역할 분리, 콘텐츠 관리 등)이 프로젝트마다 유사했으나 표준화된 시작점이 없었음.

[역할 및 해결 과정]

교육 도메인의 공통 요구사항을 정리하고, 재사용 가능한 보일러플레이트 설계
BE 서버(NestJS + PostgreSQL) 전체 개발 (기여도 100%)
GCP 기반 인프라 및 배포 자동화 시스템 구축 (기여도 100%)
프론트엔드(Next.js)와의 연동 구조 설계

[성과 및 영향]

교육 기능 도메인 확립, 이후 프로젝트의 시작 시간 단축
배포 자동화로 개발자 생산성 향상
팀 내 표준 아키텍처 패턴으로 정착

[기술적 의사결정]

NestJS 선택: 모듈 기반 구조로 도메인 분리에 적합, TypeScript 지원으로 타입 안전성 확보
GCP 인프라: AppEngine의 자동 스케일링과 관리형 서비스로 운영 부담 최소화

[스택] Next.js, NestJS, PostgreSQL, GCP

운영 서비스 코드 구조 개선

[문제 및 배경] 운영 중인 서비스의 코드가 기능별로 분리되지 않고 하나의 파일/모듈에 혼재되어, 단순한 기능 수정에도 1~3주가 소요. 테스트 코드가 전혀 없어 수정 시 사이드이펙트를 사전에 확인할 방법이 없었음.

[역할 및 해결 과정]

기존 코드베이스를 분석하여 기능별 의존 관계 파악
기능별 코드 분리 및 모듈화 진행 (기여도 70%)
분리된 모듈에 대한 단위 테스트 작성, 테스트 자동화 환경 구축
GCP AppEngine과 Function을 활용한 서비스 분리

[성과 및 영향]

기능 수정 작업 시간: 1~~3주 → 1~~3일
테스트 커버리지: 0% → 50%
코드 변경에 대한 사이드이펙트 사전 확인 가능

[기술적 의사결정]

점진적 분리 전략: 전체 리팩터링 대신 수정이 빈번한 모듈부터 우선 분리하여 즉각적인 효과 확보
GCP Function 활용: 독립적인 기능을 서버리스로 분리하여 배포 단위를 줄이고 영향 범위 최소화

[스택] Node.js, React, GCP AppEngine, GCP Function

비트맥스(맥스트) 주식회사 | 웹서버 파트장 (2023.04 ~ 2024.03)

메타버스 서비스 "틀로나" 개발 및 CBT

[문제 및 배경] 현실 기반 월드와 소셜 기능을 제공하는 서비스 "틀로나" 개발 중, 웹서버 파트가 전체 개발팀 중 가장 느린 병목 파트였음. 다른 파트가 웹서버 API를 기다리며 대기하는 상황이 반복. 코드 분석 결과 서비스 코드들이 서로 강하게 결합되어 하나를 수정하면 연쇄적인 사이드이펙트가 발생하는 구조적 문제를 확인.

[역할 및 해결 과정]

전체 팀 중 웹서버 파트가 병목이라는 문제를 인식하고, 코드를 직접 분석하여 서비스 간 강결합이 근본 원인임을 파악
단순히 더 빨리 코딩하는 게 아니라 구조 자체를 바꿔야 병렬 개발이 가능해진다는 실제 문제 도출
도메인 경계를 명확히 분리하고, 서비스 계층을 각 도메인의 행위를 표현하는 표현 계층으로 재설계
"코어 로직을 내가 만들 테니 사용만 해라"는 방식으로 팀원들의 진입 장벽을 낮춰 점진적으로 적용

[성과 및 영향]

병합 주기 7일 → 1~2일로 단축
전체 개발팀 중 가장 느린 파트에서 가장 빠른 파트로 전환
테스트 용이한 구조 확보로 CBT 버그 0건 달성
이후 구조 개선 작업 시 팀원들이 집중할 수 있도록 이슈를 막아주는 문화 형성

[기술적 의사결정]

도메인 경계 분리를 선택한 이유: 기존 서비스 계층의 강결합 구조에서는 기능 수정 시 연관된 서비스를 모두 확인해야 했음. 도메인 경계를 나누고 서비스 계층을 표현 계층으로 분리하여 독립적 개발·테스트 가능
코어 로직 선제 구현: 새로운 구조에 대한 팀원들의 학습 부담을 줄이기 위해 파트장이 먼저 코어를 구현, 실제 사용 경험을 통해 자연스럽게 수용 유도

[스택] NestJS, AWS ECS

주식회사웨어밸리 | 소프트웨어 엔지니어 (2020.01 ~ 2023.04)

경쟁사 제품 정책 이관

[문제 및 배경] 대형 통신사 계약 후 엔지니어들이 수동으로 정책을 이관하려고 시도했으나, 2,000대 DB·5,000개 정책은 수동 처리가 사실상 불가능한 규모. 연구소에 정식으로 지원 요청이 들어왔고 연동 담당자로서 이관 작업에 투입.

[역할 및 해결 과정]

경쟁사 정책 분석 및 자사 솔루션 정책 매핑 로직 개발
정책 무결성 검증 보고용 데이터 쿼리 작성 (100% 검증)

[성과 및 영향]

5,000개 정책 100% 이관 및 무결성 검증 완료
경쟁사 제품 마이그레이션 선례 확립

[기술적 의사결정]

Lua 스크립팅 활용: 자사 솔루션 내장 스크립트 엔진으로 런타임 정책 매핑 가능, 별도 외부 도구 불필요

[스택] Lua, SQL, CentOS

CC 인증을 위한 보안 강화 및 개발 프로세스 자동화

[문제 및 배경] CC 인증 획득을 위해 반복적인 빌드-테스트가 필수였으나, QA팀과 개발팀이 매 빌드마다 수동으로 설치 작업을 수행(하루 1-4회, 5분/회)하고 있었음. 팀원과 대화 중 이 반복 작업을 발견하고 직접 질문하여 문제를 구체화. CC 인증 요건으로 OS 의존성(systemd 등) 없이 동작하는 데몬 관리가 필요했음.

[역할 및 해결 과정]