컴퓨터공학 학사과정
2027.02 학위 취득 예정학점은행제 · 현재 평점 4.5/4.5 · 2026.08 학적부 기준
안녕하세요.
풀스택 개발자정용상입니다.
모든 것은 더 나아질 수 있습니다.대부분은 모르는 채로 넘어갈 뿐입니다.
통찰력을 바탕으로 근본적인 문제를 정의하며, 혁신적인 아이디어를 통해 사용자의 경험을 개선합니다.
PROFILE
About
당신은 누구인가요?
가족을 위해 고등학교를 졸업하자마자 생산직에 뛰어들었으나, 엑셀을 사용하다가 데이터 시스템의 자동화를 완성하였습니다. 여기서 개발자의 길을 깨닫고 직종을 변경하기로 결심하였습니다. 그리고 이 시기에 문제를 해결하는 소프트웨어의 본질을 깨달았습니다.
현재는 프론트엔드와 백엔드를 통합하는 개발 역량과 탑다운 사고방식을 통해 현실의 문제를 단계별로 최적화하여 완성도 높은 소프트웨어를 만들고 있습니다.
MES 솔루션 개발
비즈플러스 글로벌 ·
Spring 백엔드 개발자
B2C 서비스 기업MSA 환경과 LLM 기능 연동
Career
- 교육2023.06—2023.11JAVA 웹개발 교육 이수
이젠컴퓨터아카데미 · JAVA 웹개발 산업기사 과정
- 자격2023.11정보처리기사
정보처리기사 취득
- 경력2023.12—2026.04비즈플러스 글로벌 근무
MES 솔루션 설계·구현 및 표준 MES 개발 주도
- 자격2024.04SQLD
SQLD 취득
- 학업2025.08—현재컴퓨터공학 학사과정
학점은행제 병행 · 2027.02 학위 취득 예정
- 프로젝트2026.04Simple ERP 구축
공백기 현업 문제를 시스템으로 구현 · Claude Code 첫 사용
- 교육2026.05—2026.07백엔드 단기심화 데브코스 이수
AI · MSA 단기심화 프로젝트 이수 · Codex 리뷰 체계 도입
- 자격2026.06네트워크관리사 2급
네트워크관리사 2급 취득
- 프로젝트2026.07Inference Gateway 구축
Python · FastAPI 기반 OpenAI 호환 API 추론 서버 구축
Skills
AI CAPABILITY
AI 활용 역량
Claude Codedevelop · design
Codexreview · sub-develop
FRONTEND
프론트엔드
85%친숙함
ReactTypeScriptMUIRedux ToolkitRTK QueryVite
BACKEND
백엔드
95%친숙함
JavaSpring BootSpring ModulithJPARedisKafkaPostgreSQL
DATA & REPORTING
데이터 분석 & 보고
- 정리·계산
- Excel
- 분석·시각화
- Power BI
- 보고·전달
- PowerPoint
Projects
각 프로젝트를 배경 → 문제 정의 → 실행 → 결과의 같은 순서로 정리했습니다.
- 01WORK · MESMES – 제조관리 시스템첫 개발 경력에서 반복 구축의 한계를 표준 제품 구조로 전환했습니다.표준화정합성실무 설계↘
- 02PRODUCT · ERPSimple ERP현장의 분산된 업무 기준을 실제 사용으로 판단할 수 있는 제품으로 연결했습니다.제품 판단Modulith실사용↘
- 03TEAM · MSA · AIopenAt상품 정합성과 운영 질의를 책임 경계와 검증 기준으로 해결했습니다.MSAAI 챗봇에이전트 운용↘
- 04AI INFRA · PYTHONInference Gateway하드웨어 실행 가능성을 먼저 검증하고 반복 가능한 로컬 추론 경로를 만들었습니다.API 계약실추론벤치마크↘
PROJECT 01WORK · MES
MES – 제조관리 시스템
첫 개발 경력에서 고객별 반복 구축의 한계를 여러 현장에 적용할 수 있는 표준 제품 구조로 전환했습니다.
- 01문제 정의
고객마다 다시 만드는 구조로는 공급도 제품 고도화도 늘릴 수 없었습니다.
신규 고객마다 개발자 한 명이 독립 구축에 투입돼 같은 기능을 반복했고, 동시에 진행할 수 있는 업체 수와 기존 제품을 개선할 시간이 함께 제한됐습니다.
- 02실행
공통 업무는 표준 제품으로, 현장 차이는 확장 지점으로 분리했습니다.
2024.08—2025.04 표준 MES의 설계·구현을 주도했으며, Slack·Jira·문서를 도입해 여러 개발자가 같은 기준으로 협업할 수 있는 환경도 정리했습니다.
- 03결과
다수 업체 공급을 추진할 수 있는 제품 구조로 전환했습니다.
기존 개발자는 고객별 신규 구축을 반복하는 대신 기능 고도화와 유지보수에 집중할 수 있게 됐습니다.
PUBLIC REFERENCE
동시기 회사 전체 영업이익
- −1억 4,213만원−1.42억
- 251만원251만
- −2억 6,146만원−2.61억
- 1억 5,892만원1.59억
PROJECT 02PRODUCT · ERP
Simple ERP
여러 Excel에 흩어진 업무 기준을 직원들이 ERP의 효용을 실제 사용으로 판단할 수 있는 하나의 시스템으로 연결했습니다.
- 01문제 정의
같은 고객·계약·설비 정보가 여러 Excel에서 서로 다르게 관리됐습니다.
복사·공유·동시 수정이 반복되면서 어느 파일이 기준인지 불분명했고, 사람이 계속 파일 사이의 정합성을 맞춰야 했습니다.
- 02실행
기능 수보다 기준 데이터와 대표 업무 흐름을 먼저 완성했습니다.
Spring Modulith로 고객→영업→계약→설비→AS를 연결했습니다. 문제·아키텍처·수용 기준은 직접 정하고, 경계가 명확한 반복 구현만 Claude Code에 위임했습니다.
- 03결과
실사용 경험은 정식 ERP 도입과 후속 확장 요청으로 이어졌습니다.
하이웍스 도입 후 드러난 문제를 두 시스템을 사용한 직원들이 비교했고, 부장님이 확장을 요청했습니다. 평일 개발이 어려운 상황에서 에이전트로 반복 구현과 1차 확인을 진행해 주말 이틀 안에 확장과 전체 검증을 마쳤습니다.
ADOPTION FLOW
실사용으로 이어진 판단과 확장
- 직원 사용 평가→
- 하이웍스 도입→
- 두 시스템 비교→
- 부장님 확장 요청→
- 주말 이틀 전체 검증
실사용 환경과 데이터는 비공개이며, 격리형 데모 구현은 완료했지만 독립 공개 URL은 준비 중입니다.
PROJECT 03TEAM · MSA · AI
openAt
상품 재고의 정합성과 관리자 운영 질의를 하나의 MSA 프로젝트에서 책임 경계와 검증 기준으로 해결했습니다.
- 01문제 정의
재고 경쟁 상태와 운영 정보 접근은 서로 다른 책임 경계가 필요했습니다.
상품은 빠르게 변하는 재고와 영구 이력을 일치시켜야 했고, 관리자는 주문·상품 현황을 확인할 때마다 DB를 직접 조회해야 했습니다.
- 02실행
목표·경계·계약을 먼저 고정하고 구현 병목만 에이전트에 위임했습니다.
시나리오→책임 경계→데이터 흐름→계약→통합 검증 순서를 정했습니다. 상품은 Redis와 append-only RDB로, 챗봇은 LLM의 해석과 애플리케이션의 실행·권한·검증으로 책임을 분리하고 Claude Code 구현을 Codex 독립 리뷰와 직접 검증으로 수용했습니다.
- 03결과
재고 정합성과 관리자 질의를 각각 검증 가능한 경계로 닫았습니다.
상품은 Lua 원자 연산·DB unique 멱등성·보상 처리로 실시간 상태와 영구 이력의 정합성 경계를 구현했습니다. 챗봇의 첫 라우팅은 38/38 기대 분기와 일치했고, A/B 응답 중앙값은 30.409초에서 11.869초로 줄었지만 기능 성공은 20/24에서 19/24로 1건 줄어 속도를 전체 품질 향상으로 해석하지 않았습니다.
TROUBLESHOOTING
실패를 다음 설계 규칙으로 바꾼 세 가지 결정
- 01도메인 API 증가
read-only 통합 view와 AI 조회 책임 분리
- 028K context 한계
필요한 tool·schema만 단계별 제공
- 03다단계 호출 지연
가벼운 결과를 먼저 노출
공개 설명은 개인 담당 범위에 한정합니다. read-only shared DB view는 물리 DB 공유 제약에서 선택한 예외이며, 분리 환경에서는 API·이벤트·read model로 교체해야 합니다.
PROJECT 04AI INFRA · PYTHON
Inference Gateway
보유 하드웨어의 실행 한계를 먼저 확인한 뒤 Python·FastAPI 기반 OpenAI API 규격 추론 경로를 구축했습니다.
- 01문제 정의
API보다 먼저 11GB VRAM에서 실제 추론이 가능한지 확인해야 했습니다.
실행 가능성이 없으면 이후 계약과 배포 계획 전체가 무효가 되며, 생성과 임베딩도 실패 의미가 달라 하나의 fallback으로 묶을 수 없었습니다.
- 02실행
하드웨어 선검증 뒤 외부 계약과 실패 경계를 고정했습니다.
GGUF·Ollama로 실행 가능성을 확인하고 Python·FastAPI 기반 OpenAI API 규격 계약을 구현했습니다. 생성·embedding fallback, 오류 분류, 원자 배포·rollback을 테스트와 벤치마크로 검증했습니다.
- 03결과
단일 요청의 사용성과 동시 요청의 실제 한계를 함께 확인했습니다.
공개 문서에 기록된 마지막 전체 통과는 554개이며, 단일 요청에서 TTFT p95 2.74초·30.8 tok/s를 측정했습니다. 8개 동시 요청에서 error·OOM은 0이었지만 TTFT p95는 40.4초로 증가했습니다.
LAST DOCUMENTED PASS554최신 수집 555개와 구분
SINGLE REQUESTTTFT p95 2.74s30.8 tok/s
8 CONCURRENTerror 0 · OOM 0안정성 경계 확인
CONCURRENCY LIMITTTFT p95 40.4s첫 응답 지연의 실제 비용