오래된 시스템을 옮겨 다시 돌아가게 만들고, 사람이 반복하던 업무 흐름을 자동화하며, AI를 제품과 개발 과정 안에 설계해 넣는 백엔드 개발자입니다.
<aside> 📑
문서는 넷입니다. 요약은 이력서, 한 일을 빠짐없이 보려면 경력기술서, 대표 프로젝트를 깊게 보려면 포트폴리오, 일하는 방식은 자기소개서에 있습니다.
</aside>
| 구분 | 내용 |
|---|---|
| 백엔드 핵심 | Java, Kotlin, Spring Boot, MyBatis, JPA, QueryDSL, JDBC, MS-SQL 기반 서비스 API와 관리자 앱 구현 |
| 일하는 축 | 레거시 현대화 → 개발 프로세스 자동화 → AI 활용 세 축을 잇는 것이 지금의 관심사입니다. 멈춘 시스템을 옮겨 놓는 데서 끝내지 않고, 그 위에서 반복되던 요청·반영 과정을 자동화하며, AI를 제품 기능과 개발 과정 양쪽에 설계해 넣습니다. |
| 자동화·AI 활용 | 사내 요구사항 접수부터 구현·PR·반영 확인까지의 루프를 에이전트 스킬로 정의해, 특정 개발자가 붙어 있지 않아도 요구사항이 반영되도록 구성. 개인 프로젝트에서는 AI를 어디에 쓰고 어디서 배제할지, 어떤 권한까지 줄지를 설계의 문제로 다룸 |
| Guidance 기술 구도 | 검사 개발은 Java/Kotlin Spring 중심, 플랫폼 운영과 레거시 연동은 Ruby + ASP 기반 구조를 함께 다룸 |
| 제품 범위 | 검사 실시, 답안 저장, 결과 산출, OMR, 통계/보고서, ERP/홈페이지 운영 흐름까지 연결 |
| 인프라/운영 | AWS ECS/EC2/ECR/CodeBuild/CodeDeploy, NCP, Docker, Nginx, ALB, Jenkins 기반 배포/운영 경험 |
| 현재 강조점 | 회사에서는 레거시 ERP의 Spring 이관을 마치고, 그 위에서 요구사항 반영 파이프라인을 자동화하는 일에 무게를 두고 있습니다. 이관한 기반 위에서는 제휴 기관 채널과 각기 다른 스택에 흩어져 있던 레거시 검사를 하나의 표준 경로로 모으는 일을 함께 다룹니다. 이관한 도메인은 사람이 실제로 일하는 순서대로 다시 짜는 단계로 넘어가, 근태와 재화 관리처럼 여러 팀이 매일 쓰는 흐름을 요청·승인과 원장이 남는 구조로 정리하고 있습니다. 개인적으로는 만성질환 식이관리 서비스 케어테이블을 실배포·운영하며(api.kcalai.link) 앱 스토어 심사 기준에 맞춰 iOS 출시를 준비하고 있고, 증권 API 기반 매매 터미널은 역할별 AI 에이전트에게 권한을 나눠 주는 구조 위에서 사람이 명령을 치는 구간을 지워 상시 운영으로 넘기고 있습니다. |
| 축 | 설명 |
|---|---|
| 레거시 현대화 | Rails와 ASP로 운영되던 사내 ERP를 Spring으로 이관하고 원본을 걷어냈습니다. 오래 운영된 화면에는 문서화되지 않은 기준이 묻혀 있어, 원본 로직에서 규칙을 먼저 드러낸 뒤 단일 기준으로 정리하며 옮기는 방식을 택합니다. |
| 요구사항 자동화 | 이관한 기반 위에서, 타 팀이 올린 요구사항을 읽어 구현하고 PR을 여는 데까지를 에이전트 스킬로 정의했습니다. 설계 판단이나 위험이 개입되는 지점은 자동으로 보류해 사람에게 넘기고, 나머지는 담당자가 붙어 있지 않아도 흘러가게 하는 것이 목표입니다. |
| 플랫폼 운영 | 신규 ERP는 Rails에서 Java/Kotlin Spring으로 이관을 마쳤고, 홈페이지와 레거시 운영 플랫폼은 Ruby와 ASP 기반 흐름을 함께 이해해야 합니다. 검사 주문과 정산, 인증코드, OMR, 결과 조회, 관리자 기능, 기존 시스템 연동을 다룹니다. 검사 카운트는 레거시 집계 컬럼 대신 증감 원장으로 다시 세워 잔여 수량의 근거가 남게 했습니다. 제휴사 주문과 기관 단위 배분처럼 주문을 넣는 쪽과 소모하는 쪽이 나뉘는 흐름도 이 범위에 들어옵니다. |
| 연결 지점 | 신규 Spring API와 기존 Ruby/ASP 플랫폼 사이에서 데이터, 경로, 사용자 흐름이 끊기지 않도록 호환성과 운영 안정성을 맞춥니다. |
| 검사 개발 | SPS/LDAT 같은 신규 검사 설계도와 검수 데이터를 Java/Kotlin Spring 도메인 로직으로 구현합니다. 채점, 규준, 소견, 결과 속성, 결과표 API가 핵심입니다. 각기 다른 스택에서 돌던 레거시 검사를 공통 스택으로 모으고, 그 과정에서 연구소 정본과 대조해 죽어 있던 판정을 되살리는 일도 같은 축입니다. |
| 운영 안정화 | OMR 동적 필드, LDAT 코드 정규화, GERP 기준 검사 선택, 견적·계산서의 정산 기준, 배포 파이프라인 교착, 공유 DB 인스턴스의 커넥션 고갈, 렌더 서비스의 메모리 회수, Terraform 정합성처럼 운영 중 드러나는 기준 차이를 정리합니다. 중복과 죽은 코드를 걷어내는 정리도 같은 축으로 봅니다. 정리하는 동안 드러나는 결함이 적지 않아, 정리를 결함 탐지 경로로 씁니다. |
| 기준 | 내용 |
|---|---|
| 공개 범위 | 연락처와 상세 주소 같은 민감 정보는 공개 페이지 본문에서 제외합니다. |
| 업무 정보 | Guidance 업무 내용은 공개 가능한 수준의 도메인, 역할, 기술적 기여 중심으로 설명합니다. |
| 관리 방식 | 날짜별 변경 이력은 누적하지 않고, 최신 상태를 각 문서의 역할/성과 설명 안에 녹여 관리합니다. |