SentBe(센트비) - 센트비안 인터뷰 SentBe(센트비) SentBian Story 페이지입니다.
SentBe(센트비) - 센트비안 인터뷰
SentBe(센트비) SentBian Story 페이지입니다.
제목없음
단단한 원칙 위에 유연한 백엔드를 짓습니다
Tech | SentBe Backend | 정윤정
사용자가 센트비 앱에서 터치 몇 번으로 가입부터 송금까지 마치는 그 짧은 과정 뒤에는, 국가마다 다른 인증 요건과 규제, 그리고 여러 외부 시스템 연동이 맞물려 돌아간다. 센트비 백엔드(SentBe Backend)팀의 정윤정은 그 흐름이 멈추지 않는 단단한 서버를 설계하는 백엔드 개발자다. 2024년 센트비에 합류해 낯선 해외송금 도메인을 만났을 때, 그는 끊임없이 묻고 직접 확인하며 다른 구성원을 위해 문서를 남기는 방식을 택했다. 처음 도메인을 파악할 때의 집요함은 그대로 지금의 일하는 방식이 됐다. 그는 주어진 요구사항 너머의 빈틈과 예외를 짚어내고, 기능 아래에서 변하지 않아야 할 것과 유연해야 할 것을 날카롭게 나누며 오늘도 견고한 백엔드 구조를 설계해 나간다.
센트비 백엔드 팀은 어떤 일을 하나요.
사내 여러 프로덕트 중에서도 개인 고객이 국내외 송금은 물론 바코드 결제 등 다양한 생활 금융 서비스를 이용할 수 있는 C2C 솔루션 센트비의 백엔드를 전담하고 있습니다. 고객이 앱에서 누르는 모든 동작은 저희 서버로 전달되죠. 회원가입과 인증부터 송금, 그 뒤의 혜택과 알림까지 요청을 받아 처리하고, 외부 인증 솔루션이나 외부 기관 보고 시스템과의 연동도 모두 이 서버에서 이루어집니다.
저희 팀은 백엔드 시스템을 더욱 효율적이고 밀도 있게 관리하기 위해, 고객 여정을 기준으로 크게 세 가지 도메인으로 나누어 맡고 있습니다. 회원가입과 인증을 묶은 ‘회원 및 인증’, 실제 돈이 오가는 핵심 영역인 ‘송금’, 고객이 서비스에 계속 머무르게 만드는 ‘운영 및 리텐션’이 그 세 축입니다. 이는 저희 팀만의 기준이 아니라 개인 고객용 프로덕트를 담당하는 모든 조직과 협의해 맞춘 기준이라, 관련 부서 모두가 이 기준에 맞춰 움직이고 있어요. 회원 및 인증 도메인은 사용자가 누구인지를 다루는 영역입니다. 회원가입, 로그인 같은 기본적인 회원 기능과, 송금 전에 사용자의 신원을 확인하는 KYC 인증을 맡습니다. 송금 도메인은 센트비의 가장 핵심적인 도메인으로, 50개국 이상으로 보낼 수 있는 다양한 수취 방법 관리부터 송금을 위한 결제 수단 관리까지 송금 플로우 전반을 다룹니다. 운영 및 리텐션 도메인은 서비스 이용이 일회성에 그치지 않도록 쿠폰이나 캐시백 같은 혜택 기능과, 그 혜택을 고객에게 전달하는 배너·이벤트·알림 기능을 담당하죠.
고객용 서비스뿐만 아니라 CS 조직, Operation Strategy팀, Compliance Ops팀 같은 사내 운영 조직이 원활히 일할 수 있도록 백오피스를 만드는 일도 함께 맡고 있어요. 고객 문의에 대응할 수 있게 계정과 거래 내역을 조회하는 화면, 인증 정보를 수동으로 검토하고 상태를 바꾸는 기능, 쿠폰 지급 기능 같은 것들입니다. 이 기능들이 운영 현장에서 실제로 어떻게 쓰이는지는 Operation Strategy팀이 중간에서 정리해 저희에게 전달해 줍니다. 지금 어떤 상황이고 어떤 불편이 있는지를 정리해 받으면, 저희는 원인을 분석하고 구조를 바꾸는 식이죠.
그중 회원 및 인증 도메인을 맡고 계시다고요.
이 도메인의 핵심은 KYC, 즉 센트비 송금 서비스를 쓰려는 사용자가 실제로 누구인지 확인하는 일입니다. 인증 프로세스는 별도 서버에서 주로 Go 언어로 개발해 처리하고 있어요. 송금이 시작되는 한국, 인도네시아, 싱가포르 세 나라에서 서비스를 운영하다 보니 국가마다 요구하는 인증 항목과 단계가 다르고, 신분증 진위 확인처럼 외부 솔루션을 쓰는 단계도 있어서 그 흐름을 각각 관리해야 합니다. 인증의 목적은 크게 두 가지입니다. 하나는 서비스를 운영하는 국가별 비대면 인증 규정을 준수하는 것이고, 다른 하나는 서비스의 불법적인 이용을 사전에 차단하는 것이에요. 결국 인증이란 검증된 사용자만 송금 서비스를 이용할 수 있도록 하는 중요한 과정입니다. 그래서 신원 인증은 회원가입 이후 실제 송금을 신청하기 전 단계에서 반드시 거치도록 되어 있습니다.
기능 하나가 요청에서 배포까지 가는 동안, 다른 팀과는 어떻게 맞물려 일하시나요.최근 월렛 프로젝트에서 진행한 인증 계좌 변경 기능을 예로 들 수 있겠네요. 먼저 도메인 팀 전체가 모여 킥오프 회의를 합니다. 저는 이 자리에서 요구사항과 정책을 검토하며 놓친 부분이나 애매한 부분은 없는지 확인해서 PM에게 다시 묻습니다. 그러면 회의에서 나온 내용을 바탕으로 PM이 요구사항을 유저 스토리 형태의 티켓으로 정리해 줍니다. 그다음에는 앱 클라이언트 개발자와 API 스펙 및 에러 처리 방식을 함께 논의하며 개발을 진행하죠. 개발이 끝나면 QA팀이 미리 작성해둔 테스트 케이스별로 검증하고, 실제 운영 환경 배포는 정해진 배포 프로세스에 따라 인프라 조직이 담당합니다. 배포가 끝나면 저희는 모니터링 대시보드로 관련 지표와 로그를 지켜보며 이상 유무를 확인합니다.
“변하지 않아야 할 부분은 모든 해외송금 건은 예외 없이 보고돼야 한다는 정책 자체이고, 유연해야 할 부분은 그 보고를 언제, 어떤 순서로, 몇 번 재시도하며 처리하는지에 대한 구현 방식이라고 생각해요.”
외부 연동 하나가 송금 자체를 끊지 않도록 실패를 격리하는 구조를 늘 염두에 둔다고 하셨습니다. 한국은행 해외송금 통합관리시스템(ORIS) 연동에서는 어떻게 설계했나요.
저희가 구축한 ORIS 연동 시스템은 한국은행의 ORIS API와 센트비 송금 서비스 사이를 잇는 백엔드 게이트웨이입니다. 센트비에서 발생하는 해외송금 거래를 ORIS에 보고하는 역할을 하는데, 올해부터 사실상 송금 서비스의 필수 관문이에요. 이 작업의 주요 목표 중 하나는, 보고가 외부 시스템 사정으로 지연되더라도 그 지연이 고객의 송금을 막아서는 안 된다는 것이었습니다. 사용자는 있는지도 모르는 시스템 때문에 송금이 막히면 안 되니까요. 그래서 보고 요청 자체를 비동기로 처리하고, 실패하면 바로 에러를 던지는 대신 별도 큐(Queue)에 쌓아두고 스케줄러가 간격을 점점 늘려가며 재시도하는 구조를 만들었습니다. 외부 시스템 응답이 느려지는 순간에도 사용자의 송금 요청은 영향 없이 처리되고, 밀린 보고 건은 큐에서 순차적으로 처리됩니다. 보고는 빠짐없이 완료되고, 고객은 그 과정을 느끼지 않는 거죠. 결국 이 구조에서 변하지 않아야 할 부분은 ‘모든 해외송금 건은 예외 없이 보고돼야 한다’는 정책 자체이고, 유연해야 할 부분은 그 보고를 언제, 어떤 순서로, 몇 번 재시도하며 처리하는지에 대한 구현 방식이라고 생각해요.
ORIS 연동 서비스는 Java로 만들어졌다고요.
저희 팀은 Go를 주력으로 써왔지만 서비스별로 Go와 Java를 함께 쓰고 있고, 신규 서비스는 Java를 우선적으로 고려하고 있어요. ORIS 연동도 그 흐름 속에서 Java로 만들어진 서비스입니다. 두 언어를 함께 다루면 언어별 컨벤션과 라이브러리 생태계가 달라서 작업하는 레포지토리가 바뀔 때마다 컨텍스트 스위칭이 생깁니다. 대신 두 언어를 오가며 일하다 보니 특정 언어의 문법보다 ‘이 로직이 원래 뭘 하려는 것인가’를 먼저 파악하는 습관이 생겼고, 이게 오히려 다른 코드베이스를 이해하는 속도를 높여줬습니다.
요즘 가장 비중 있게 하는 일은 무엇인가요.
신분증 인증에 쓰는 외부 솔루션 연동을 사내 컴플라이언스 통합 시스템으로 옮기는 작업입니다. 이 시스템은 센트비 안의 여러 컴플라이언스 관련 기능을 한곳에 모아 관리하기 위해 만들어졌고, 외부 컴플라이언스 솔루션 연동의 중앙 창구 역할도 맡습니다. 그래서 센트비에서 쓰는 외부 인증 솔루션들도 여기서 통합 관리하기로 결정됐어요. 이제 저희 서버 쪽에서는 신분증 인증이 필요할 때 통합 시스템 하나만 호출하고, 통합 시스템이 인증하려는 국가에 맞는 외부 솔루션을 골라 실제 인증을 처리한 뒤 결과와 인증 정보를 정리해 다시 전달해주는 구조로 바뀝니다.
첫 사례가 싱가포르 인증에 쓰는 Singpass(싱가포르의 국가 디지털 신원 인증 서비스) 전환이었습니다. 기존에 쓰던 API 버전의 지원 종료가 예정돼 있어 가장 먼저 진행했죠. 원래 Singpass API를 직접 호출하던 로직을 걷어내고 통합 시스템이 정의한 스펙에 맞춰 요청과 응답을 주고받도록 바꿨는데, 특히 통합 시스템은 인증 결과를 Kafka 이벤트로 비동기 전달하기 때문에 저희 쪽도 이 이벤트를 받아서 처리하는 구조로 바꿔야 했습니다. 목표는 고객이 인증 방식이 바뀐 걸 전혀 눈치채지 못하게 하는 것이었고, 실제로 화면과 사용자 경험은 거의 그대로 둔 채 내부 연동 구조만 바꿨습니다. 다른 인증 솔루션들도 앞으로 이관이 쉬운 순서대로 이 구조에 통합될 예정이에요.
모놀리식 구조를 도메인 경계에 맞게 분리하는 작업도 진행 중이라고 하셨습니다. 지금은 어디까지 와 있나요.
현재 인증 프로세스, ORIS 연동, 월렛 로직이 먼저 별도 서버로 분리됐고, 회원 정보·약관 같은 회원 도메인, 월렛을 제외한 송금 전반, 쿠폰·회원 등급 같은 리텐션 도메인은 하나의 서버 안에서 운영하고 있습니다. 인증 서버로의 이관도 아직 다 끝나지 않아 진행 중이고요. 분리하면서 달라진 것도 있습니다. 월렛 로직이 기존 모놀리식(Monolithic) 서비스에서 별도 서버로 분리되면서, 예전에는 DB를 직접 조회해 가져오던 다른 도메인 정보를 이제는 서버 간에 전달받아야 하는 상황이 됐거든요. 서버끼리 직접 호출해 강하게 결합되는 걸 피하려고, 각 서버가 자기 상태 변화를 Kafka를 통해 이벤트 기반으로 알리는 방식으로 통신하게 됐어요. 이전부터 저희 팀이 지향하던 구조였는데, 월렛 서버 분리를 기점으로 적극적으로 도입하게 됐습니다.
다음에 분리할 도메인은 순서를 미리 정해두기보다 몇 가지 기준으로 검토해 정하고 있습니다. 단순히 구조를 나누는 기술적인 작업이라기보다, 오랫동안 쌓여온 로직이 서로 연결돼 있어 기능 하나를 떼어낼 때도 영향 범위를 넓게 봐야 하거든요. 그래서 분리를 검토할 때는 몇 가지를 함께 봅니다. 이상적인 도메인 경계와 실제로 그 서비스를 책임지고 운영할 수 있는 주체 사이에서 타협점을 찾아야 하고, 기술적으로는 서비스를 나눴을 때 장애나 부하가 서로 전파될 수 있는 부분까지 감안해서 분리로 얻는 실익이 실제로 있는지를 따져봅니다. 서비스가 여러 개로 늘어날수록 아키텍처가 복잡해지는 만큼, 전체를 한눈에 파악할 수 있는 가시성과 모니터링 체계도 함께 갖춰야 하고요. 각 도메인을 잘 아는 분들과 직접 확인해가며 하나씩 걷어내고, 기존 서비스에 영향을 주지 않으면서 분리해 내는 과정이 핵심이라고 생각합니다.
센트비에서 처음으로 앱 클라이언트를 직접 대응하게 되면서 하위 호환성을 훨씬 신중하게 생각하게 되셨다고요.
전 회사에서는 인터페이스를 비교적 자유롭게 바꿀 수 있는 환경이었는데, 센트비에서는 앱 클라이언트를 직접 대응하다 보니, 서버만 바꾸면 끝나는 게 아니라 아직 앱을 업데이트하지 않은 사용자도 불편 없이 서비스를 계속 쓸 수 있어야 한다는 걸 체감했습니다. 그래서 지금은 몇 가지 원칙을 지키고 있어요. 기존 API를 작업할 때 인터페이스 자체가 바뀌는 변경이면 클라이언트 개발자와 미리 더블체크하고, 인터페이스는 그대로지만 내부 로직만 바뀌는 경우에도 앱 버전에 따라 처리 방식을 다르게 해야 하는지 확인합니다. 그리고 구버전 앱에 영향이 있을 수 있다고 보이면 QA팀에 검증을 요청해 확인하고 있습니다.
요구사항을 받으면, 세부 조건이나 예외 케이스까지 한 번 더 짚어보는 편이시라고요.
PM분들은 요구사항을 개발자가 바로 작업할 수 있는 형태로 정리해 전달하는 데 익숙한 편이에요. 그렇지 않은 경로로 들어오는 요청은 당연히 개발에 필요한 세부 조건까지 담겨 있지 않을 수 있고요. 그래서 요구사항을 받으면 세부 조건이나 예외 케이스까지 한 번 더 짚어봅니다. 애매한 부분을 먼저 풀어두어야 의도대로 한 번에 만들 수 있거든요. 특히 저희가 다루는 KYC나 컴플라이언스 영역은 국가나 정책에 따라 요구사항 자체가 크게 달라지기 때문에, 이 과정을 건너뛰면 구조 자체를 다시 짜야 하는 경우가 많아서 더 신경 쓰게 됩니다. 요구사항에 적히지 않은 예외를 찾으면 바로 PM과 팀에 공유합니다.
“요구사항을 받으면 예외 케이스까지 한 번 더 짚어봅니다. 애매한 부분을 먼저 풀어두어야 의도대로 한 번에 만들 수 있거든요.”
매주 금요일마다 팀 세미나가 있다고요. 어떤 이야기가 오가나요.
제가 입사했을 때부터 있던 센트비 문화인데, 지금은 각자 업무를 하다 고민되는 부분을 함께 논의하거나 팀 컨벤션을 정하는 자리로 쓰이고 있어요. 거창한 발표 세션이 아니라 그때그때 필요한 방식으로 유연하게 씁니다. 최근에는 계층별로 쓰는 DTO 이름을 통일하는 논의를 했는데, 외부로 데이터를 내보내는 계층의 이름을 놓고 의견이 갈렸습니다. Input/Output, Request/Response, Spec/Projection처럼 후보로 나온 이름들이 각각 어떤 뉘앙스를 주는지, 다른 계층 이름과 짝이 맞는지를 두고 이야기가 오갔고, 그 자리에서 결론을 내기보다 후보를 추려 팀 전체 투표로 정리하기로 했죠. 오래 일하다 보면 기존 방식에 익숙해져서 불편함 자체를 못 느끼게 되는 시기가 오기도 하는데, 새로 합류하신 분들이 적극적으로 의견을 내주신 덕분에 당연하게 여기던 부분들을 다시 비판적인 시각으로 들여다볼 수 있었습니다. 코드 리뷰도 마찬가지예요. 단순히 스타일을 지적하는 수준이 아니라 왜 이렇게 짜는 게 더 나은지 근거까지 함께 이야기하면서 서로 배우는 자리로 쓰고 있습니다.
“동료들이 자기 일이 아니어도 같이 문제의 본질을 짚어봐 줍니다. 센트비 백엔드 팀에서는 도메인 경계가 협업의 장벽이 되지 않아요.”
센트비에서 개발자로 일하는 매력은 무엇인가요.
저희 팀이 개인 고객용 서비스 개발의 중심에 있다 보니, CS, 운영, 컴플라이언스 같은 다양한 조직과 계속 협업하게 됩니다. 서비스를 개발자 관점에서만 보는 게 아니라, 이 기능이 운영 조직에게는 어떤 의미인지, 고객 응대에서는 어떤 문제로 이어질 수 있는지까지 함께 고려하게 되더라고요. 무엇보다 각자 속한 도메인 팀과 직접 관련이 없는 문제라도, 고민을 나누면 다른 동료들이 자기 일처럼 같이 들여다봐주는 분위기가 있습니다. 최근에 인증 도메인 신규 기능에 필요한 데이터 설계를 두고 같은 도메인 팀원과 리뷰를 하는데, 뚜렷한 답이 안 나오고 맴돌던 적이 있어요. 옆에 계시던 다른 도메인 팀원께 가볍게 의견을 여쭤봤는데, 그분은 바쁘셨고 신규 기능에 대한 컨텍스트도 전혀 없는 상태였습니다. 그런데도 바로 답을 주려 하지 않고, 이 기능을 왜 만들게 됐는지, 어디에 쓰일 예정인지부터 하나씩 물어보며 같이 문제 자체를 다시 짚어봐 주셨어요. 그렇게 배경을 함께 정리하다 보니 저희가 놓치고 있던 지점이 보였고, 결국 그분이 제안한 방향을 그대로 채택했습니다. 이 팀에서는 도메인 경계가 협업의 장벽이 되지 않는다는 걸 그때 느꼈습니다.
마지막으로, 송금 도메인이 낯설어 지원을 망설이는 개발자에게 한마디 건네신다면요. 그리고 백엔드 개발자로서 일을 잘한다는 건 무엇일까요.
해외송금이라는 도메인 자체를 접하기 쉽지 않다 보니, 저도 입사 초반에는 낯선 금융 용어를 익히는 데 시간이 걸렸습니다. 처음 맡았던 수취 수단 추가 작업 때도 용어나 플로우가 복잡해서 파악이 쉽지 않았어요. 그래서 팀원들에게 묻고, 클라이언트 개발자분들께 하나하나 여쭤보고, 직접 테스트 기기로 화면을 확인해가며 흐름을 맞췄습니다. 그렇게 파악한 내용은 다음에 같은 걸 겪을 사람을 위해 문서로 정리해뒀고요. 낯선 도메인 앞에서 잠깐 주눅 들기도 했지만, 결국 누가 정리해줄 때까지 기다리기보다 부딪혀가며 스스로 컨텍스트를 채우는 편이 훨씬 도움이 된다는 걸 체감했습니다.
그래서 이 일에는 스스로 문제를 찾아서 나서는 사람이 잘 맞는다고 생각합니다. 여러 팀과 계속 맞물려 일해야 하는 구조라, 가만히 기다리기보다 필요한 정보나 맥락을 직접 찾아 나서고, 애매한 부분이 있으면 먼저 짚고 방향을 제안하는 사람이 훨씬 빨리 자리를 잡습니다. 송금 도메인이 낯설어 망설이고 계신다면, 도메인 지식보다 이런 능동적인 태도가 더 중요하다는 말씀을 드리고 싶어요. 제가 생각하는 일 잘하는 백엔드 개발자도 같은 맥락입니다. 주어진 요구사항만 코드로 옮기는 사람이 아니라, 작업하다 마주치는 애매모호한 부분들을 그냥 넘기지 않고 끝까지 파고들어 해소하면서, 서비스의 완성도를 높이는 데 기여하는 사람이라고 생각합니다.
