1인 개발자가 CODEF·쿠콘 마이데이터 API 를 알아본 회고
자영업자나 프리랜서를 위한 자동화 도구를 한번 만들어볼 수 있을까 싶어 정산 시스템 비슷한 것을 그려보던 중에, 한국 마이데이터 중개 API 인 CODEF (운영사 쿠콘) 까지 살펴보게 되었습니다. 결정을 내리거나 추천하려는 글은 아니고, 1인 개발자가 "어디까지 가능하고 어디서 막히는지" 알아본 사전 조사 회고에 가깝습니다.
출발점 — 매출 자동화가 안 풀리는 갭
정산 시스템을 머릿속으로 그려보다 보니 매입 쪽과 매출 쪽의 비대칭이 자꾸 걸렸습니다. 매입(지출) 은 영수증 OCR 로 사진을 찍으면 vendor·날짜·금액이 빠지는 흐름이 어느 정도 그려집니다. 그런데 매출 은 결국 사장님이 카드·현금·배달·온라인 매출을 매일 직접 입력하는 그림으로 수렴하는 것 같습니다.
그래서 "매출 자동화의 첫 카드로 현금영수증이나 세금계산서 발행 내역을 자동으로 끌어올 수 있을까?" 가 출발 질문이 되었습니다. 거기서 가지가 뻗어 부가세 신고 자동화, 무통장 입금 확인 자동화까지 닿았고, 그러다 보니 자연스럽게 한국 마이데이터 / 스크래핑 API 생태계를 들여다보게 되었습니다.
헷갈리는 분기점 — "마이데이터" 의 두 얼굴
찾아보면서 가장 먼저 정리해야 했던 것은 한국에서 "마이데이터" 라는 단어가 두 가지로 쓰인다는 점이었습니다. 둘을 섞어 쓰면 이후 모든 검토가 어긋나는 것 같아 짧게라도 분리해두는 편이 좋겠다는 생각이 들었습니다.
| 구분 | 법적 마이데이터 | 속칭 마이데이터 |
|---|---|---|
| 근거 | 2020년 신용정보법 개정 | 스크래핑/대행 인증 기반 |
| 인가 | 금융위 인가 필수 (60+ 사) | 별도 인가 없음 |
| 통로 | KFTC 표준 API | 사용자 인증서/간편인증 대리 로그인 |
| 대표 | 네이버페이·뱅크샐러드·토스·카카오페이 | CODEF, NICE D.NA |
흥미로운 것은 쿠콘 이 두 영역을 동시에 운영한다는 점입니다. 2021년 1차 마이데이터 사업자 인가를 받았으면서, 개발자 친화 브랜드로 스크래핑/API 통합 플랫폼인 CODEF 도 운영합니다. "쿠콘이 마이데이터 사업자 맞나?" 하고 헷갈리던 부분이 이 지점에서 풀렸습니다.
CODEF 가 다루는 영역
CODEF 의 상품 카탈로그를 훑어보면 영역이 꽤 넓습니다. 홈택스(전자세금계산서·현금영수증·사업용 카드·사업자 등록 조회), 은행(잔액·입출금 거래내역·이체 결과), 카드(매출·사용내역·청구서), 증권·보험·통신·정부24·보건복지부까지 한 API 안에서 다룹니다.
다만 1인 사업자나 SaaS 관점에서 보면 진짜 sweet spot 은 사업자 영역 인 것 같습니다. 홈택스·사업자 금융·정부24 쪽이 직접 만들었을 때 가치가 크고, 개인 금융 데이터는 후술할 신용정보법 흐름상 정식 마이데이터 사업자 쪽이 점점 더 깔끔해질 것 같다는 인상이었습니다. 다만 이 부분은 직접 양쪽을 다 써본 결과가 아니라 자료 기반 추정입니다.
가격이 비공개라는 진입장벽
솔직히 말하면 가격 정보가 가장 답답한 부분이었습니다. codef.io 공식 가격 페이지가 로그인 후에만 노출 되어 있어, 사전 조사 단계에서는 정확한 단가를 확인할 방법이 없었습니다.
여기저기 후기와 리뷰를 모아보면 대략 이런 그림이 그려집니다. 호출당 ₩30~200 사이에서 상품별로 차등이 있고, 홈택스가 비싸고 사업자 단순 조회는 저렴한 편이라고 합니다. Demo 환경은 월 200건 정도 무료, 최소 충전은 ₩10,000부터, 월 기본료는 등급제로 낮은 등급은 무료라는 언급이 보였습니다. 다만 이 숫자들은 전부 후기 기반 추정이고, 정확한 단가는 본인이 가입해서 대시보드에서 확인해야 한다 는 한계가 분명합니다.
이 정보 비대칭이 1인 개발자 입장에서는 꽤 큰 진입장벽처럼 느껴졌습니다. 5분 polling 으로 입금 알림을 만들었을 때 한 달에 얼마가 나오는지 같은 단가 산수가 사전 단계에서는 어림짐작 이상이 되기 어려운 것 같습니다.
그려본 시나리오 두 가지
시나리오 A — 부가세 신고용 정리 자료
가장 그림이 잘 그려진 것은 부가세 신고용 정리 자료입니다. 홈택스 4종(매출/매입 × 세금계산서/현금영수증) 을 사용자 인증 1회로 모두 조회해두고, 분기 끝에 합계표와 거래처별 명세, PDF 까지 자동으로 떨어뜨리는 그림입니다.
매장이 여러 개거나, 종합소득세 정리를 매년 세무사한테 맡기는 사장님이라면 "세무사한테 그대로 넘기는 정리 PDF" 가 자동으로 나오는 것만으로도 가치가 있을 것 같다는 생각이 들었습니다. 다만 여기서 한 가지 주의할 점은, 결과물에 "신고 대행" 같은 표현은 절대 붙이면 안 된다는 점입니다. 세무사법 가드 때문에 어디까지나 "신고용 정리 자료" 까지가 안전 구간인 것 같습니다.
시나리오 B — 무통장 입금 알림
두 번째는 무통장 입금 확인입니다. 은행 거래내역 조회 API 를 cron 으로 주기적으로 호출하면서 직전 스냅샷과 diff 를 떠서 새 입금이 들어오면 알림을 보내는 흐름입니다.
타겟이 명확하다는 점이 마음에 들었습니다. PG 가상계좌 발급은 정산 한도나 심사가 부담이고, 펌뱅킹은 매출 규모가 안 되는 1인 강사·외주 개발자·소규모 자영업자·B2B 인보이스 발행자 같은 분들 말입니다. 그런데 옵션을 나란히 놓고 보면 각자 트레이드오프가 다릅니다.
| 옵션 | 지연 | 비용/장벽 | 타겟 |
|---|---|---|---|
| PG 가상계좌 | 실시간 (webhook) | 심사·정산 한도·수수료 | 일정 규모 이상의 온라인 매출 |
| CODEF polling | 준실시간 (5분~) | 호출당 비용 누적 | 소규모 1인 사업자 |
| 토스 비즈 푸시 | 실시간에 가까움 | 토스 비즈 계정 필요 | 토스 비즈 사용 사장님 |
현실적 트레이드오프
시나리오를 그려보고 나니 곧바로 걸리는 지점들이 있었습니다. 정리해두지 않으면 나중에 같은 고민을 처음부터 다시 할 것 같아 옮겨둡니다.
먼저 polling 지연 입니다. CODEF 는 webhook 이 아니라 polling 모델이라 5분~1시간 간격이 한계입니다. "실시간" 이 아니라 "준실시간" 으로 약속해야 하는 것 같습니다.
두 번째는 호출 비용 누적 입니다. 5분 polling 을 24시간 돌린다고 가정하면 일 288회, 호출당 ₩100 추정으로 계산해도 일 ₩28,800 — 월 ₩86만이 넘는 산수가 나옵니다. 한 사용자 기준입니다. 영업시간 한정 + "지금 확인" 수동 버튼 + 1시간 cron 같은 mix 가 현실적인 절충점일 것 같습니다.
5분 polling × 24h = 288회/일
288 × ₩100 = ₩28,800/일
× 30일 ≈ ₩864,000/월 (1 사용자)
세 번째는 Connected ID 만료 입니다. 사용자 인증 자격이 보통 1년, 일부 상품은 90일 정도라고 합니다. 만료되면 알림이 조용히 멈출 위험이 있어 만료 임박 알림 UX 가 필수일 것 같습니다.
네 번째는 신용정보법 2021년 개정 의 큰 그림입니다. 개인 금융 데이터의 스크래핑은 단계적으로 금지되고 정식 마이데이터 API 로 전환되는 추세라, 스크래핑 영역 자체가 시간이 갈수록 좁아진다는 점은 염두에 두어야 할 것 같습니다.
마지막으로 앞서 짧게 적었지만 세무사법 입니다. 부가세 정리 자료를 만들더라도 "신고 대행" 이라는 단어는 절대 노출하지 않고 "신고용 정리 자료" 까지에서 멈춰야 한다는 점은 시나리오 A 의 가장 중요한 가드레일인 것 같습니다.
결정은 보류, 여기까지 알아봤습니다
여기까지 정리하고 나니 명확한 결론을 내리기는 어려웠습니다. 부가세 신고용 정리 자료 쪽은 PoC plan 을 한 건 따로 적어두었고, 무통장 입금 확인은 별도 카드로 분리해서 더 들여다보기로 했습니다. 단가가 진짜 의사결정에 영향을 주는 변수인데, 그 단가가 가입 전에는 추정밖에 안 되니 본 글은 어디까지나 그 직전까지의 사전 조사 회고에 머무를 수밖에 없습니다.
"CODEF 가 정답이다" 같은 결론은 아직 내놓지 못하겠습니다. 다만 한국에서 자영업자·프리랜서 자동화 도구를 만들고 싶은 1인 개발자라면 한 번쯤 같은 길을 걷게 될 것 같아, 제가 막힌 지점들이라도 raw material 로 남겨두는 것이 의미가 있을 것 같다는 생각이 들었습니다. 다음에 직접 가입해서 단가와 응답을 본 다음에 후속 글을 한 편 더 써볼 생각입니다.
관련 글
오랜만에 글의 시작을 AI의 도움없이 진행해봅니다.
AI에게 글쓰기를 맡긴 3개월, 편했지만 독자의 문제를 해결해주는 글은 아니었다. 블로그의 정체성을 돌아보고, 개발자로서 앞으로의 방향을 정리합니다.
개발도 결국은 상품을 만드는 일 — 기술 스택 선택이 납품과 유지보수를 결정한다
사이드 프로젝트의 모던 스택을 클라이언트에게 납품하려 하니, 기술 선택이 곧 유지보수 비용과 클라이언트 경험을 좌우한다는 걸 깨달았습니다. 개발자가 시장과 목적에 맞는 기술 스택을 선택해야 하는 이유를 정리했습니다.
무엇을 배워야 하는가 - IT 외주 시장 적응기
SaaS를 뒤로하고 다시 이직·외주 시장의 문을 두드린 2주차의 기록. AI 시대, 전문성의 깊이(이직)와 넓이(외주) 사이에서 1인 개발자가 무엇을 먼저 갖춰야 할지에 대한 고민을 정리했습니다.