🔗 https://portfolio.shindongmin.dev/
우리금융캐피탈에서 금융 IT를 배우고,
스타트업에서 서비스 운영을 경험했습니다.
이제 그 두 가지를 케이뱅크에서 함께 쓰고 싶습니다.
Career
2017.07 ~ 2017.12 · 6개월
모델링 기반 Front-End & Back-End 개발자 양성과정
2018.05 ~ 2022.04 · 3년 11개월
우리금융캐피탈
2022.05 ~ 재직중 · 3년 11개월+
랩도쿠
Key Achievement
신용회복·개인회생 결재 시스템에 결함이 있어 매번 DB 데이터를 직접 수정하는 식의 우회 방법을 써가며 처리하고 있었습니다. 특정 담당자 없이 모두가 기피하던 레거시 시스템이었고 관련 문서나 컨텍스트가 없었기 때문에 전면 개편을 진행하는 것이 합리적이라고 판단하였습니다. 이후 해당 프로젝트의 진행 필요성을 정리해 경영진을 설득했고, RFP 작성부터 업체 선정까지 직접 맡아 진행했습니다.
레거시 시스템에 대한 개편 프로젝트 주도적으로 진행개인회생 담당자가 매일 법원 사이트에 접속해 건별로 일정과 변제금액을 확인하고 있었습니다. 주 약 8,000건에 달하는 작업이었고, 놓치거나 오입력하는 경우가 꽤 있었습니다. 비효율적이고 실수 가능성이 큰 업무를 개선하기 위해 스크래핑 배치를 개발해 신규 일정·금액 변동·오입력을 자동 검증하고, 팝업으로 담당자에게 알려주는 체계를 만들었습니다.
주 8,000건 업무 자동화를 통한 업무 효율성 향상배치 오류가 발생하면 데이터센터 야간 근무자의 연락을 통해 인지하는 구조였습니다. 인력에 의존하는 방식이다 보니 상황에 따라 장애 인지가 지연되기도 했습니다. 이를 개선하기 위해 오류 발생 즉시 담당자 휴대전화로 자동 전화가 연결되도록 IVR을 개발했습니다. 금융 배치는 당일 업무에 치명적인 영향을 줄 수 있기 때문에 무엇보다 빠르게 인지하고 즉시 조치할 수 있는 체계를 만드는 것이 중요하다고 판단했습니다.
장애 즉시 인지 체계 구축현업이 자료가 필요할 때마다 IT에 서비스 요청을 올리고 기다리는 구조였습니다. 이는 현업이나 IT 담당자 모두 불필요한 시간을 소모하게 만들었기 때문에 내부 시스템에 자료별 조회·다운로드와 함께 자료 생성 배치를 실행할 수 있는 기능을 만들었습니다. 또한 결재권자 승인이 필요한 자료도 다룰 수 있도록 결재 품의 연동까지 지원하여 업무의 효율성을 높였습니다.
불필요한 서비스 요청 제거전임 개발자가 모두 퇴사한 뒤 문서도 없이 B2B 웹 SaaS 서비스를 운영하게 되었습니다. 낮에는 운영하고 밤에는 구조를 파악하며 장애를 줄여갔고, 결국엔 단일 장애점 문제를 해결하기 위해 서비스를 전면 개편했습니다. 클라우드 플랫폼을 활용해 인프라를 구축하고, 여러 플랫폼·채널의 데이터를 유연하게 수집·연동해야 했기 때문에 MySQL에서 MongoDB로 전환해 확장성을 확보했습니다. 그리고 Redis와 로컬 LRU 캐시, CDN을 조합해 중복 데이터 요청을 줄이고 응답 성능을 개선했습니다. 리뉴얼 서비스는 레거시 사용자 수를 넘어섰고, 현재 100개 이상의 쇼핑몰이 사용 중입니다.
100+ 쇼핑몰 운영 · 클라우드 인프라 구축 · MySQL→MongoDB 전환 · 캐시 성능 개선사내 블록체인 프로젝트에서 온체인 데이터를 수집하고 정제하여 사용자 지갑의 디지털 자산 포트폴리오를 한눈에 볼 수 있는 화면으로 만들었습니다. 또한 보유 자산의 전송·전환 기능을 구현하고, 트레이딩 뷰를 활용하여 각 자산별 시세 차트를 제공하였습니다.
온체인 데이터 수집 → 포트폴리오·전송·시세 차트 구현About Me
우리금융캐피탈에서 4년 가까이 여신 시스템을 개발했습니다. 데이터 하나가 잘못되면 다음 날 마감 전체가 틀어진다는 걸 몸으로 배웠고, 그 과정에서 안정적인 기능 개발과 금융 업무 이해의 중요성을 현장에서 느꼈습니다.
스타트업에서 혼자 서비스를 운영해보니 배포 이후가 더 중요하다는 걸 알게 됐습니다. 장애가 나면 새벽에도 저 혼자 대응해야 했으니까요. 그래서인지 코드를 짤 때 운영 편의성과 장애 대응을 먼저 생각하는 습관이 자연스럽게 생겼습니다.
같은 장애가 반복되면 패치보다 원인을 먼저 찾습니다. 우리금융캐피탈에서 법원 조회 오입력이 반복되길래 수동 조회 자체를 배치로 바꿨고, 결재 시스템 결함으로 인한 반복적인 데이터 수정을 줄이기 위해 전면 개편을 진행했습니다. 빠른 작업도 중요하지만 그와 더불어 재발하지 않는 방향을 선택해왔습니다.
"이게 불편해요"라는 말을 들으면 어떤 기능이 필요한지 찾는 걸 좋아합니다. IT 경유 요청을 직접 조회 화면으로 바꾸고, 오입력이 반복되던 텍스트 입력 필드를 코드로 바꾼 것도 그런 대화에서 시작됐습니다. 현업과 직접 얘기하는 게 요구사항 문서보다 정확할 때가 많습니다.
인수인계 없이 운영 중인 서비스를 넘겨받은 날, 솔직히 막막했습니다. 그래도 코드부터 읽고, 모르면 찾고, 안 되면 다시 했습니다. 어린 시절 운동선수로 훈련하며 쌓은 습관인데, 개발자가 된 지금도 유효합니다.
MySQL에서 MongoDB로의 전환, Redis 캐시 설계, 클라우드 인프라 구축까지 — 처음 써보는 기술이어도 서비스에 필요하면 찾아서 적용해왔습니다. 더 나은 서비스를 위해서라면 낯선 기술도 두려워하지 않습니다.
Tech Stack
Why Kbank
좋은 시스템은 아무도 눈치채지 못하는 사이
조금씩 더 나아지고 있어야 합니다.
배포 다음 날 현업이 아무 말도 없으면 잘 된 겁니다.
그러면서
어느 순간 일이 조금 더 빠르고, 조금 덜 번거로워져 있는 것.
일을 할수록 그게 맞는 방향이라는 걸 느꼈고,
케이뱅크에서도 그렇게 하고 싶습니다.
계정계 수신 시스템에서 현업이 불편하게 쓰고 있는 것들을 찾아내고 싶습니다. 수동으로 처리하거나 돌아가는 흐름, 반복되는 문의, 아무도 고치지 않아서 그냥 참고 있는 것들. 우리금융캐피탈에서 그런 것들을 하나씩 줄여봤고, 케이뱅크에서도 그렇게 하고 싶습니다.
코드 한 줄이 미칠 수 있는 영향을 알고 있습니다. 데이터 하나가 잘못되면 다음 날 마감 데이터가 틀어지고, 배치 장애 하나가 후행 처리 전체를 멈춘다는 것도 압니다. 그래서 빠르게 만드는 것도 중요하지만 오래 믿고 쓸 수 있는 안정적인 시스템을 만들겠습니다.
금융 IT는 안정이 우선이지만, 케이뱅크는 그 위에서 빠르게 움직이는 곳이라고 생각합니다. 금융 도메인을 아는 사람이 서비스 속도까지 갖추면 더 잘 할 수 있다고 믿습니다. 그 경험을 케이뱅크에서 쌓고 싶습니다.
우리금융캐피탈에서 여신 시스템을 개발하며 금융 업무의 흐름과 데이터 구조를 몸으로 익혔고, 짧지만 CMS 서비스 경험도 있습니다. 완전히 같지는 않아도 수신과 여신은 서로 맞닿아 있는 영역입니다. 상환 스케줄과 원리금 계산, 배치 처리의 타이밍과 정합성 문제 같은 감각은 도메인이 바뀌어도 그대로 쓸 수 있다고 생각합니다. 이미 금융 IT의 무게를 아는 사람으로서, 수신 도메인의 세부 규칙도 빠르게 익혀 실질적인 기여를 하고 싶습니다.