SentBe(센트비) - 센트비안 인터뷰 SentBe(센트비) SentBian Story 페이지입니다.
SentBe(센트비) - 센트비안 인터뷰
SentBe(센트비) SentBian Story 페이지입니다.
제목없음
송금이 예외 없이 도착하게 만드는 기술
Tech | SentBiz Backend | 윤재현
견고한 송금 시스템은 결코 스스로를 증명하려 애쓰지 않는다. 기업이 보내는 정산 대금이 약속된 시간에 정확히 도착하는 것. 이 당연하고도 빈틈없는 결과야말로 시스템이 가장 완벽하게 작동하고 있다는 증거다. 기업 고객을 위한 해외송금·결제 솔루션 센트비즈(SentBiz)의 결제 도메인을 책임지는 22년 차 백엔드 엔지니어 윤재현의 일은 바로 그 시스템의 안쪽에서 이뤄진다.
기업 고객이 송금액과 최종 지급 금액을 확인해 정산을 의뢰하면, 그 내역이 정산 원장에 기록되고 센트비즈의 코어 시스템이 실제 정산을 수행한다. 일련의 과정이 오차 없이 매끄럽게 맞물려 돌아가도록 시스템을 설계하고 책임지는 것이 그의 역할이다. 해외에서 국내로 들어오는 송금의 수취인 본인 인증과 오픈뱅킹 연계도 그의 손을 거친다. 요즘 가장 공들이는 일은 결제대금 지급 실패를 빠르게 알아채고 조치하는 구조를 갖추는 것. 고객사가 이용하는 웹 대시보드 등 클라이언트 단에서 발생하는 오류를 실시간으로 지켜보다가, 그 오류에 남은 추적 번호(trace-id)를 따라가 문제가 시작된 지점을 찾아내는 식이다.
"송금을 신청하고 그 결과가 뜨기까지, 그 사이에 생길 수 있는 예외를 최소화하는 것이 제 일이에요. 고객의 화면에는 ‘송금 성공’이라는 결과만 떠야 하니까요." 나라마다 다른 송금 조건, 파트너사마다 제각각인 규칙, 그리고 언제든 튀어나올 수 있는 예외 상황들. 그가 매일같이 보이지 않는 경우의 수를 집요하게 걷어내는 이유다.
어떤 업무를 담당하고 계신가요.
기업 고객을 위한 해외송금·결제 솔루션 센트비즈의 결제 도메인을 개발하고 유지보수합니다. 고객이 얼마를 보내면 상대가 얼마를 받는지 확인한 뒤 정산을 의뢰하면, 그 내역을 정산 원장에 저장하고 코어 시스템을 통해 실제 지급을 수행하는 과정이죠. 여기에 더해 해외 고객이 국내로 돈을 보낼 때 필요한 수취인 본인 인증과 오픈뱅킹 연계 기능도 개발하고 운영하고 있습니다. 해외송금은 국가와 파트너에 따라 지급 조건이 달라질 수 있어요. 그래서 정책이 바뀌어도 유연하게 대응할 수 있는 구조를 만들어두는 일이 중요합니다. 그럼에도 예외 상황은 생기는데, 그걸 어떻게 처리하면 전체 시스템에 영향을 주지 않을지 계속 고민해야 하죠.
해외에서 국내로 들어오는 송금에서는 특히 두 가지가 중요합니다. 하나는 자금세탁 방지예요. 금융 범죄가 발생하지 않도록 막는 일이라 반드시 필요한데, 리걸&컴플라이언스 부문(Legal & Compliance Division)에서 기준을 잡아 가이드라인을 주시고 저는 그 기준에 맞게 개발하고 유지보수합니다. 다른 하나는 데이터의 상태 정합성을 맞추는 일입니다. 실제로 처리된 결과와 시스템에 기록된 상태가 어긋나면, 고객은 자기 돈이 어디에 있는지 알 수 없게 되니까요.
하루 업무 사이클은 어떻게 흘러가나요.출근길에 밀린 슬랙 스레드를 확인하는 것으로 시작해요. 사무실에 도착하면 짧은 아침 회의(데일리 스크럼)를 하고, 해외송금 모듈의 변경사항을 리뷰한 뒤 이번 스프린트에 계획해둔 이슈들의 요건을 정리해둡니다. 오후에는 여러 팀에서 확인 요청이 오는 경우가 많아서, 그 사이사이에 개발에 집중할 준비를 해둡니다. 그러고는 조금 늦은 오후에 개발을 시작해서, 목표한 만큼 끝나면 퇴근하는 흐름이에요.
요즘 가장 공들이는 건 결제대금 지급 실패를 빠르게 인지하고 조치하는 개선입니다. 지급 실패는 원인이 안에 있을 때와 바깥에 있을 때로 나뉘어요. 바깥, 즉 파트너 쪽 문제라면 파트너사에 문의한 뒤 회신 결과에 따라 개발로 해결하거나 운영에서 처리합니다. 내부 오류라면 앱에서 발생하는 에러를 실시간으로 지켜보다가, 그 오류에 남은 추적 번호(trace-id)를 따라가 근본 원인이 생긴 모듈을 찾아 조치합니다.
“정형화된 시스템에서는 어려운 맞춤형 요구도, 핀테크 환경에서는 기술적으로 시도해볼 수 있는 영역이 됩니다. 고객의 요구에 직접 대응하는 것, 그것이 기술로 만들어내는 진짜 가치입니다.”
20여 년의 개발 커리어 중, 센트비를 선택한 이유가 궁금합니다.영상 플랫폼, 클라우드 PC, 광고 플랫폼을 거쳐왔는데, 도메인마다 기술로 만들어낼 수 있는 가치의 크기가 달랐어요. 금융은 오랫동안 기술만으로는 도전할 수 없는 영역이었습니다. 그런데 그 벽이 점차 낮아지는 흐름이 보였어요. 소액해외송금업이 신설되면서 핀테크 기업도 해외송금을 할 수 있게 됐고, 오픈뱅킹으로 고객 동의를 받아 계좌를 조회하고 이체할 수 있게 됐고, 마이데이터로 금융 데이터를 활용할 길도 열렸습니다. 이런 흐름을 보면서 금융에서 기술이 차지하는 자리와 규모가 계속 커질 것이라고 판단했고, 그래서 송금이라는 도메인을 택했습니다.
기업 고객은 회사마다 정산 기준이 다릅니다. 그래서 그 기준에 맞춰 시스템을 조정해야 하는 일이 생기는데, 정형화된 시스템에서는 손대기 어려운 부분이죠. 핀테크 서비스에서는 기술적으로 풀 수 있다면 시도해볼 수 있습니다. 이렇게 고객의 요구에 직접 대응할 수 있다는 점이, 제가 생각하는 기술의 가치입니다.
“문제를 만나면 예전에는 '이걸 코드로 어떻게 풀지'부터 고민했어요.
지금은 '애플리케이션에서 풀 문제인가, 인프라에서 풀 문제인가'를 먼저 봅니다.”
시야를 넓혀준 커리어의 전환점이 있으셨다고요.크게 두 가지를 꼽을 수 있습니다. 첫 번째 전환점은 인프라였습니다. AWS를 다루게 되면서 설계의 범위가 달라졌어요. 그전까지 제가 백엔드 개발자로 관여하던 범위는 프레임워크 구성과 서버의 처리량 정도였습니다. 예전에는 비즈니스 요구사항을 받으면 애플리케이션 코드 안에서 어떻게 풀지를 먼저 고민했고, 서버 간 통신과 로컬 데이터 저장소가 제가 쓸 수 있는 재료의 거의 전부였죠. 클라우드를 쓰기 시작하면서 그 재료가 늘었습니다. 큐나 람다(Lambda), 키네시스 스트림(Kinesis Stream) 같은 관리형 서비스*를 설계에 넣을 수 있게 되니, 예전에는 애플리케이션 안에서 억지로 만들어야 했던 실시간 처리를 인프라의 도움을 받아 구성할 수 있게 됐어요.
가장 크게 달라진 건 문제를 볼 때 던지는 첫 질문입니다. 예전에는 ‘이걸 코드로 어떻게 풀지’를 먼저 고민했어요. 지금은 ‘애플리케이션에서 풀 문제인가, 인프라에서 풀 문제인가’를 먼저 봅니다. 인프라로 해결할 수 있는 게 무엇인지 알수록, 제가 해결할 수 있는 일의 범위가 비약적으로 넓어지더라고요.
두 번째 전환점은 팀의 경계를 넘어선 협업이었습니다. 센트비에서 C2C 조직과 국내송금을 함께 개발하면서 회사의 송금 흐름 전체를 보게 됐어요. 그전까지는 제가 담당하는 모듈 안에서 입력과 출력을 맞추는 데 집중했습니다. 협업을 하면서 그 앞뒤에 어떤 과정이 있는지, 제 모듈을 지나간 데이터가 최종적으로 고객에게 어떻게 보이는지를 알게 됐죠. 실질적으로 가장 달라진 건 코어 모듈을 수정할 때입니다. 예전에는 제 모듈의 테스트가 통과하면 됐는데, 지금은 이 변경이 어느 클라이언트 서비스까지 닿는지를 먼저 확인합니다. 같은 코어를 여러 서비스가 함께 쓰고 있다는 걸 눈으로 보고 나면, 수정 하나에도 자연스럽게 더 조심스러워지더라고요.
또 하나는 사람에 대한 지도가 생겼다는 점입니다. 다른 조직의 개발팀과 일해보니 각자 무슨 일을 하는지 알게 됐는데, 이게 생각보다 훨씬 중요했어요. 문제가 생겼을 때 누구에게 물어야 하는지, 반대로 제가 가진 정보를 누구에게 줘야 하는지 바로 판단할 수 있게 되었습니다. 혼자 파고들면 반나절 걸릴 일이, 맞는 사람에게 물으면 십 분에 끝나기도 하니까요.
*관리형 서비스: 백업, 자동 확장, 소프트웨어 업데이트, 모니터링 등을 대행하는 인프라 제공 서비스
레거시 코드를 마주하면 무엇부터 하시나요.가장 먼저 하는 일은 그 시스템의 히스토리를 아는 담당자를 찾는 겁니다. 레거시 코드는 문서와 실제 구현이 맞지 않는 경우가 많아서, 직접 묻는 것만큼 빠르고 확실하게 시행착오를 줄여주는 방법이 없거든요. 그게 어려운 상황이라면 데이터 구조도(ERD)나 도메인 모델을 먼저 파악하고, 그다음에 모듈의 핵심 기능 위주로 코드를 읽어나갑니다. 그렇게 접근해도 가장 까다로웠던 건 에러 처리 공통 코드였습니다. 여러 프로젝트가 함께 가져다 쓰는 코드(공통모듈)라, 코드만 봐서는 수정의 영향 범위를 짐작할 수 없었어요. 그 모듈을 쓰는 모든 프로젝트를 먼저 확인해야 했죠. 지금은 영향 범위 파악이 끝난 상태입니다. 의존성이 지나치게 큰 기능은 잠시 그대로 두고, 사용성을 개선할 수 있는 기능부터 손봐서 배포해뒀어요. 길게 보면 이 공통 코드에 대한 의존성을 완전히 걷어내는 것이 목표입니다.
“요구사항을 구현할 때 다른 직군과 사용자의 입장을 함께 고려하는 건, 단순한 배려가 아니라 실제 기능의 완성도를 높이는 가장 확실한 방법입니다.”
일할 때 중요하게 여기는 게 협업하는 사람의 입장이라고 하셨습니다.C2C 개인용 송금 솔루션의 국내송금 기능을 개발할 때였어요. 계획된 스펙은 입금과 출금 기능만 완성하면 되는 것이었죠. 그런데 클라이언트 개발자와 이야기해보니, 그 두 개의 API를 클라이언트에서 직접 조합해 쓰는 방식이었습니다. 그러면 에러가 났을 때 앞선 처리를 되돌리는 보상 트랜잭션까지 클라이언트가 관리해야 하는 구조가 되죠. 그래서 국내송금 전용 API를 추가로 개발했습니다. 결과적으로 클라이언트는 한 번의 호출과 그 응답만 믿으면 되는 구조가 됐어요.
단순히 배려의 차원은 아닙니다. 개발하다 보면 제가 미처 생각하지 못한 부분을 다른 직군이나 다른 팀의 관점에서 발견하는 경우가 많아요. 요구사항을 구현할 때도 운영팀과 다른 개발팀, 실제 사용자의 입장을 함께 보려고 합니다. 그 과정이 결국 기능의 완성도를 높이고, 운영에서 생길 수 있는 문제를 줄여주니까요. 그래서 사람들이 모여서 이야기를 하고 있으면 호기심과 불안함에 무슨 일인지 확인하러 가는 편이에요. 송금과 직접 관련이 없어도 영향을 줄 수 있는 요소를 많이 발견할 수 있어서, 결국 제 업무에도 도움이 됩니다.
센트비에서 개발자로 일하는 매력을 꼽는다면요.
입사했을 때 센트비 코드에는 설계나 인프라 구성이 시대에 뒤떨어지지 않도록 꾸준히 개선해온 흔적이 보였습니다. 코틀린으로 헥사고날 아키텍처*가 적용되어 있었고, 이벤트 기반 구조도 들어와 있었어요. 인프라도 EKS 클러스터**로 구성되어 있어서 늘어나는 트래픽에 유연하게 대응할 수 있는 상태였습니다. 인프라 구성이나 개발 스펙은 회사가 기술을 대하는 태도를 보여준다고 생각해요. 개선을 위해 스터디한 흔적도 문서에 남아 있었는데, 그걸 보면서 이곳은 개발자가 배우고 기여할 여지가 많은 곳이구나 싶었습니다.
일하면서 하나 더 크게 느낀 건 인프라 실의 지원입니다. 송금은 외부 파트너나 은행과 연동하는 일이 많아서 네트워크 구성이나 보안 규칙을 손봐야 하는 경우가 자주 생겨요. 이런 게 막히면 개발 자체가 멈추는데, 요청하면 빠르게 처리되고 왜 그렇게 구성하는지도 같이 설명해줍니다. 덕분에 저는 개발에 집중할 수 있고, 그 과정에서 네트워크 지식도 조금씩 늘었어요.
*헥사고날 아키텍처: 비즈니스 로직을 외부 기술과 분리해, 나중에 기술을 갈아 끼우기 쉽게 만드는 설계 방식
**EKS 클러스터: 컨테이너를 묶어 운영하는 관리형 쿠버네티스 환경
앞으로 팀에서 더 해결해보고 싶은 과제가 있다면요.경력이 쌓이면서, 개발을 잘하는 것만으로는 조직의 성과에 기여하기 어렵다고 느꼈습니다. 필요한 요건에 빠르게 대응하고 도전할 수 있어야 하는데, 그 빠름을 막는 게 결국 고도화가 밀린 시스템이라고 봐요. 첫 번째 걸림돌은 파악이 어려워진 코드와 의존 관계입니다. 처음 만들 땐 깔끔했어도 덧대어지다 보면 이 변경이 어디까지 닿는지 알 수 없게 됩니다. 그러면 잘 돌아가는 코드라도 손을 못 대요. 기술적으로 어려워서가 아닙니다. 판단할 근거가 없어서예요. 두 번째는 정보의 불균형입니다. 같은 목표를 향해 모인 구성원이 각자 알고 있는 배경지식이 달라서, 그 격차를 줄이는 데 너무 많은 시간을 쓰게 됩니다. 그래서 하고 싶은 일이 두 가지예요. 잘 돌아가는 코드라도 복잡도를 줄일 여지를 찾아 단순한 구조로 바꾸고 오래된 코드를 최신화해두는 것, 그리고 변경사항 요약과 구조화된 문서를 자동으로 만들어 구성원에게 공유하는 일입니다.
“회고에서 얻은 걸 혼자만 알고 있으면 개인의 노하우로만 남습니다. 공유해야 팀의 방식이 됩니다. 저는 그 차이가 개인의 실력과 일 잘하는 개발자를 가른다고 생각해요.”
끝으로, 일 잘하는 개발자는 어떤 사람인가요.일 잘하는 개발자는 더 잘하기 위한 회고와 도전을 반복하는 사람이라고 생각합니다. 이 도전은 코드에만 한정되지 않아요. 소통 방식이나 문서 작성, 시스템 설계까지 다양할 수 있습니다. 꾸준히 공부하는 것도 결국 그 반복의 일부죠. 다만 회고에서 얻은 것을 혼자만 알고 있으면 개인의 노하우로만 남습니다. 공유해야 팀의 방식이 됩니다. 저는 그 차이가 개인의 실력과 일 잘하는 개발자를 가른다고 생각해요.
