이규원

본인인증 체계 전환 및 보안 정책 재설계

문제

기존 본인인증 구조는 외부 인증 Provider 변경에 따라 단순 연동 교체만으로 처리하기 어려웠으며, 아이디 찾기·비밀번호 재설정·회원정보 수정 등 여러 민감 기능이 인증 결과를 개별적으로 소비하고 있었습니다. 특히 본인인증 결과 식별자의 재사용 가능성과 CI/DI 개인정보 저장 방식에 대한 보안 기준을 함께 재정의할 필요가 있었습니다.

해결

기존 본인인증 방식을 PortOne 기반으로 전환하면서 인증 결과 조회와 비즈니스 기능 수행의 책임을 분리하였습니다. 본인인증 결과 식별자는 1회만 사용할 수 있도록 정책화하고 사용 이력을 저장하여 재사용을 차단하였으며, 동시 요청에서도 동일 인증 결과가 반복 사용되지 않도록 DB Unique 제약을 적용하였습니다. 또한 DB 검색 용도가 아닌 동일 사용자 검증 목적으로 사용되는 CI/DI는 원문 저장 대신 HMAC-SHA256을 적용하여 식별 가능성과 개인정보 보호 요구를 함께 충족하도록 설계하였습니다. 아이디 찾기·비밀번호 재설정·회원정보 수정 등 기존 인증 의존 기능도 새로운 인증 흐름에 맞추어 재구성하였습니다.

결과

기존 본인인증 Provider를 PortOne 기반 구조로 전환하고 주요 계정 복구·회원정보 기능을 신규 인증 흐름으로 통합하였습니다. 인증 결과를 재사용 가능 구조에서 1회 사용 정책으로 변경하여 인증 결과 탈취·재사용 위험을 차단하였고, CI/DI 원문 저장을 제거하고 HMAC 기반 검증 구조를 적용하여 민감 식별정보의 노출 범위를 축소하였습니다. 본인인증을 특정 기능의 구현 세부사항이 아닌 재사용 가능한 공통 인증 흐름으로 정리하였습니다.

Tech: Kotlin, Java, Spring Boot, PostgreSQL, PortOne

세미나 Commerce 도메인 확장

문제

세미나는 일반 상품과 달리 주문·결제뿐 아니라 모집 기간, 일정/회차, 정원, 참석자, 사전 질문, 환불 제한, QR 출석 등 다수의 상태와 정책이 동시에 연결되는 상품이었습니다. 기존 Commerce 구조에 예외 분기를 추가하는 방식으로 구현할 경우 주문·결제 로직이 세미나 정책에 강하게 종속되고, PG Webhook 재처리나 결제 취소 과정에서 신청 인원과 참석자 상태가 불일치할 가능성이 존재하였습니다.

해결

세미나를 기존 Commerce의 예외로 처리하지 않고 세미나 일정 → 신청 → 주문 → 결제 → 참석의 독립적인 상태 모델로 구성하였습니다. 기존 세션 단위 중심 구조를 일정(schedule) 중심으로 재정의하여 회차별 신청과 정원 관리를 하나의 기준으로 통합하였습니다. 주문 생성 시 참석자를 대기 상태로 생성하고, 결제 완료 시 참석 확정·신청 인원 반영·QR Token 발급을 후처리로 연결하였으며, 결제 실패·취소 시에는 참석 상태와 신청 인원을 함께 복구하도록 설계하였습니다. 중복 Webhook 및 결제 재처리에서도 신청 인원이 반복 증가하지 않도록 멱등성을 고려하였고, 무료 결제·전액 쿠폰·적립금 결제에도 동일한 완료 후처리를 적용하였습니다.

결과

그 결과 장바구니 → 주문 → 결제 → 참석 확정 → QR 발급 → 현장 체크인을 하나의 Commerce Flow로 연결하였고, 전체 일정 신청과 회차별 신청을 모두 지원하면서 정원 관리 기준을 일정 단위로 일원화하였습니다. 1인 1매 정책, 참석자별 고유 QR Token, 환불 마감 이후 취소 제한 등 세미나 핵심 정책을 시스템 수준에서 보장하였으며, 중복 Webhook·재처리 상황에서도 신청 인원이 1회만 반영되도록 결제 후처리 안정성을 확보하였습니다. 기존 주문·결제 구조를 별도 상품군에 재사용하여 Commerce 도메인의 확장 가능성을 검증하였습니다.

Tech: Kotlin, Java, Spring Boot, PostgreSQL

회원 그룹 기반 커뮤니티 접근 권한 시스템 구축

문제

서비스가 확대되면서 관리자 역할만으로는 접근 범위를 표현하기 어려워졌으며, 특정 프로젝트나 기수에 소속된 사용자만 일부 게시판과 콘텐츠에 접근해야 하는 요구가 발생하였습니다. 각 API에서 사용자 역할이나 회원 여부를 직접 검사하는 방식은 역할·그룹·리소스가 추가될수록 조건문과 중복 검증이 증가하고, 목록 조회와 단건 접근의 정책 차이도 표현하기 어려운 구조였습니다.

해결

기존 역할 기반 권한에 회원 그룹·기수 개념을 추가하여 Role → Member Group → Resource로 접근 정책의 표현 범위를 확장하였습니다. 회원 그룹·기수·회원 소속 관계를 별도의 도메인으로 모델링하고, 게시판과 회원 그룹 간 N:M 접근 정책을 구성하였습니다. 게시판·게시물·댓글 등 개별 API에서 반복되던 검증은 Annotation + AOP 기반 공통 Authorization 계층으로 분리하고, 요청 Body·Path·Query Parameter 등 다양한 위치에서 대상 리소스를 식별하도록 구성하였습니다. 또한 단건 접근과 목록 조회의 성격을 분리하여, 단건은 Authorization 단계에서 차단하고 목록은 사용자의 접근 범위를 Query 조건에 반영하도록 설계하였습니다.

결과

역할 중심의 권한 모델을 역할·회원 그룹·리소스 기반 접근제어로 확장하였고, 게시판·게시물·댓글 등 복수의 리소스에 동일한 공통 접근 정책을 적용하였습니다. 비회원·일반 회원·특정 회원 그룹·전체 접근 권한 등 사용자 조건에 따라 목록 조회 결과까지 일관되게 제한할 수 있었으며, MARKETER 등 신규 역할 추가 시에도 기존 비즈니스 로직 수정 없이 권한 체계를 확장할 수 있는 기반을 마련하였습니다. 개별 API에 반복되던 권한 검증을 공통 영역으로 이동하여 비즈니스 로직과 접근제어 책임을 분리하였습니다.

Tech: Kotlin, Java, Spring Boot, PostgreSQL

콘텐츠 이용 권한 아키텍처 재설계

문제

기존 콘텐츠 이용 권한이 주문 데이터에 직접 종속되어 있어 일반 구매 외 기업 지급, 패키지, 대여, 이벤트 보상 등 새로운 콘텐츠 제공 방식이 추가될수록 주문 도메인에 예외 로직이 누적되는 구조였습니다. 주문 취소나 재구매 시 기존 콘텐츠의 소장·대여 상태를 정확하게 복원해야 하는 요구도 발생했습니다.

해결

콘텐츠 이용 권한을 주문과 분리된 독립적인 상태 모델로 재정의하고, 소장·대여·회수·재활성화 정책을 콘텐츠 도메인에서 공통으로 관리하도록 구조를 변경했습니다. 콘텐츠 획득 경로보다 현재 사용자의 이용 권한을 기준으로 동작하도록 설계하여 기업 회원 일괄 지급, 패키지, 이벤트 보상 등 비구매 기반 지급에도 동일한 모델을 적용했습니다. 주문 취소 및 재구매에서는 기존 대여·소장 상태를 정확하게 복원할 수 있도록 주문 시점의 콘텐츠 상태 Snapshot을 보존하는 구조까지 확장했습니다.

결과

구매에 종속되어 있던 콘텐츠 제공 구조를 독립적인 권한 모델로 전환하여 기업 지급·패키지·대여·이벤트 보상까지 동일한 구조에서 처리할 수 있도록 확장했습니다. 신규 콘텐츠 지급 정책 추가 시 주문 도메인의 수정 범위를 줄이고, 콘텐츠의 소장·대여·회수·재활성화에 대한 일관된 상태 관리 기반을 확보했습니다.

Tech: Kotlin, Spring Boot, PostgreSQL, Domain Modeling

주문·결제 시스템 신규 전환 및 도메인 재설계

문제

레거시 주문·결제 시스템은 주문 상태가 과도하게 세분화되어 있었으며 API·DB·운영툴에서 동일한 상태를 서로 다른 의미로 사용하는 경우가 존재했습니다. 또한 장바구니 → 주문 → 결제 → 쿠폰·적립금 → 콘텐츠 지급으로 이어지는 과정에서 결제 성공·실패·취소에 따라 여러 도메인의 상태를 동시에 정합성 있게 변경해야 했습니다. 외부 PG의 API 응답과 비동기 Webhook, 가상계좌 만료 등 서로 다른 경로에서 결제 상태가 변경될 수 있어 부분적으로 처리된 주문을 복구하거나 보정할 수 있는 구조도 필요했습니다.

해결

장바구니부터 주문·결제·혜택·콘텐츠 지급까지 이어지는 전체 상태 전이와 후처리 책임을 재설계했습니다. 기존에 중복된 의미로 사용되던 주문 상태를 정리하여 13종의 주문 상태를 8종으로 통합하고, API·DB·운영툴이 동일한 상태 체계를 사용하도록 일원화했습니다. 결제 API와 Webhook의 책임을 분리하고 결제 상태별 주문 최종화 기준을 정의했습니다. 결제 실패·취소 시 쿠폰·적립금·콘텐츠·장바구니의 복구 기준을 공통화하고, 외부 PG와 내부 주문 상태가 불일치하거나 처리되지 않은 주문을 탐지·보정하는 주문 보정 흐름을 구성했습니다. 무료 결제, 쿠폰·적립금 결제, 가상계좌, 패키지, 대여 상품 등 서로 다른 결제·상품 정책 역시 동일한 주문 상태와 후처리 구조 안에서 처리하도록 확장했습니다.

결과

주문 상태를 13종 → 8종으로 축소하여 상태 수 기준 복잡도를 약 38% 감소시키고, API·DB·운영툴의 주문 상태 해석 기준을 일원화했습니다. 결제 API·Webhook·주문 보정 경로의 책임을 분리하고 실패·취소 시 쿠폰·적립금·콘텐츠·장바구니의 복구 기준을 통합하여 결제 후처리의 일관성과 운영 대응력을 높였습니다. 이를 기반으로 2026년 1월 신규 주문·결제 시스템을 운영 전환했으며, 이후 데이터 보정과 레거시 주문 연동 로직 제거까지 진행했습니다.

Tech: Kotlin, Spring Boot, PostgreSQL, Transaction, Webhook, Scheduler

MRX-ray 고도화

문제

산업 현장의 장비 데이터를 클라우드 기반으로 수집·관리하면서 이상 징후를 조기에 탐지해야 했고, 현장 데이터와 운영 요구가 변하는 상황에서 프로토타입 수준의 기능을 상용 환경으로 확장할 필요가 있었습니다.

해결

AI 엔지니어와 협업해 이상탐지 대시보드를 프로토타입부터 상용 배포까지 개발하고, 실시간 진동 데이터 모니터링과 라벨링 기능을 구현했습니다. 이상 징후 발생 시 최대 10개의 주요 입력 변수와 기여도를 분석한 진단 보고서가 자동 전송되도록 구성해 현장 엔지니어가 장비 상태를 빠르게 파악할 수 있도록 했습니다.

결과

반도체 부품 제조사의 CO2 레이저 드릴에 적용해 실제 고장 1개월 전에 이상 징후를 예측했고, 초기 3대 장비에 적용된 솔루션이 현장 검증을 거쳐 10대 장비로 확장되었습니다. 이를 통해 장비 고장 대응과 유지보수 의사결정을 지원하는 상용 솔루션으로 검증되었습니다.

• 센서 대용량 데이터를 위한 이상탐지 모니터링 백엔드와 DB를 설계했습니다.
• 데이터 수집·가공 파이프라인과 알림 체계를 함께 구성해 운영 가능한 구조로 정리했습니다.
• 실시간 진동 데이터 모니터링과 라벨링 기능을 구현해 분석과 운영에 활용할 수 있는 기반을 마련했습니다.
• 이상 징후 진단 보고서 자동 전송과 현장 적용을 통해 상용 프로젝트 수주 및 실사용 배포까지 연결했습니다.

Tech: Python, Django, PostgreSQL, Kubernetes, Docker, AWS

MRX-ray 자바 마이그레이션

문제

기존 이상 탐지 모니터링 서비스는 Python/Django로 구현되어 있었고, 안정성·확장성·구인 등의 이유로 Java 전환이 결정된 상태였습니다. 또한 서비스 구조가 플랫하게 구성되어 있어 API 수와 데이터 모델을 함께 정리할 필요가 있었습니다.

해결

MRX-ray의 기본 구조를 잡고 스켈레톤을 구현했으며, 핵심 API 개발을 주도했습니다. 요구사항 변경에 맞춰 도메인을 다시 이해하고 UX 관점에서 필요한 데이터와 불필요한 데이터를 구분해 API를 재구성했고, 기존에 기능별로 흩어져 있던 API를 단일 조회 구조로 정리했습니다. 데이터베이스는 초기 요구사항과 현재 요구사항 차이를 반영해 불필요한 컬럼, 무분별한 인덱스, 대체키를 제거하며 리팩토링했습니다.

결과

기존 170개 수준이던 API를 리팩토링하여 80여 개 수준으로 축소했고, 한 페이지를 조회하기 위해 20여 개 호출되던 API를 1개 API로 통합해 조회 구조를 단순화했습니다. 서비스의 구조적 복잡도를 낮추고 자바 기반 운영 체계로의 전환을 안정적으로 마무리했습니다.

Tech: Java, Spring Boot, PostgreSQL, AWS

모델링용 원천 데이터 적재 파이프라인·DB 설계

문제

모델링 팀에서 사용할 원천 데이터가 MDF라는 특수한 파일 형태로 전달되어, 수작업 파싱과 적재에 의존하면 데이터 활용성과 정합성을 유지하기 어려운 상황이었습니다.

해결

MDF 포맷을 분석해 각 데이터의 의미와 시간 구조를 파악하고, ML 엔지니어와 의논하여 원본 데이터를 가공하지 않되 시간 정합을 맞춰 적재하는 방식으로 프로세스를 설계했습니다. 설정 파일에 정의된 경로를 감시하다가 파일이 들어오면 필요한 데이터를 추출해 DB에 적재하는 구조를 만들고, 사내 K8s 환경에 DB와 파싱 프로세스를 배포했습니다.

결과

모델링 팀이 바로 사용할 수 있는 원천 데이터 DB를 구축했고, 반복적인 수작업 적재를 제거해 학습 및 분석용 데이터 공급을 안정화했습니다. 이후 데이터 구조 변화에 대한 유연성이 아쉬운 점으로 남았지만, 당시 요구사항 기준에서는 자동화된 적재 기반을 확보했습니다.

Tech: Python, PostgreSQL, Docker, Linux, K8s

분류 모델 성과 지표 기능 개발·개선

문제

추론된 이상 값을 기준으로 분류 모델 성과 지표를 조회 시점에 계산하는 구조였기 때문에, 임계값이 파라미터로 달라질 수 있는 상황에서는 매번 계산이 필요했고 대규모 조회에서 DB 부하와 응답 지연이 발생했습니다.

해결

추론 전 모델에서 이상 값의 임계값을 1로 맞추는 규약을 두고, 조회 시 계산하던 방식을 적재 시점 계산으로 전환했습니다. 추론된 이상 값을 애플리케이션에서 처리해 통계 테이블에 적재하도록 개선하여 조회 부담을 줄였습니다.

결과

한 달치 조회 기준 응답 시간을 5초에서 1초 미만으로 단축했고, 지표 조회로 인한 DB 부하를 낮춰 성능과 운영 안정성을 함께 개선했습니다.

Tech: Python, PostgreSQL, Docker, Linux

홈택스·손택스 종합소득세 일반신고서 (21귀속) 오픈 개발

문제

홈택스에서 가장 트래픽이 높고 사용자 수가 많은 종합소득세 신고 서비스는 매년 데이터 이슈와 오픈 대응 부담이 큰 서비스였습니다.

해결

작년과 변경되는 부분을 미리 체크하고 동료들과 공유하여 불필요한 작업을 줄였으며, 개발 가능한 시간을 확보해 테스트와 검증을 충분히 진행할 수 있도록 했습니다. 모르는 부분은 적극적으로 공유하며 팀 내 소통을 강화해 버그 원인을 빠르게 파악하고 수정할 수 있는 협업 흐름을 만들었습니다.

결과

종합소득세 신고 서비스를 안정적으로 오픈·운영했고, 최종 신고 인원 949만 5,000명 규모를 장애 없이 처리했습니다. 신고 기간 동안의 버그 분석과 대응 속도를 높여 안정적인 운영에 기여했습니다.

Tech: Java, JavaScript, DB2, JSP

홈택스·손택스 근로소득자 경정청구 (21귀속) 오픈 개발

문제

연말정산을 한 근로자가 세금 감면을 덜 받았을 때 경정청구를 통해 세금을 감면받을 수 있어, 21귀속 세법 개정에 맞는 계산기 팝업과 계산 알고리즘을 새로 개발해야 했습니다. 기존 코드는 정리가 되어 있지 않아 분석이 어렵고 재사용과 변경이 힘든 상태였습니다.

해결

재사용 가능하고 변경하기 쉬운 코드 구조로 바꾸자는 의견을 제안하고, 7,000줄이 넘던 계산 알고리즘 스크립트를 리팩토링해 약 2,000줄 수준으로 정리했습니다. 또한 다른 팀의 데이터와 서비스를 사용해야 하는 구조를 빠르게 파악하기 위해 먼저 적극적으로 연락해 데이터 흐름을 이해하고, 필요한 계산 로직과 화면 동작을 맞춰 구현했습니다.

결과

계산 구조와 화면 로직을 세법 개정에 맞게 재정비하고, 코드 분석과 추가 변경에 드는 시간을 줄였습니다. 원천 데이터 흐름을 빠르게 파악해 이전 귀속보다 2주 빨리 구현을 마쳤고, 계산기 팝업과 알고리즘을 안정적으로 제공할 수 있었습니다.

Tech: Java, JavaScript, DB2, JSP

기준경비율 주요경비 세금계산서 데이터 적재 배치 개발

문제

기준경비율 주요경비 세금계산서 데이터 70만 건 적재와 대량 세금계산서 700만 건 적재 모두 기존 데이터 load 방식으로는 데이터 양 증가와 DB 부하 문제를 감당하기 어려운 구조였습니다.

해결

데이터 양에 따라 작업일자를 나누어 배치 처리할 수 있도록 프로그램을 수정하고, 적재 방식을 load에서 insert 기반 병렬 처리로 전환했습니다. 첫 배치 개발 업무였지만 업무 흐름을 이해하기 위해 계속 질문하고 공식 문서와 기존 레퍼런스 자료를 참고해 구현을 완료했습니다.

결과

70만 건 적재 배치와 700만 건 대량 적재 모두 DB 부하를 낮춘 구조로 처리할 수 있게 되었고, 분할 적재와 병렬 처리 기반의 배치 구조를 안정적으로 운영할 수 있었습니다.

Tech: Java, JavaScript, DB2, JSP