[23호]. AI로 다 빨라진다더니, 돈 앞에서는 왜 다시 느려질까

PRD는 몇 시간 만에 만들었지만, 여전히 서류와 메일, 때로는 팩스가 필요했습니다.

2026.07.22 | 조회 263 |
0
|
from.
Product Makers Note
첨부 이미지

안녕하세요. 성수동에 있는 회사에서 다시 핀테크 서비스를 만들고 있는 hubert입니다.

얼마 전 회사를 옮기면서 출근길도, 함께 일하는 사람들도 바뀌었습니다. 공교롭게도 몇 년 만에 다시 핀테크 도메인을 맡게 되었고요.

그 사이 AI 덕분에 제가 제품을 만드는 방식도 많이 달라졌습니다. 예전에는 며칠이 걸렸던 일을 이제는 몇 시간 만에 해볼 수 있게 되었습니다.

그런데 핀테크 도메인으로 돌아가자 분위기가 달랐습니다. AI로 화면과 코드를 빠르게 만들다가도, 실제 서비스를 연결할 때는 서류의 빈칸을 채워 메일로 보내야 했습니다. 팩스를 써야 할 때도 있었고요.

모든 것이 자동화되는 시대라고 생각했는데, 돈이 움직이는 구간에 들어가면 속도가 갑자기 끊기는 느낌이 들었습니다. 처음에는 오래된 업무 방식 때문이라고만 생각했지만, 일을 조금 더 들여다보니 모든 느림이 같은 느림은 아니었습니다.

이번 글에서는 AI로 빠르게 일하면서도 제가 돈 앞에서 한 번 멈추게 된 이유와, 그 이후 AI를 활용하는 기준을 어떻게 나누게 되었는지 이야기해보려고 합니다.


1. AI 덕분에 ‘만드는 과정’은 정말 빨라졌습니다

저는 AI를 꽤 거침없이 사용하는 편입니다.

PRD를 작성할 때는 AI와 함께 초안을 만듭니다. 문제 정의와 요구사항의 구조를 잡고, 놓친 예외 케이스가 없는지 확인합니다. 복잡하게 쓴 문장을 다시 읽기 쉽게 정리해달라고 요청하기도 합니다.

목업도 직접 만듭니다. 예전에는 기획 의도를 문서로 길게 설명하거나 디자이너의 손을 기다려야 했던 화면을, 이제는 제가 먼저 만들어볼 수 있습니다. 완성된 디자인은 아니더라도 버튼을 눌렀을 때 어떤 일이 일어나는지, 사용자가 어떤 순서로 이동하는지는 충분히 보여줄 수 있습니다.

그렇게 만든 목업을 개발자와 함께 보면 대화도 달라집니다. 문장만 보고 서로 다른 화면을 상상하는 대신, 실제 흐름을 보면서 빠진 상태값이나 구현하기 어려운 부분을 이야기할 수 있습니다. 제가 생각한 기획 의도와 개발자가 이해한 내용이 어디서 달라지는지도 훨씬 빨리 발견할 수 있고요.

바이브 코딩도 비슷합니다. 아이디어가 떠오르면 일단 만들어보고 직접 실행해봅니다. 예상과 다른 부분을 찾으면 다시 고칩니다. AI가 완성된 제품을 대신 만들어준다기보다, 설명으로만 존재하던 아이디어를 실제 흐름으로 확인하는 시간이 짧아졌습니다.

목업이 어색하면 고치고, PRD가 허술하면 리뷰에서 보완합니다. 프로토타입은 방향이 틀렸다면 버리고 다시 만들 수 있습니다. 수정 비용이 낮으니 AI를 과감하게 써도 부담이 적었습니다.

그런데 결제 서비스를 만들기 시작하자 이 속도가 그대로 이어지지는 않았습니다.

 

2. 결제 서비스는 회사 안에서만 만들 수 없었습니다

핀테크, 특히 결제 서비스는 회사 내부의 개발만으로 완성되지 않습니다. PG사를 비롯한 여러 제휴사와 함께 움직여야 합니다. 할인을 적용하려면 필요한 정보를 정리해 전달해야 하고, 카드사의 가맹점 번호를 취득하려면 별도의 절차도 밟아야 합니다.

그 과정에는 생각보다 많은 수기 업무가 남아 있었습니다. 필요한 내용을 확인해 서류에 옮기고, 담당자에게 메일이나 팩스로 보낸 뒤 처리가 끝났는지 다시 확인했습니다. AI로 PRD와 목업을 빠르게 만들었더라도, 실제 서비스를 연결하는 과정에서는 잠시 멈춰야 했습니다.

규제도 함께 살펴야 했습니다. 무엇을 만들 수 있는지뿐만 아니라 전자금융감독규정을 비롯한 여러 규제 안에서 어디까지 가능한지 확인해야 했습니다. 새로운 기술을 사용할 수 있다는 사실과 금융 서비스에서 그 기술을 바로 사용할 수 있다는 사실은 같은 말이 아니었습니다.

금융 서비스의 업무 환경에서 생성형 AI를 본격적으로 활용하려면 망분리 규제와 보안 요건도 함께 살펴야 합니다. 생성형 AI는 대부분 인터넷과 클라우드 환경을 통해 제공됩니다. 반면 금융회사는 오랫동안 내부 업무망과 인터넷망을 분리해 운영해왔습니다. AI를 사용할 기술은 준비되어 있어도, 실제 업무 환경에서는 접근부터 어려운 경우가 생깁니다.

금융당국도 이 문제를 인식하고 규제를 단계적으로 개선하고 있습니다. 2024년에는 생성형 AI와 SaaS 활용을 확대하는 내용의 금융분야 망분리 개선 로드맵이 발표되었습니다. 현재 생성형 AI는 규제 샌드박스를 통해 활용되고 있으며, 금융당국도 관련 제도화를 추진하고 있습니다. 다만 핀테크 업계에서는 관련 논의가 여전히 금융회사 중심으로 흘러간다는 아쉬움도 나옵니다.

관련 인터뷰에서 이혜민 대표는 기업의 규모나 분류보다 실제 보안 역량과 책임 체계를 기준으로 제도를 설계해야 한다고 이야기했습니다. 저도 이 부분에 공감했습니다.

규제를 피해서 AI를 사용하는 것이 아니라, 어떤 데이터를 어디까지 활용할 수 있는지, 문제가 생겼을 때 누가 책임질 것인지 먼저 정리되어야 합니다.

결제 서비스가 느린 이유는 낡은 절차만이 아니었습니다. 그다음 단계에서 실제 돈이 움직이고, 누군가는 그 결과에 책임을 져야 하기 때문이었습니다.

 

3. 돈을 움직이는 실수는 성격이 달랐습니다

정산 금액을 계산하고, 환불을 실행하고, 고객의 한도를 결정하는 순간부터는 이야기가 달라졌습니다. AI가 만든 결과가 문서를 넘어 실제 돈의 이동으로 이어지기 때문입니다.

여기까지 AI에 온전히 맡기려니 저는 조금 두려웠습니다. AI가 못해서도, 사람이 언제나 더 정확해서도 아닙니다. 잘 설계된 자동화는 오히려 사람이 반복해서 처리하는 것보다 정확할 때도 있으니까요.

다만 이 영역의 실수는 되돌리는 방식이 달랐습니다. 정산 기준이 하루 잘못 적용되면 그날의 거래가 잘못된 기준으로 처리될 수 있습니다. 환불이 두 번 실행되면 숫자를 수정하는 것만으로 끝나지 않습니다. 한도 판단이 잘못되면 고객의 금융 경험에도 직접 영향을 줍니다.

기술적으로 이전 상태로 복구할 수 있더라도, 이미 발생한 손실과 고객의 불편, 무너진 신뢰까지 깨끗하게 되돌리기는 어렵습니다.

곰곰이 생각해보니 제가 걱정한 건 AI 자체가 아니었습니다. AI의 답이 별도 확인 없이 실행으로 이어지는 구조가 걱정됐던 겁니다. 그 뒤로는 AI가 얼마나 똑똑한지보다, 잘못됐을 때 원래 상태로 돌아갈 수 있는지를 먼저 보게 되었습니다. 그 질문에 자신 있게 답하기 어려운 곳이 제가 멈춰야 할 지점이었습니다.

 

4. AI가 만든 답은 어디에서 멈춰야 할까

저는 요즘 AI를 활용하기 전에 세 가지를 먼저 생각해봅니다.

이 결과가 틀려도 고객에게 닿기 전에 되돌릴 수 있는가.
이 결과가 실제 돈이나 고객의 권리에 영향을 주는가.
문제가 생겼을 때 판단의 근거를 설명하고 복구할 수 있는가.

PRD 초안이나 목업처럼 다시 만들 수 있는 일이라면 AI가 먼저 결과물을 만들게 합니다. 경우의 수를 펼치고, 프로토타입으로 아이디어를 확인하는 일도 적극적으로 맡깁니다. 반대로 정산, 환불, 한도처럼 실제 실행으로 이어지는 일이라면 AI의 역할을 제안까지로 제한합니다.

AI가 정산 기준의 초안을 정리하고, 환불 정책에서 놓친 경우의 수를 찾고, 확인해야 할 규정을 목록으로 만들 수는 있습니다. 하지만 그 결과는 사람이 다시 확인합니다. 근거와 영향 범위를 검토하고, 문제가 생겼을 때 중단하거나 복구할 방법을 준비한 뒤 최종 실행을 승인합니다.

제가 정리한 기준은 이렇습니다.

되돌릴 수 있는 일에서는 AI가 먼저 만들게 합니다.
되돌리기 어려운 일에서는 AI가 먼저 제안하게 합니다.
마지막 판단과 실행은 책임질 수 있는 사람이 맡습니다.

이 기준으로 다시 보니, 금융 서비스에 남아 있는 느림도 조금 다르게 보였습니다.

서류와 메일, 팩스처럼 전달 방식 때문에 생기는 지연은 줄여야 합니다. 같은 정보를 여러 번 입력하고 사람이 반복해서 옮기는 것이 반드시 더 안전한 것은 아니기 때문입니다. 반면 정산 기준을 확인하고, 규제의 범위를 살피고, 실행 전에 영향 범위를 점검하는 시간은 남겨야 합니다.

우리가 지켜야 하는 것은 오래된 작업 방식이 아니었습니다.
AI가 만든 답이 되돌리기 어려운 결정으로 곧바로 이어지지 않게 하는 구조였습니다.

요즘은 느린 업무를 만나면 먼저 그 이유부터 살펴봅니다. 같은 정보를 반복해서 옮기느라 느린 일이라면 자동화합니다. 하지만 돈이 움직이기 전에 확인이 필요해서 느린 일이라면, 그 단계는 사람이 맡아야 한다고 생각합니다.

여러분의 일에서는 어떤가요?
AI가 더 빨라질수록, 오히려 천천히 지나가야 하는 지점은 어디인가요?

여러분이 일하면서 발견한 경계선도 댓글로 들려주세요.


📮 다음 호 예고

[24호] 기획자를 위한 AI 설계 4부작 ① 가드레일 — AI에 브레이크 달기

AI 서비스 만들 때 모델 잘 고르면 끝났다고 생각하나요? 아닙니다. 모델 성능은 모델러 일이 맞아요 근데 기획자가 아래 4가지를 잘 설계해줘야 좋은 모델이 좋은 AI 서비스로까지 연결됩니다.

4가지는 바로 가드레일, Tool Use, Human-in-the-loop, Context 입니다. 모델을 가드레일로 붙잡고, Tool로 실제 일을 하게 만들고, 사람과 잇고(HITL), Context로 상황을 이해시켜야 — 비로소 쓸 만한 서비스가 됩니다.

좋은 AI 모델을 진짜 서비스로 만드는 4가지 장치에 대한 글을 4회 연속 연재할게요. 1편 가드레일부터 다음 호에서 만나요.

✉️ 다음 호가 궁금하신 분들은 아래 [구독하기] 버튼을 눌러주세요.

 

 

다가올 뉴스레터가 궁금하신가요?

지금 구독해서 새로운 레터를 받아보세요

✉️

이번 뉴스레터 어떠셨나요?

Product Makers Note 님에게 ☕️ 커피와 ✉️ 쪽지를 보내보세요!

댓글

의견을 남겨주세요

확인
의견이 있으신가요? 제일 먼저 댓글을 달아보세요 !

다른 뉴스레터

© 2026 Product Makers Note

「판교에서 여의도까지」 — ✉️ 프로덕트 메이커들의 기획·디자인·AI 노트

뉴스레터 문의note4makers@gmail.com

메일리 로고

도움말 오류 및 기능 관련 제보

서비스 이용 문의admin@team.maily.so 채팅으로 문의하기

메일리 사업자 정보

메일리 (대표자: 이한결) | 사업자번호: 717-47-00705 | 서울특별시 송파구 위례광장로 199, 5층 501-2-31호

이용약관 | 개인정보처리방침 | 정기결제 이용약관 | 라이선스