인앱약정 SDK 프로젝트 회고
통제할 수 없는 환경에서 경계를 만들고 책임을 설계한 경험
인앱약정 SDK 시리즈 11편. 아홉 편은 기술적 결정을 다뤘다. 이 글은 다르다. 이 프로젝트가 나에게 무엇이었는지에 대한 개인적인 기록이다.
아무도 먼저 맡겠다고 하지 않았던 프로젝트
처음 이 프로젝트 이야기가 나왔을 때, 먼저 맡겠다는 반응은 많지 않았다.
이유는 분명했다.
금융사마다 스무 개가 넘는 화면을 만들어야 했고, 각 금융사의 환경은 모두 달랐다. 우리가 통제할 수 없는 레거시와 보안 솔루션 위에서 동작해야 했고, 배포 일정도 마음대로 정할 수 없었다. 문제가 생기면 금융사 담당자와 직접 원인을 찾아야 했다.
겉으로 보면 반복 구현이 많고 운영 제약이 큰 프로젝트였다. 가장 많이 들었던 말도 “힘들겠다”였다.
그럼에도 맡기로 했다.
어려운 프로젝트라서가 아니라, 해결해야 할 문제가 분명했기 때문이다.
당시 대출 비교 서비스의 가장 큰 한계 중 하나는 사용자가 상품을 선택한 이후였다. 사용자는 대출을 받기 위해 금융사의 기존 약정 프로세스로 이동해야 했고, 그 과정에서 많은 이탈이 발생하고 있었다.
인앱약정은 이 경험을 개선하기 위한 프로젝트였다. 새로운 화면 하나를 만드는 일이 아니었다. 사용자가 대출을 신청하고 완료하는 마지막 과정을 더 자연스럽게 잇는 일이었다.
이 프로젝트는 서비스 개선 효과를 인정받아 특별 인센티브로 이어졌다. 하지만 내가 더 의미 있게 느낀 것은 보상보다, 오랜 시간 고민했던 구조와 기술적 선택이 실제 사용자 경험 변화로 연결됐다는 점이었다.
두 번째 이유는 구조 자체가 흥미로웠기 때문이다.
우리가 만든 UI가 우리 서버도, 우리 도메인도 아닌 금융사의 웹페이지 안에서 실행되어야 했다. 그리고 그 금융사 페이지는 다시 우리 앱의 WebView 안에서 열렸다.
금융사 시스템과 우리 앱, 그리고 우리 SDK 사이에서 어떤 경계를 만들고 어떤 책임을 가져가야 하는지 고민해야 했다.
쉽게 경험하기 어려운 구조였고, 그 안에서 기준을 만들어가는 과정 자체가 흥미롭게 느껴졌다.
무엇을 만들어야 하는지부터 정해야 했다
프로젝트 초반 가장 어려웠던 것은 기술 구현이 아니었다.
무엇을 만들어야 하는지가 명확하지 않았다.
인앱약정이라는 큰 방향은 이미 있었다. 하지만 실제로 프로젝트를 성공시키기 위해서는 이 목표를 구체적인 문제와 해결 방법으로 바꾸는 과정이 필요했다.
금융사는 각자의 시스템과 제약을 이야기했고, 우리는 우리 서비스와 앱 구조를 설명했다.
모두 자신의 상황을 이야기하고 있었지만, 그것을 하나의 문제로 모아 “그래서 어떤 구조를 만들어야 하는가”라는 공통 언어로 만드는 과정은 부족했다.
회의를 거듭해도 요구사항이 정리된다기보다 각자의 환경 설명만 늘어나는 느낌이었다.
그래서 먼저 우리가 생각하는 구조를 하나 만들었다.
금융사 웹페이지 안에서 SDK가 실행되고, 필요한 화면을 렌더링하고, 앱과 금융사 사이의 흐름을 연결하는 구조였다.
완성된 답이라기보다는 서로 같은 그림을 보며 이야기하기 위한 첫 번째 기준에 가까웠다.
그 구조를 바탕으로 금융사와 논의를 이어갔고, 실제 환경에서 동작 가능하다는 피드백을 받았다.
그때 처음으로 생각했다. 이제 무엇을 만들어야 하는지는 알겠다.
성공을 확신한 순간은 아니었다.
다만 막연했던 문제가 처음으로 해결 가능한 형태를 갖춘 순간이었다.
동작한다고 서비스가 된 것은 아니었다
구조가 정해지고 SDK가 실행되기 시작한 뒤에도 불확실성은 남아 있었다.
개발 환경에서 동작하는 것과 실제 사용자가 사용하는 것은 다른 문제였다.
앱의 WebView에서 실행되어야 했고, 실제 금융사 페이지 위에서 동작해야 했다. 다양한 기기와 앱 버전, 금융사별 레거시와 보안 솔루션을 통과해야 했다.
무엇보다 이제 실제 사용자가 들어오기 시작했다.
첫 금융사를 오픈한 뒤에는 에러 모니터링을 계속 확인했다. 다행히 큰 문제는 보이지 않았다.
그리고 일주일 정도 지나 결과를 확인했다.
몇 달 동안 고민했던 구조가 실제 사용자 행동 변화로 이어지는지 확인할 수 있는 순간이었다.
기존 흐름과 인앱약정 흐름을 비교했을 때, 인앱약정을 적용한 그룹의 약정 완료율은 기존 대비 30% 가까이 높게 나타났다.
30%p 상승이 아니라 상대적인 개선이었다. 하지만 단순히 동작하는 시스템을 만든 것이 아니라 실제 사용자가 마지막 단계까지 도달하는 경험을 개선했다는 점에서 큰 의미가 있었다.
첫 성공 사례가 생기고 나니 다음 금융사와의 논의도 빨라졌다.
그리고 프로젝트의 성격도 조금씩 달라졌다.
어느 순간부터 SDK가 아니라 사용자를 보고 있었다
초반 내가 가장 많이 고민했던 질문은 기술적인 것이었다.
WebView에서 SDK를 어떻게 안정적으로 실행할까?
스타일은 어떻게 격리할지, 금융사마다 다른 환경을 어떻게 흡수할지, 화면 전환의 책임은 어디에 둘지, 장애가 발생했을 때 어떻게 대응할지.
대부분 기술적인 문제였다.
하지만 실제 사용자가 들어오고 CX팀과 가까이 일하면서 질문이 조금씩 바뀌었다.
대출을 받으려고 여기까지 온 사용자가 왜 마지막 단계에서 실패해야 할까?
대출 신청은 짧은 과정이 아니다.
사용자는 상품을 비교하고, 정보를 입력하고, 동의를 거치고, 심사를 기다린다. 긴 과정을 지나 마지막 단계까지 왔는데 화면이 멈추거나 앱이 종료된다.
신분증을 여러 번 촬영해도 인식되지 않는 경우도 있었다.
개발자 입장에서 보면 각각 다른 문제였다.
WebView 로딩 실패일 수도 있고, 네이티브 문제일 수도 있고, 금융사 보안 솔루션 문제일 수도 있고, 외부 모듈 문제일 수도 있다.
하지만 사용자 입장에서는 모두 같은 경험이다.
대출을 신청하다가 실패한 것이다.
CX팀과 함께 고객 문의를 확인하면서 그 차이를 많이 배웠다.
개발자에게는 하나의 오류 로그였던 것이 고객에게는 중요한 금융 경험의 실패였다.
그때부터 장애를 단순한 기술 문제가 아니라, 사용자가 경험하는 실패의 한 형태로 바라보기 시작했다.
프론트엔드 개발자의 역할을 다시 생각하게 됐다
이 프로젝트가 나에게 특별했던 이유 중 하나는 문제를 바라보는 범위가 넓어졌다는 점이다.
그동안 개발자로 일하면서 대부분의 업무는 이미 정의된 문제를 전달받고, 그 안에서 더 좋은 구현 방법을 고민하는 형태였다. 물론 구현 과정에서도 많은 판단이 필요하다. 하지만 해결해야 할 문제가 무엇인지는 대부분 앞 단계에서 결정되어 있었다.
이번 프로젝트에서는 조금 달랐다.
인앱약정이라는 방향은 조직에서 정한 목표였다. 하지만 그 목표가 실제 성과로 이어지려면 무엇을 개선해야 하는지, 어디에서 사용자가 어려움을 겪는지, 어떤 문제를 우선 해결해야 하는지는 계속 구체화해야 했다.
무엇을 개선해야 하는지 판단하기 위해 먼저 사용자의 흐름을 확인했다. Mixpanel 보드를 구성해 기존 약정 흐름에서 사용자가 어느 단계에서 이탈하는지 살펴봤고, 기술적인 구현 범위를 넘어 실제 개선해야 할 지점을 찾으려고 했다.
문제를 해결하기 위해 CX팀, 금융사, 네이티브팀, 디자인팀 등 다양한 조직과 함께 논의했다. 신분증 인식 경험을 개선하기 위해서는 단순히 코드를 수정하는 것만으로 해결되지 않았다. 고객이 어떤 상황에서 어려움을 겪는지 확인하고, 금융사의 현재 프로세스를 이해하고, 네이티브팀과 가능한 해결 방향을 찾아야 했다.
돌이켜보면 이 경험이 특별했던 이유는 주어진 목표를 실제 해결 가능한 문제로 구체화하는 과정에 참여했다는 점이다. 여러 팀이 각자의 관점에서 말하는 문제를 하나로 정리하고, 그걸 기술 방향으로 옮기는 역할을 어느새 하고 있었다.
개발자가 반드시 코드 안에만 머물 필요는 없다는 것을, 이 프로젝트에서 배웠다.
불확실성을 줄이기 위한 설계
이 프로젝트에서 배운 것은 어려운 기술 자체보다, 불확실성을 다루는 방법이었다.
금융사가 하나 추가될 때마다 새로운 운영 환경이 생겼다.
브라우저가 달랐고, 레거시가 달랐고, 보안 솔루션이 달랐고, 배포 방식도 달랐다.
우리 코드가 같다고 해서 항상 같은 결과를 보장할 수는 없었다.
그래서 우리가 만든 설계들은 대부분 하나의 목적을 가지고 있었다. 반복되는 불확실성을 줄이는 것.
Shadow DOM을 통한 스타일 격리는 금융사마다 다른 CSS 환경과의 충돌 가능성을 줄이기 위한 선택이었다.
SDK 구조 표준화는 금융사별 구현 차이를 줄이고, 새로운 연동이 추가되어도 같은 기준으로 확장하기 위한 선택이었다.
화면 흐름을 SDK가 관리하도록 만든 것은 금융사가 늘어날수록 발생할 수 있는 흐름 제어의 차이를 줄이기 위한 선택이었다.
좋은 설계는 가장 멋진 기술을 고르는 일보다, 앞으로 생길 문제를 미리 줄여가는 과정에 가깝다는 것을 배웠다.
문제를 소유할 때 몰입의 깊이가 달랐다
이 프로젝트를 돌아보며 가장 크게 느낀 것은 몰입의 방식이었다.
처음에는 단순히 어려운 기술을 해결하는 프로젝트라고 생각했다. 하지만 실제로 가장 몰입했던 순간은 새로운 기술을 적용할 때가 아니었다. 내가 왜 이 문제를 풀어야 하는지 이해하고, 어떤 방향으로 가야 하는지 고민하고, 그 결과가 실제 사용자 경험으로 이어지는 과정을 볼 때였다.
주어진 요구사항을 잘 구현하는 것과, 해결해야 할 문제를 함께 고민하는 것은 몰입의 깊이가 달랐다. 내가 이해한 문제가 프로젝트의 방향이 되고, 여러 사람이 함께 움직이고, 결과가 서비스 개선으로 이어지는 경험은 개발자로서 큰 성취감을 줬다.
중요한 문제를 발견하고 해결 과정에 참여하며 결과를 확인할 수 있을 때, 개발자로서 더 깊게 몰입할 수 있었다.
앞으로 어떤 환경에서 성장하고 싶은가
이 프로젝트 이후로 내가 어떤 환경에서 가장 크게 성장하는지 조금 더 분명하게 알게 됐다. 금융 도메인이나 SDK라는 기술적 특성보다, 통제하기 어려운 환경 속에서 무엇이 중요한 문제인지 정의하고, 서로 다른 관점을 가진 사람들이 같은 방향을 보게 만들고, 그 결과가 실제 사용자 경험의 변화로 이어지는 과정을 볼 때 가장 크게 몰입했다.
앞으로도 이런 경험을 할 수 있는 환경에는 내 나름의 기준이 몇 가지 있다.
첫째, 내가 의미를 느끼고 몰입할 수 있는 문제여야 한다. 사용자에게 어떤 영향을 주는지 이해할 수 있고, 해결했을 때 실제 변화를 확인할 수 있는 문제일 때 가장 깊게 몰입할 수 있었다.
둘째, 조직에서도 중요한 문제여야 한다. 아무리 좋은 문제라도 개인의 노력만으로 끝난다면 영향 범위는 제한적이다. 여러 사람이 함께 움직이고 조직의 목표와 연결될 때 더 큰 변화를 만들 수 있다.
셋째, 스스로 문제를 정의하고 해결까지 주도할 수 있는 자율성과 권한이 있는 문화여야 한다. 역할은 존중하되, 더 나은 결과를 위해 의견을 내고 새로운 시도를 할 수 있어야 한다. 그리고 그런 과정 자체를 인정해주는 환경이 중요하다는 것을 배웠다.
결국 내가 찾는 환경은 어려운 기술이 있는 곳만은 아니다. 중요한 문제를 함께 정의하고, 여러 제약 속에서 해결 가능한 구조를 만들고, 그 결과가 실제 사용자와 서비스의 변화로 이어지는 곳이다. 앞으로도 그런 환경에서 문제를 깊게 이해하고 더 나은 구조를 만들어가는 개발자로 성장하고 싶다.
혼자 만든 결과가 아니었다
마지막으로 이 프로젝트는 혼자 만든 결과가 아니었다.
초반부터 중반까지는 만들어야 할 화면이 많았고 일정도 여유롭지 않았다.
그 시기를 함께한 팀원들은 화면 구현뿐 아니라 구조와 방향에 대해서도 적극적으로 의견을 주었다.
야근과 주말 출근을 함께하며 빠듯한 일정 속에서도 첫 출시까지 갈 수 있도록 힘을 보태준 팀원들에게 감사하다.
금융사가 늘어나면서 중요해진 것은 당장 다음 연동을 끝내는 일보다, 앞으로 반복해 쓸 수 있는 구조를 만드는 일이었다.
이 문제의식에 공감하고 함께 기준을 만들어준 팀원들 덕분에 개인적인 고민이 아니라 프로젝트의 방향으로 발전할 수 있었다.
구조를 개선하는 과정에서는 비즈니스 요구사항 변경이 아님에도 금융사 배포 심사가 필요한 경우가 있었다.
우리에게는 필요한 개선이었지만 금융사 입장에서는 추가 업무였다.
그때마다 취지를 이해하고 흔쾌히 협조해주신 금융사 담당자분들께 감사하다. 그런 협조가 없었다면 알고 있던 문제도 쉽게 바꾸지 못했을 것이다.
성과가 보일 때마다 함께 기뻐해주시고 응원해주신 영업 조직에도 감사하다.
우리가 만든 결과가 실제 사업 가치로 연결되고 있다는 것을 계속 느끼게 해주셨다.
그래서 이 프로젝트를 떠올리면 힘들었던 기억만 남지는 않는다.
통제할 수 없는 환경 때문에 고민했던 순간도 있었고, 끝없이 해결해야 할 문제가 생겼던 순간도 있었다.
하지만 함께 고민하고, 방향을 만들고, 결과를 확인하는 과정이 있었기에 즐겁게 일할 수 있었다.
그리고 다시 비슷한 상황을 만나게 된다면, 이전보다 조금 더 빠르게 문제의 본질을 찾고 함께 해결할 수 있는 구조를 만들어가고 싶다.