티스토리 뷰

카테고리 없음

[AM INSPIRE CAMP] 멘토링 3주차

eunnna 2026. 4. 18. 16:50

🌱 들어가며

3회차 멘토링 들어가기 전 우리 팀은 카페 테라스에서 잠깐 여유를 갖는 시간이 있었다 ㅋㅋㅋㅋ

 

 

멘토님이 지각하셔서 커피를 사주셨기 때문이다!! 정말 재밌었다 다음에도 이런 시간이 있었으면 좋겠다 ㅎㅎ
(뭔가 사진을 첨부하고 싶었는데 너무 대충찍어서 부끄럽다... 셋로그 올렸던 거라도 가져왔다)

지난주부터 우리 팀은 페이 시스템을 주제로 정하고 본격적으로 기획을 디벨롭하고 있었는데, 이번 멘토링은 그 기획 과정에서 며칠 동안 팀원들끼리 치열하게 토론했던 페인 포인트들을 멘토님과 같이 풀어나가는 시간이었다. 결제 로직, 더치페이 시나리오, 인증 방식, MCP 서버, AWS 아키텍처, QA 전략까지 진짜 방대한 주제가 오갔다.

이번 글에선 그 내용을 최대한 빠짐없이 기록해두려고 한다. 내가 나중에 다시 봐도 흐름이 살아있도록!

 

💳 1. 지난 주간 팀의 진행 상황 공유

한 주간의 진행 상황을 쭉 정리해서 멘토님께 말씀드렸다. 핵심 내용을 요약하면?

  • 페이 시스템을 만들기로 하면서 페이 / PG사 / 코어뱅킹을 어떻게 구현할지 논의
  • 제일 메인 기능으로는 내 카드 여러 장으로 분할 결제를 두기로 함
  • 오프라인에서 더치페이를 어떻게 처리할지가 제일 큰 고민거리였다 -> 어제까지도 며칠째 토론 중임 ㅜㅜ
  • 유사 서비스를 발견했는데, 우리가 고민했던 페인 포인트를 상당수 해결해둔 상태였다. 팀 내에서 "이거 엎어야 하나?" 하는 분위기도 잠깐 있었다..

멘토님께서는 비슷한 서비스에 관련해서 오히려 좋은 레퍼런스라고 생각하면 안 되는지? 해당 서비스를 잘 참고해서 기능들을 만들어보고, 뛰어넘을 생각이면 그거보다 더 좋은 아이디어를 생각하면 된다. 라고 하셨다!

🏷️ 기존 서비스와의 차별점

기존 서비스는 내 카드 중에서 분할 결제를 할 때 사용자가 어떤 카드로 얼마 결제할지 직접 입력해야 한다. 우리는 여기서 한 발 더 나가서, PG사까지 같이 구현하니까 사용자가 직접 선택하지 않고도 알고리즘이 돌아가서 최적의 카드 조합을 자동으로 제안해주는 방향으로 차별점을 가져가기로 했다. 네 가지 정도의 조합을 보여줄 예정이다!

🚗 2. 인카페이먼트 — 차량 내 결제 아이디어

더 차별점을 고민하다가 한 팀원이 인카페이먼트(In-Car Payment)라는 걸 알려줘서 찾아봤다. 자율주행차나 자동차 OS가 발달하면서, 차 안에서 스타벅스 주문부터 결제까지 차량 내부에서 다 진행되는 사례가 있었다! 안드로이드 스튜디오 에뮬레이터에서 AAOS (Android Automotive OS) 기기를 지원하는 걸 토대로 구현할 수 있다는 아이디어였다.

근데 팀 내부에서 "이건 모빌리티 성격이 너무 강해서 페이 서비스는 하위 기능이 되는 것 같다"는 의견이 나왔다. 그래서 강사님께 여쭤봤더니…

 

"그러면 인터페이스를 여러 군데에 두고 우리 서비스를 오픈 API 형식으로 하는 게 어떠냐. 다른 리테일 조에서 우리 페이 서비스를 갖다 쓰게 하는 건 어떠냐."

 

오! 이 방향으로 생각이 기울어서 오픈 API를 만들어보는 쪽으로 가기로 했다. 리테일 조에서 써줄지 모르겠지만.. 일단 이 방향으로 만드는 걸 생각도 못했던 터라 아주 좋은 피드백이었다!!

 

멘토님 말씀으로는 임원급 시선에서 볼 때 팀 간 협업은 굉장히 좋은 모습이라고 한다.!!! 그렇지만 실제로 팀원들끼리는 회사 내에서도 KPI가 다르고 서로 "더 잘 보이고 싶어서" 사일로처럼 움직이는 경향이 있다고. 지금 우리 상황도 그런 맥락에서 자연스러운 현상이니까, 제안해놓고 상대 팀이 고민할 시간을 주는 게 좋겠다는 조언을 해주셨다.

🔌 3. MCP 서버 — AI 시대의 새로운 연동 방식

멘토님이 추가로 제안해주신 방향이 정말 인상적이었다. 오픈 API뿐만 아니라 MCP 서버로도 제공해보라는 것이다.

MCP 서버에 관해서 지난 멘토링 때도 들었었는데 우리가 MCP 서버를 만든다는 것은 생각지도 못했던 방향이라 너무 좋았다!!!

근데 여기서 문제는 MCP서버가 아직도 뭔지 잘 모르겠다

MCP 서버란?

멘토님이 쉽게 풀어주셨다.

지금까지 외부 서비스 결제를 연동하려면 어떻게 했냐면 — 예를 들어 토스페이먼츠를 붙이려면 토스페이먼츠 도큐먼트 문서 사이트에 들어가서 일일이 스펙 보고, API 콜 코드 따와서 헤더 넣고… 이런 식으로 엄청 수작업이었다.

근데 요새는 AI로 개발하니까 MCP 서버라는 걸 제공하면, 클로드 코드 같은 에이전트에서 MCP 서버 주소만 플러그인처럼 꽂아넣으면 끝이다. 그다음부터는 AI한테 "여기에 토스페이먼츠 연동해줘"라고만 하면 개발이 끝나는 느낌인 것이다

 

구현 방식

  • 실제로 서버로 띄울 수 있음 (FastMCP? 같은 라이브러리 활용)
  • 우리 서비스 엔드포인트 뒤에 /mcp 같은 주소를 붙여놓으면 MCP 서버로 동작
  • 피그마도 MCP 서버를 제공하고 있고, 토스페이먼츠도 MCP 서버가 제공되고 있음
  • Anthropic에서 MCP 서버들을 모아놓은 리스트도 있음 → 우리도 거기에 올릴 수 있으면 어필 포인트가 될 것 같다!!

팀원 한 분이 "AI 활용이 살짝 부족하다고 느꼈는데 이거 하면 좋겠다"고 바로 반응하셨다. 확실히 요즘 트렌드에 맞춰서 어필할 수 있는 좋은 포인트 같다.

🧩 5. 핵심 난제 — 더치페이 결제 로직

여기서부터가 이번 멘토링의 진짜 본론이다. 며칠간 팀이 치열하게 토론했던 더치페이 결제 로직 부분을 멘토님과 같이 풀어나갔다.

기능 포인트 3가지

  1. 혜택 기반 자동 카드 최적화 — 실적, 혜택 베이스로 4가지 카드 조합 제시
  2. 더치페이 — 여러 사람이 한 번에 결제
  3. 오픈 API + MCP 서버 — 어디서든 갖다 쓸 수 있게

이 중에서 1번과 2번은 로직이 구체적으로 합의되어야 나머지 기능들이 진행될 수 있는 상황이었다.

📐 피그마로 정리한 서비스 흐름도

팀원 한 분이 피그마로 서비스 흐름도를 싹 정리해 주셨다. 우리가 논의했던 케이스는 크게 다음과 같다:

구분시나리오핵심 로직

온라인-모바일 내 핸드폰에서 페이로 결제 결제 → 페이 앱 이동 → 금액 확인 → 핀/생체 인증 → 알고리즘 돌려 카드 조합 제시 → PG사 거쳐 결제
온라인-PC 웹사이트에서 QR로 결제 결제창에 QR → 페이 앱으로 스캔 → 모바일에서 인증 → 뒷단 알고리즘 → 결제
오프라인-혼자 가게에서 내가 혼자 결제 페이 앱 실행 → 핀 인증 → QR 제시 → 가게에서 스캔 → 자동 선택 → 결제 완료
오프라인-더치페이 여러 명이서 나눠 결제 대표자 그룹 생성 → 참여자 초대 → 금액 입력/모금 → 최종 QR 생성 → 가게 제시 → 결제

 

더치페이에서 막힌 지점..ㅜㅜ

문제는 더치페이 로직에서 계속 막힌다는 것. 이슈가 이렇게 꼬여있었다:

  • 혜택 기반 자동 카드 추천을 하려면 가맹점 정보와 결제 금액을 알아야 함
  • 근데 가맹점 정보를 알려면 가게랑 연동되어 있어야 함
  • 우리가 가게랑 연동을 하려면 테이블마다 QR이 필요하거나 포스기 연동이 필요함
  • 모든 음식점에 QR이 있다고 가정하는 건 무리 — 포스기 연동도 쉽지 않음
  • 참여자가 앱을 종료하거나 하면 결제 로직이 꼬임

이 부분을 계속 빙빙 돌다가, 멘토님이 시나리오를 직접 짚어주시면서 한 시간 넘게 같이 풀었다.

💡 멘토님이 정리해주신 두 가지 시나리오

잊지 말아야 할 대원칙: 고객과 가맹점이 최대한 편해야 한다! 복잡한 로직은 기능적으로 다 출어나가고 단계를 줄여야된다

 

🅰️ 1안: PG사 선결제 시나리오

  1. 4명이 그룹을 참여. 총 10만 원 결제
  2. 결제 요청이 들어오면 PG사가 가맹점에 먼저 10만 원을 선정산 (카드사까지는 안 감)
  3. 사용자들이 이제 나머지 3명이 얼마씩 N빵 할지 결정
  4. 최종 승인 시점에 고객 카드 정보를 가지고 카드사에 실제 결제 요청을 뿌림
  5. 4개 카드로 2만 5천 원씩 결제가 일어나서 10만 원을 채움

🅱️ 2안: 선결제 후 취소·재결제 시나리오

  1. 4명이 그룹을 참여. 대표 카드로 10만 원 실제 결제 (카드사까지 감)
  2. 나머지 3명의 정산이 완료되면, 기존 10만 원 카드 승인 건을 취소
  3. 4개 카드로 2만 5천 원씩 재결제

각 시나리오의 이슈

이걸 풀다가 엄청 많은 디테일 문제가 나왔다....

  • 시간 오차 문제: 가맹점 정산 시간과 카드사 결제 시간이 다를 수 있음 → 날짜/달이 바뀌는 시점에 문제 발생 가능. 대응: 카드사 API에 결제 일자를 명시해서 넘기거나, 일자 전환 시간대는 큐에 쌓았다가 지나서 처리
  • 할인 문제: 청구 할인과 즉시 할인이 다름. 10만 원 이상 결제 시 8천 원 할인 같은 조건형 할인이 걸려있으면 2만 5천 원씩 쪼갤 때 혜택을 못 받음
  • 수수료 문제: 취소 건은 수수료 없음. 하지만 건당 라우팅 수수료(VAN사 → PG사)는 있을 수 있음. 팀 내부적으로 "이건 프로젝트니까 일단 걱정 말자"는 결론
  • 돈 없을 때: 대표자가 결제 실패하면 다음 참여자 카드로 시도. 최대 4번 반복. 근데 딜레이가 걸림. 멘토님 말씀: "거기까지 고민은 아무도 안 해줄 수도 있어요. 카드 실패하면 그냥 콜백 나가면 돼요"

최종적으로 잡힌 방향

멘토님이 정리해주신 방향은 다음과 같다.

 

--> 청구 할인이 들어가는 카드로 대표자가 먼저 결제하고, 정산할 때는 가장 혜택 좋은 카드 시나리오를 보여준 뒤 사용자가 선택. 그러면 기존 결제를 취소하고 선택한 카드로 재결제 + 나머지는 계좌 이체(충전식)로 보내주는 기능까지 포함

 

 

즉, 기존에 배제했던 계좌 이체 / 충전식 기능을 다시 포함시키기로 한 것. 카카오페이, 네이버페이, 토스페이 같은 유사 서비스가 다 충전식이니까 사용자 경험상으로도 어색하지 않다는 판단이었다.

 

우리는 카드 결제 서비스니까 계좌 이체 개념을 빼자고 처음에 결정했는데, 결국 현실적인 결제 로직을 돌리려면 계좌 이체 기능을 포함해야 한다는 결론으로 돌아옴. 기획이 이렇게 돌고 돌아 다시 수정되는 과정이 진짜 기획자의 일이구나 싶었다. ㅠㅠ 기획자 어떻게 하는 거지

 

🔐 7. OAuth vs 자체 인증서 (MTLS)

회원 인증 방식에 대한 논의도 있었다. 한 팀원이 "페이 앱에서 OAuth(카카오, 구글 로그인 등)를 쓰는 게 보안상 괜찮을까요?"라고 질문했다.

멘토님 답변: OAuth 쓰는 게 오히려 더 안전할 수 있다

  • 카카오뱅크도 카카오 OAuth 인증을 붙여서 사용하고 있음
  • 자체 인증 구축보다 카카오/구글 같은 큰 플랫폼의 보안 시스템을 신뢰해서 연동하는 게 일반적으로 더 안전함
  • 카카오가 뚫리면 한국이 난리, 구글이 뚫리면 전 세계가 난리일 정도ㅜㅋㅋ 지금까지 OAuth 2.0이 뚫린 사례는 없음

MTLS (Mutual TLS) — 더 안전한 방식

진짜 핀테크급 보안을 원하면 MTLS (양방향 TLS 인증) 방식이 있다고 알려주셨다.

일반 TLS vs MTLS

  • 일반 TLS: 서버가 클라이언트에게 "나는 안전한 서버야"라고 인증서를 제공하는 일방향 인증
  • MTLS: 서버가 "나도 안전하지만, 너도 안전한 클라이언트야?" 하고 양방향으로 서로 인증서를 교환하는 방식

진행 흐름은 이렇다:

  1. 회원가입 때 인증 회원 상향 과정을 수행
  2. 단말에 자체 인증서를 발급해서 심어놓음 (공인인증서, 금융인증서 같은 느낌)
  3. 로그인해서 들어가면, 서버는 클라이언트에게도 인증서를 요청
  4. 서로 인증서를 주고받아 상호 인증 완료

은행 앱에서 핸드폰 바꾸면 인증을 다시 받아야 하는 이유가 바로 이 단말 인증서를 다시 발급받기 때문이라고 한다. 새 폰에서 계좌 인증 받으면 "너네 안전하네, 인증서 다시 내려줄게" 하면서 다시 심어주고, 이전 단말에선 더 이상 접속 못 하게 되는 것.

 

결론: 핀테크 관련해서 "진짜 안전"을 추구한다면 MTLS 방식을 구축하는 게 이상적이지만, 자체 인증서 구축은 난이도가 높다. 우리 프로젝트는 OAuth로 가고, MTLS는 이론으로 알고 있으면 좋은 방식으로 정리!

 

 8. 시스템 아키텍처

구현해야 할 서비스 단위 논의로 넘어갔다. 페이 시스템이면 결국 실제 돈 흐름을 흉내 내야 하니까, 최소한 다음 구조가 필요하다:

  • 오픈뱅킹 서버: 카드사를 가정하는 코어뱅킹. 계좌 조회 / 실명 조회 / 입금 이체 / 카드 조회 API 제공
  • 페이 서버: 회원 정보, 계좌/카드 연동, PG사 기능까지 수행
  • 페이 애플리케이션: React Native로 만드는 모바일 앱

PG사 기능은 페이 서버가 대행하는 개념으로 합침. 가맹점과 카드사는 실제 구현 없이 시나리오상 존재하는 것으로 두되, QR 코드 시연 정도는 구현하기로 했다

네임스페이스와 리소스 쿼터 개념

MSA로 쪼갤 때 쿠버네티스 차원에서 어떻게 격리할지 설명을 해주셨다!!!

탄탄한 아키텍처는 이렇게 네임스페이스로 오픈뱅킹용 / 페이 서버용을 각각 격리해서 두는 구조라고 한다.

 

그리고 프로젝트 시작 전에 AWS 리소스 사용 계획서를 제출해야 한다고 한다. 미니 2차 때는 대충 써도 넘어갔는데, 최종 프로젝트는 깐깐하게 본다고 이미 들은 상태. 감이 안 잡힌다…

멘토님이 구체적으로 산정 기준을 잡아주셨다!

🧰 9. QA와 테스트 — 실무 프로세스

멘토님께 "테스트 케이스를 어떻게 작성하면 좋을지" 여쭤봤다. 실제 실무에서 어떻게 돌아가는지 자세히 설명해 주셨다.

테스트 단계별 프로세스

  1. 개발자 단위 테스트
  2. 정적 분석
  3. 기획자 베이스 시나리오 테스트
  4. QA 팀 테스트
  5. CBO (Closed Beta Open/Test)
  6. Open

🎨 10. 추가 기능 아이디어 — "대신 결제 요청하기" / 카드 다이어트

기능 확장 아이디어에 대해서도 의견을 여쭤봤다.

대신 결제 요청하기

페이코에서 본 기능인데, 아이가 뭘 사고 싶은데 부모한테 "대신 결제해줘" 요청을 보내는 식. 미용실 예약 후 매장에서 어플로 직접 결제 요청이 오는 것도 비슷한 맥락이다

 

피드백: 결제로 할 수 있는 거의 대부분은 할 수 있을 것 같아요. PG사처럼 움직이니까요. 일단 메인 기능에 최선을 다하고, 마일스톤 2로 붙여도 좋겠어요.

 

카드 추천 서비스

  • 정산할 때 광고처럼 "이 카드로 결제하면 최대 X원 절약" 식의 추천이 뜨는 것
  • 실제로 카드고릴라처럼 혜택 비교 서비스 시장이 잘 돌아가는 이유가 여기 있음
  • 수수료 사업으로도 괜찮은 방향. 카드사들이 자기네 카드를 올리려고 돈 내는 구조

카드 다이어트 (안 쓰는 카드 해지)

  • 안 쓰는 카드 해지를 추천해주는 기능
  • 다만 카드사 입장에선 해지 유도가 달갑지 않음
  • 우리 서비스 확장을 위해선 카드사와 좋은 관계 유지가 중요 → 해지보다는 "추가" 유도가 비즈니스적으로 더 좋음
  • 처음엔 "카드사 몰래" 시작하지만, 나중에 카드사와 딜할 때는 수수료 협상 카드로 활용 가능

멘토님 왈: 기획 얘기를 많이 안 하려고 한다. 제 의견이 너무 많이 들어가면 여러분이 하청처럼 일하는 느낌이 될 수 있어서요. SI처럼 일하지 말고, IT 서비스를 만드는 핀테크 회사처럼 일하세요. 여러분들이 기획하고 여러분 아이디어로 서비스를 만들었을 때 좋은 효과를 거두는 경험이 중요합니다

🚀 11. 다음 멘토링까지의 계획

다음 멘토링까지는 3주 텀이 있다 (중간에 연휴가 껴있어서 ㅠㅠ ).

그 사이 진행할 것

  • 다음 주: 기획 최종 정리 → 요구사항 명세서 / BRD / DB 설계 / API 명세 / 시스템 아키텍처 / 와이어프레임 마무리
  • 그 다음 주: 개발 환경 세팅, 프로젝트 생성, DB 설계 반영, CRUD성 기능 어느 정도 완성
  • 그다음: CI/CD 연결, DB 붙여서 작업까지 (연휴 이후)

다음 멘토링 (4회차 예정)

  • 기간: 3주 후 (연휴 이후)
  • 방식: 개인 1:1 30분씩
  • 주제: 자소서 / 포트폴리오 피드백, 면접 준비, 진로 고민 등
  • 준비물: 자소서, 포트폴리오 초안
  • 점심도 같이 먹기로 했다!! 🍽️

💭 마치며

정말 긴 세션이었지만, 이번 멘토링은 내내 "실무에서 어떻게 결정을 내리는지"를 간접 체험하는 느낌이었다. 특히 더치페이 결제 로직 부분에서 팀 내부적으로 며칠을 쳇바퀴 돌았던 문제가, 멘토님이 한 번 시나리오를 짚어주시니까 단번에 정리되는 걸 보면서… 현업 개발자의 시야가 얼마나 다른지 실감했다.

그리고 오늘의 가장 큰 깨달음은 이거였다:

"기획에서 2~3주를 쓰는 건 아깝지 않아요. 오히려 개발 실제로 들어가서 코드 만지는 것보다 더 귀중한 경험일 수 있어요."

 

개발자 커리어를 준비하면서 코드에만 너무 몰입했던 것 같은데, 기획 / 의사결정 / 협업 과정 자체가 포트폴리오의 핵심 자산이 될 수 있다는 걸 다시 한번 느꼈다.

MCP 서버 도입, OAuth vs MTLS, 쿠버네티스의 Pod/Node 구조, QA 프로세스 등등 한 번에 너무 많은 내용이 들어와서 솔직히 지금 머리가 좀 터질 것 같다 🤯 일단 오늘 배운 건 여기 기록해두고, 팀과 논의하면서 하나씩 구체화해나가야겠다.

그리고 3주 후에 멘토님과 밥도 먹고, 자소서 / 포트폴리오 피드백까지 받는다니 벌써부터 기대된다. 😊

다음 회차 후기로 또 돌아오겠습니다!!

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
TAG
more
«   2026/07   »
일 월 화 수 목 금 토
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함