[35호] 빨라진 구현, 느려진 실행

AI가 먼저 만들어도 되는 일과 제안까지만 맡길 일을 어떻게 구분할까요?

2026.10.16 | 조회 176 |
0
|
from.
Product Makers Note
첨부 이미지

안녕하세요, 구독자님. 프로덕트를 만들며 생각이 점점 많아지고 있는 hubert입니다.

요즘 AI로 코드를 짜는 일이 꽤 재미있습니다. 예전에는 개발자에게 요청하거나 직접 공부해야 했던 일들을 이제는 AI에게 물어보며 하나씩 만들어볼 수 있더라고요. 저도 최근 업무에서 필요했던 간단한 도구들을 AI로 만들어보고 있습니다.

처음에는 신기했습니다. 원하는 기능을 설명했더니 코드를 만들어주고, 실행 방법까지 알려줬으니까요. 중간에 오류가 발생해도 메시지를 전달하면 수정할 방법을 찾아줍니다.

그런데 몇 번 사용하다 보니 한 가지 고민이 생겼습니다. 만드는 속도는 빨라졌는데, 이걸 실제로 사용해도 되는지 확인하는 일은 여전히 제 몫이었습니다.

이번 글에서는 제가 AI로 두 가지 기능을 만들어보면서 경험했던 일을 공유해보려고 합니다. 그리고 PM 입장에서 AI에게 어디까지 맡기면 좋을지, 요즘은 어떤 방식으로 활용하고 있는지도 이야기해보겠습니다.

 

같은 AI를 사용해도 결과는 달랐습니다

최근 AI를 이용해 두 가지 작업을 해봤습니다. 하나는 테스트에 필요한 기능이었고, 다른 하나는 결제 운영 과정에서 발생할 수 있는 문제를 확인하기 위한 도구였습니다. 두 작업 모두 제가 원하는 기능을 설명하고 AI가 코드를 만들어주는 방식으로 진행했습니다.

처음에는 비슷한 작업이라고 생각했습니다. 요구사항을 전달하고, 만들어진 코드를 실행해보고, 문제가 있으면 수정하면 되는 일이었으니까요. 그런데 직접 해보니 차이가 있었습니다. 테스트를 위한 도구는 비교적 부담 없이 시도할 수 있었습니다. 잘못 만들어지면 다시 수정하거나 처음부터 만들어보면 됐습니다.

반면 결제 운영과 관련된 기능은 달랐습니다. 실제 거래 데이터를 다루는 일이다 보니 잘못된 결과를 보여주거나, 정상적인 거래를 잘못 처리하면 문제가 커질 수 있었습니다. 같은 AI가 코드를 만들어줬지만, 제가 확인해야 하는 부분은 전혀 달랐던 거죠.

 

자동취소가 실패한 거래를 찾아봤습니다

결제 시스템에는 여러 가지 예외 상황이 발생합니다.
결제가 정상적으로 처리되지 않거나, 취소 요청이 실패하기도 합니다. 이런 상황에 대비해 자동으로 취소를 시도하는 기능을 운영하기도 합니다. 그런데 자동취소 기능이 있다고 모든 문제가 해결되는 것은 아닙니다. 취소 요청 자체가 실패할 수도 있기 때문입니다.

예를 들어 1,000건의 거래에 대해 취소 요청을 보냈다고 가정해보겠습니다. 대부분 정상적으로 취소됐지만 일부 거래는 실패했다면, 운영 담당자는 어떤 거래가 실패했는지 확인하고 해당 거래의 상태를 다시 조회해야 합니다. 이후 재처리가 가능한 거래인지 확인하거나 별도의 조치를 취해야겠죠.

저는 이 과정에서 사용할 수 있는 도구를 AI로 만들어봤습니다. 자동취소가 실패한 거래를 찾아보고, 거래 상태를 확인한 뒤 필요한 조치를 판단할 수 있도록 하는 것이 목적이었습니다. 기능 자체는 생각보다 빠르게 만들어졌습니다. 원하는 내용을 설명하니 AI가 코드를 작성해줬고, 실행하면서 필요한 부분을 수정할 수 있었습니다.

그런데 여기서부터 고민이 시작됐습니다. AI가 찾아낸 거래가 정말 제가 찾으려던 거래인지 어떻게 확인할 수 있을까요? 단순히 화면에 거래 목록이 나타난다고 기능이 완성된 것은 아니었습니다. 이미 취소가 완료된 거래가 포함되지는 않았는지, 반대로 확인해야 할 거래가 누락되지는 않았는지 살펴봐야 했습니다. 무엇보다 거래 상태를 잘못 판단하면 정상적인 거래에 불필요한 조치를 할 수도 있었습니다.

테스트용 도구를 만들 때는 크게 고민하지 않았던 부분이었습니다. AI는 제가 요청한 기능을 빠르게 만들어줬지만, 그 기능이 실제 운영 환경에서도 문제없이 동작할지는 별도로 확인해야 했습니다.

예전에는 개발팀에 기능을 요청하고 결과물을 검토하는 일이 익숙했습니다. 그런데 AI를 이용하니 제가 직접 기능을 만들어볼 수 있게 됐습니다. 분명 편리해졌지만, 그만큼 제가 판단해야 할 일도 늘어난 셈입니다. 코드가 실행된다는 것과 실제 업무에서 사용할 수 있다는 것은 다른 문제였습니다.

 

요즘은 AI에게 만들기 전에 세 가지를 먼저 물어봅니다

몇 번 시행착오를 겪고 나니 AI를 사용하는 방식도 조금 달라졌습니다. 예전에는 필요한 기능이 생각나면 바로 만들어달라고 요청했습니다. 요즘은 그 전에 세 가지를 먼저 확인하려고 합니다.

첫 번째, 만들려는 기능을 충분히 설명할 수 있는가

생각보다 이게 쉽지 않았습니다. 예를 들어 ‘취소에 실패한 거래를 조회하는 기능’이라고 설명하면 간단해 보입니다. 그런데 조금만 자세히 생각해보면 정해야 할 것들이 많습니다. 취소 실패는 어떤 상태를 의미할까요? 취소 요청을 보냈지만 응답을 받지 못한 거래도 실패로 봐야 할까요? 이미 취소된 거래는 어떻게 구분해야 할까요? 부분취소가 발생한 거래는 어떤 기준으로 보여줘야 할까요?

이런 내용을 충분히 정리하지 않고 AI에게 요청하면, AI는 부족한 정보를 나름대로 해석해서 코드를 만들어줍니다. 문제는 그 해석이 제가 생각했던 업무 방식과 다를 수 있다는 점입니다. 그래서 요즘은 기능을 만들기 전에 제가 생각한 처리 기준부터 정리합니다.

두 번째, 결과가 정상적인지 직접 확인할 수 있는가

AI가 만들어준 코드를 모두 이해하기는 어렵더라도, 결과가 맞는지는 확인할 수 있어야 한다고 생각합니다. 취소 실패 거래를 조회하는 기능이라면 어떤 거래가 조회돼야 하고, 어떤 거래는 제외돼야 하는지 제가 판단할 수 있어야 합니다. 정상적인 거래와 예외 거래를 구분할 수 있는 테스트 데이터도 필요하겠죠.

만약 결과가 잘못됐는데도 그 사실을 알아차릴 수 없다면, 기능을 만들어도 실제 업무에 사용하기는 어렵습니다.

세 번째, 문제가 발생했을 때 어디까지 영향을 미치는가

제가 가장 신중하게 생각하는 부분입니다. 테스트 환경에서 데이터를 조회하는 기능과 실제 운영 환경에서 거래 상태를 변경하는 기능은 다릅니다. 조회 결과가 잘못됐다면 다시 확인할 수 있지만, 잘못된 거래를 취소하거나 데이터를 변경했다면 상황이 복잡해집니다.

그래서 운영에 영향을 줄 수 있는 기능은 처음부터 자동으로 처리하도록 만들지 않으려고 합니다. 우선 필요한 데이터를 정확하게 조회할 수 있는지 확인하고, 실제 조치가 필요한 부분은 사람이 판단하는 방식으로 접근합니다. 물론 실제 시스템에 적용할 때는 개발팀의 검토와 보안, 권한, 테스트도 필요합니다. AI가 만들어준 기능이라고 해서 이런 과정을 생략할 수는 없으니까요.

 

꼭 직접 만들어야 하는 건 아니었습니다

AI를 사용하다 보면 신기한 마음에 이것저것 만들어보고 싶어집니다. 저도 그랬습니다. 간단한 요구사항만 전달했는데 실제로 동작하는 코드를 만들어주니, 평소에 생각만 했던 기능도 한번 구현해보고 싶어지더라고요. 그런데 모든 기능을 직접 만들 필요는 없었습니다. 특히 기존 시스템에 연결해야 하거나 중요한 데이터를 처리하는 기능이라면 더욱 그렇습니다.

요즘은 직접 구현하기 어려운 작업도 AI에게 먼저 검토를 요청합니다. 어떤 기능이 필요할 때 바로 코드를 만들어달라고 하기보다, 필요한 요구사항과 예상되는 예외 상황을 먼저 정리해달라고 합니다. 제가 미처 생각하지 못했던 부분을 발견할 때도 있습니다.

이렇게 정리한 내용을 가지고 개발자와 논의하면 조금 더 구체적인 이야기를 나눌 수 있습니다. 어떤 데이터가 필요한지, 기존 시스템에서 활용할 수 있는 기능이 있는지, 실제로 구현하려면 어떤 부분을 확인해야 하는지 미리 살펴볼 수 있으니까요. PM 입장에서는 이것만으로도 도움이 됩니다. 막연하게 ‘이런 기능이 있으면 좋겠다’고 생각했던 것을 조금 더 구체적인 요구사항으로 정리할 수 있게 됐습니다.

물론 AI가 정리해준 내용이 모두 맞는 것은 아닙니다. 실제 시스템의 구조나 정책을 모르는 상태에서 제안한 내용일 수도 있으니 확인이 필요합니다. 그래도 개발팀과 논의하기 전에 생각을 정리하는 용도로는 충분히 활용할 만했습니다.

 

제가 사용하는 프롬프트를 공유합니다

저는 요즘 AI에게 기능 구현을 요청할 때 처음부터 코드를 만들어달라고 하지 않습니다. 먼저 요구사항을 확인하고, 제가 놓친 부분이 없는지 살펴봅니다. 이후 테스트 데이터를 활용해 작은 기능부터 만들어봅니다.

앞에서 이야기한 자동취소 실패 거래 조회 기능을 예시로 정리해봤습니다. 필요한 부분을 복사해서 각 회사의 시스템 구조와 정책에 맞게 수정해보셔도 좋겠습니다.

 

① 요구사항을 검토하고, 테스트 데이터로 구현하기

당신은 결제 시스템을 이해하는 백엔드 개발자입니다.?
저는 결제 서비스를 담당하는 PM입니다.
자동취소에 실패한 거래를 확인하는 간단한 운영 도구를 만들고 싶습니다.

필요한 기능은 다음과 같습니다.

  • 취소 실패 거래 목록 조회
  • 거래별 결제·취소 상태 확인
  • 실패 원인과 오류 코드 확인
  • 재처리가 필요한 거래 구분

코드를 작성하기 전에 다음 내용을 검토해주세요.

1. 추가로 확인해야 할 요구사항

2. 발생할 수 있는 예외 상황

3. 구현에 필요한 데이터

4. 운영 시 주의해야 할 사항


확인되지 않은 내용은 임의로 판단하지 말고 저에게 먼저 질문해주세요.
요구사항이 정리되면 테스트 데이터로 동작하는 간단한 조회 화면을 만들어주세요.
실제 거래 데이터나 상태 변경 기능은 제외합니다.

여기서 중요한 건 제가 생각하지 못했던 예외 상황이나 추가로 확인해야 할 요구사항을 먼저 찾아보는 것입니다. 실제 결제 시스템과 연결하지 않고 테스트 데이터로 구현하도록 요청하면 부담 없이 결과물을 확인할 수 있습니다.

 

② 만들어진 기능이 제대로 동작하는지 확인하기

지금 만든 기능이 요구사항에 맞게 동작하는지 확인할 수 있도록 테스트 시나리오를 작성해주세요.
다음 상황을 반드시 포함해주세요.

  • 정상적으로 취소된 거래
  • 취소 요청이 실패한 거래
  • 취소 요청 후 응답이 없는 거래
  • 부분취소가 발생한 거래
  • 동일 거래에 취소 요청이 중복된 경우

각 상황별 테스트 방법과 예상 결과를 표로 정리해주세요.
추가로 누락된 요구사항이나 위험 요소도 확인해주세요.
실제 테스트하지 않은 내용은 정상 동작한다고 판단하지 말아주세요.

테스트 시나리오를 정리하도록 요청하면 정상적인 상황뿐 아니라 다양한 예외 상황도 함께 살펴볼 수 있습니다. 물론 AI가 작성한 시나리오만으로 검증이 끝나는 것은 아닙니다. 실제로 기능을 실행해보고 결과를 확인하는 과정이 필요합니다.


앞으로도 제가 필요한 기능을 직접 만들어보는 시도는 계속할 생각입니다.
그 과정에서 새롭게 알게 된 내용이나 예상과 달랐던 경험들도 이곳에서 공유해보겠습니다.

여러분은 요즘 AI를 어디까지 활용하고 계신가요?
기획서나 요구사항을 정리하는 데 사용하고 계신가요? 아니면 저처럼 직접 기능을 만들어보고 계신가요? 실제로 활용하면서 겪었던 경험이 있다면 함께 이야기 나눠보고 싶습니다.

가볍게 써볼 새로운 AI 추천

메타가 만든 AI 앱, Meta AI를 소개합니다.
텍스트나 음성으로 질문하고, 문서 요약이나 아이디어 정리에 활용할 수 있어요.

평소 쓰는 AI의 답변이 아쉽거나 다른 관점이 필요할 때, 같은 질문을 Meta AI에도 해보세요. 답변을 나란히 비교하면서 빠뜨린 조건이나 새로운 아이디어가 있는지 살펴보는 용도로 추천합니다.

iPhone 앱 받기   Android 앱 받기   웹에서 써보기


📮 다음 호 예고

[36호] AI를 써야 한다는 집착

“AI를 잘 쓰기 위해서는 언제 쓰지 않을지 알아야 한다.”라는 말이 있죠. (그런 말 없습니다 🙃)
모든 업무에 AI를 적용해야 한다는 강박에서 벗어나 봅시다. AI를 쓰는 것 자체가 목표가 되지 않도록, 언제 AI를 쓰고 언제 쓰지 않을지 함께 생각해 봐요.

 

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

 

 

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

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

✉️

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

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

댓글

의견을 남겨주세요

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

다른 뉴스레터

© 2026 Product Makers Note

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

뉴스레터 문의note4makers@gmail.com

메일리 로고

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

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

메일리 사업자 정보

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

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