Product Engineer(PE)로 일하기: 무이자 할부 정보 업로드 자동화

마이리얼트립은 기획·디자인·개발을 구분하던 기존 직무 체계를 Product Engineer(PE)로 통합했습니다. 제품을 중심으로 문제를 정의하고, 설계하고, 구현하며, 결과까지 책임지는 역할을 하나의 기준으로 묶은 것입니다.

그 사례로 기획 업무를 담당하던 결제정산개발팀 김진균님은 PE로서 매월 반복되던 무이자 할부 업로드 작업을 직접 자동화했습니다.

여행 상품을 볼 때 “A카드 2개월 무이자”, “B카드 3개월 무이자” 같은 문구를 본 적이 있을 겁니다. 이 무이자 할부 정보를 사이트에 올리려면, 매월 담당자가 관리 페이지에 들어가서 새로 공지된 무이자 할부 이미지를 보고, 그걸 엑셀에 옮겨 적은 뒤, 다시 우리 쪽 관리 페이지에 직접 올려 넣어야 했습니다.

엑셀 수식으로 업무를 조금 덜었지만, 어떤 카드가 몇 개월까지 무이자인지 판단해서 넣고, 그걸 다시 올리는 일은 여전히 사람이 매번 해야 했습니다. 실수나 누락이 생기기 쉬웠고, 맥에서는 엑셀이 깨지거나 서식이 틀어지는 일도 있었습니다.

김진균님은 이 업무를 자동화하고 싶어 오래 고민하다가, 직접 나서 “매월 마지막 영업일 오전 10시에 자동으로 돌아가는 흐름”을 만들었습니다. 정책이 올라오는 페이지에서 이미지를 가져오고, AI가 이미지 속 글자를 읽어 데이터로 바꾼 뒤, 한 번 검증하고 저장하고, 담당자에게만 “확인해 주세요” 알림을 보내는 식입니다. 이제 손으로 하던 작업이, 한 번 설정한 파이프라인 하나로 이어져 처리됩니다. 이 글에서는 자동화를 어떻게 실현시켰는지, 그 과정에서 무엇이 쉬웠고 무엇이 어려웠는지 나눕니다.

반복되던 수동 작업이 사라지다

이 무이자 할부 정보는 결제 대행사가 이미지로만 알려 주기 때문에, 담당자는 매월 수동 작업을 반복해야 했습니다. 이 작업에는 세 가지 문제가 있었습니다. 엑셀이 깨지거나 서식이 바뀌는 일, 사람이 하다 보니 나는 실수와 누락, 그리고 담당자 부재 시 업로드를 빠뜨린 경험입니다.

“휴먼 에러와 누락을 없애고, 반복되는 운영을 줄이기 위해 자동화를 구현했습니다.”

“예전에 사람이 하던 전 과정”을 한 흐름으로 묶은 이 자동화는 매월 마지막 영업일 오전 10시에 자동 실행되고, 실패하면 오후 2시에 한 번 더 시도합니다.

정책 페이지에서 이미지를 가져오고 → AI가 이미지 속 글자를 읽어 카드사별 할부 정보로 바꾸고 → 한 번 검증한 뒤 → 데이터 저장소(DB)에 넣는, 처음부터 끝까지 이어지는 여덟 개 단계로 나뉩니다.

• 이미지 가져오기 — 예전에는 담당자가 페이지에 접속해 이미지를 봤는데, 이제는 그 페이지에서 이미지를 자동으로 받아와 회사 파일 저장 공간에 넣도록 했습니다. 중간에 실패하면 다시 시도하는 장치도 넣었습니다.
• 이미지 속 글자 읽기(AI OCR) — 정책이 이미지로만 나오기 때문에, 이미지를 읽어서 “어떤 카드, 몇 개월 무이자” 같은 데이터로 바꾸는 게 핵심이었습니다. 외부 AI 서비스(업스테이지)를 써서 이미지를 읽고, 카드사별 할부 정보를 뽑았습니다. 카드사 이름은 우리 서비스에서 쓰는 번호로 자동 매핑되도록 했습니다. 예를 들어 “A카드”가 들어오면 내부 코드 11번으로 바뀌는 식입니다.
• 검증, 승인 절차 — 가져온 이미지와 AI가 뽑은 데이터가 1차로 자동 검증을 통과하면 저장되고, 그다음 담당자가 최종 확인·승인해야 실제 서비스에 반영됩니다. 아직 100% 신뢰를 검증하지 못했기 때문에, 반려·승인을 두는 안전장치를 넣었고, 나중에 안정이 확인되면 승인 없이 자동 반영할 계획입니다.
• 자동 실행, 알림 — 매월 마지막 영업일 10시, 실패 시 14시에 자동으로 돌아가고, 결과는 슬랙으로 옵니다. 성공하면 “승인 요청” 알림, 실패하면 “경고” 알림이 갑니다.
• 관리 화면, 보안 — 자동화했지만 사람이 최종 확인하고 승인하는 구조는 유지했습니다. 관리 페이지에서 AI가 읽어 낸 결과를 보고, 잘못된 부분만 그 자리에서 수정한 뒤 승인할 수 있게 했습니다. AI를 부르는 데 쓰는 키는 암호화해서 관리합니다. 이렇게 한 흐름으로 이어지면서, 반복되던 수동 작업이 자동으로 처리되도록 바뀌었습니다.

말로 요청하고, AI가 코드로 답하다

김진균님은 기획 업무 경험을 살려 직접 구현까지 맡았습니다.

순서는 이랬습니다. 먼저 코드 분석용 AI(Devin)에게 기존 무이자 할부 코드를 분석하게 했고, 그 결과를 구현용 AI(Cursor)가 쓰는 폴더에 넣었습니다. 그다음 “이렇게 동작하게 해 달라”는 요구를 평범한 말로 적어서 넘기면서, 사람이 읽기 쉬운 계획 문서와 AI가 읽기 쉬운 정책 문서를 만들었습니다. 중간에 AI가 기존 테이블을 안 쓰고 새로 만들려 하거나, 기록 방식을 다르게 가져가려 할 때는 말로 다시 맞추며 여러 번 수정했습니다. 이미지를 데이터로 바꾸는 부분은 동료가 소개해 준 업스테이지 서비스를 쓰기로 하고, 문서를 AI에게 넘긴 뒤 “우리 정책에 맞게 읽어 달라”고 설계했습니다. 요구가 추가되거나 테스트가 실패할 때마다 원인을 찾아 고치는 과정을 반복한 끝에 완성했습니다.

예전에는 기획자가 개발자에게 설명하고, 여러 사람이 읽기 좋게 문서를 만든 뒤에야 진행됐던 것을, 이번에는 AI와 함께 바로 구현할 수 있었습니다.

“도메인 지식이나 요구사항만 명확히 정리하면, 비개발자도 설계를 이끌고 AI가 기술 구현을 해 주는 식으로 함께 일할 수 있다고 느꼈습니다.”

절반은, 코드 밖에 있었다

직접 해 보니 생각보다 쉬운 부분이 많았습니다. 기존 코드 분석은 AI에게 맡기니 잘 나왔고, 결과가 본인 지식과 맞아서 믿고 다음 요청을 할 수 있었습니다. “이렇게 해 달라”고 말만 해도 코드가 나와서 구현 자체는 부담이 적었습니다. 문서를 “사람 눈에 예쁘게” 만들 필요가 없어져서 오히려 편했고, 요구를 넣으면 곧바로 코드와 화면 결과를 볼 수 있어 속도도 빨랐습니다. 정책이 바뀌어도 개발자에게 부담을 주지 않고 말로만 요청하면 돼서, 심리적 부담이 적었습니다. 테스트에서 실패해도 원인을 찾아 고치는 게 비교적 빠르게 이뤄졌고, “아이디어를 바로 구현할 수 있었다”는 점이 가장 컸습니다.

반대로 어려웠던 건 “코드”보다 “그 코드가 돌아가는 환경”이었습니다. 크게 여섯 가지입니다. 1. 어떤 환경에서 어떻게 배포할지, 2. 설정값은 어디에 두는지, 3. 어떤 권한이 필요한지, 4. 자동 실행은 어떤 도구로 할지, 5. 보안은 어떻게 할지, 6. 문제가 생겼을 때 로그는 어디서 보는지.

본인 컴퓨터에서는 잘 되는데, 서버에 올리면 실패하는 경우가 많았습니다. AI는 코드가 잘못됐다고만 생각하고 코드만 고쳤는데, 나중에 보니 서버의 설정값이나 권한 차이가 원인이었습니다. 테스트용 서버를 제가 쓰는 공간이 따로 없어서, 다른 분이 배포할 때 제가 만든 코드가 사라지는 경험도 했습니다. 팀 동료가 “여기서 같이 테스트하자”는 브랜치를 만들어 줘서 해결했지만, 혼자였으면 더 헤맸을 것 같다고 합니다.

권한도 오래 걸렸습니다. AWS 권한은 받았는데 AI는 권한이 없다고 하고, DB 운영 권한은 있는데 데브(dev) 권한은 따로 요청해야 한다는 것도 나중에 알았습니다. 터미널에서 주기적으로 로그인해야 AWS와 통신된다는 것도 처음엔 알려 주는 사람이 없었습니다. AI도 이 부분은 잘 짚어 주지 못해서, 결국 팀원에게 물어보며 하나씩 알아갔습니다.

로그 위치도 막막했습니다. 본인 컴퓨터에서는 터미널에 바로 찍히는데, 서버에서는 API 서버·배치 서버·자동 실행 도구 중 어디서 보는지 감이 안 왔습니다. 로그 화면이나 캡처를 AI에게 보여 주며 “이게 뭔 의미야?” 하고 해석받는 식으로 시간을 썼습니다.

처음에는 “코드 안에서 정해진 시각에 실행되게” 만들었는데, 팀은 자동 실행을 별도 서버(젠킨스)로 관리한다고 나중에 알게 됐고, 그 구조에 맞춰 바꾸는 데도 시간이 들었습니다.

API 키 암호화는 “해야 한다”는 건 알겠는데 방법을 AI도 몰라서, 위키에서 암호화 관련 문서를 찾아 적용해 본 뒤 팀원에게 “이렇게 했는데 맞나요?” 하고 확인받았습니다.

설정값 우선순위도 헷갈렸습니다. “환경 변수”가 설정 파일 내용을 덮어쓴다는 걸 모르고 설정 파일만 고치다가 “왜 반영이 안 되지?” 하고 한동안 헤맸습니다. DB에는 소문자 “active”로 저장돼 있는데 프로그램에서는 대문자 “ACTIVE”를 쓰다 보니, 그 차이 때문에 실행 중 오류가 나고 원인 찾는 데도 시간이 걸렸습니다.

“코드 작성보다, 우리 팀의 개발 구조와 환경을 몸으로 익히는 데 전체 프로젝트의 절반 넘게 쓴 것 같습니다.”

AI가 잘 쓰이려면, “구조와 문서”가 먼저다

이번에 느낀 건, “코드 작성 규칙”이나 “테이블을 어떻게 설계할지” 같은 기준이 개인 경험에 많이 묶여 있다는 점이었습니다. 기준이 없어서 AI가 의도와 다른 방향으로 가는 경우도 있었고, 업무에 대한 이해가 없었으면 시행착오가 더 많았을 것 같습니다. “언제 어떤 환경에서 테스트하고 배포하는지” 같은 공식 문서도 찾기 어려워서, 개발자가 아닌 사람은 부딪혀 가며 배우는 수밖에 없었습니다.

AI는 코드는 빠르게 만들어 주지만, “우리 회사 인프라나 보안 규칙”은 정확히 모르는 것 같았습니다. AI도 모르고 본인도 모르면 막히고, AI를 잘 쓰려면 “우리 구조와 문서를 얼마나 잘 정리해 두었는지”에 더 많이 달려 있다고 느꼈습니다.

그래서 “개발이 아닌 사람이 개발할 때 필요한 것”을 세 가지로 정리했습니다.

1. 개발·보안 표준 — 코드 규칙, 보안 처리 기준, 개발 시 체크할 목록이 문서로 있으면, AI와 함께할 때도 방향이 더 분명해집니다.
2. 환경 가이드 — 로컬·테스트·운영 각각에서 어떻게 돌려 보고, 어떻게 배포하는지 정리돼 있으면, 같은 일을 다시 할 때 시간을 덜 씁니다.
3. 권한과 로그 — “어떤 권한이 필요한지”, “문제 생겼을 때 로그는 어디서 보는지”가 정리돼 있으면, AI와 더 빠르게 진행할 수 있고, 잘못됐을 때도 덜 불안합니다.

“AI가 더 많은 일을 하는 시대일수록, 그 AI가 잘 돌아가도록 우리가 먼저 구조를 갖춰 둬야 한다는 생각이 들었습니다.”

다음 도전을 위한 문서화

기획부터 배포까지 직접 해 보면서, “AI와 함께라면 비개발자도 도메인 지식을 바탕으로 개발에 기여할 수 있다”는 걸 확인했고, 조직의 구조와 가이드가 먼저 갖춰져 있어야 한다는 점도 배웠습니다.

플랫폼솔루션실에서는 올해 목표로, 김진균님처럼 개발이 주 업무가 아닌 분도 개발과 오류·히스토리 파악을 스스로 할 수 있도록 결제·주문·정산 영역 문서화를 진행하고 있고, 상당 부분 끝난 상태입니다.

앞으로 더 많은 분이 AI와 함께 개발에 도전할 수 있는 환경이 되었으면 하고, 그에 필요한 표준과 가이드는 팀과 함께 만들어 나가고 싶다는 말로 발표를 마쳤습니다.

PE로서 문제를 정의하고, 설계하고, 직접 구현까지 마친 이 경험은 결제정산개발팀이 앞으로 어떻게 일할지를 보여주는 하나의 기준점이 되었습니다.