API 제품

API Product

도구

화면 없이 다른 프로그램이 호출해 쓰도록 만들어 파는 제품으로, 돈을 내는 고객이 사용자가 아니라 개발자입니다.

등장 배경

제품을 만든다는 말에는 오랫동안 화면을 만든다는 뜻이 붙어 있었습니다. 사람이 열어 보고 누르는 자리가 있어야 제품이라고 불렀습니다.

그런데 화면이 있으면 오히려 방해가 되는 기능이 있습니다. 문자 한 통을 보내는 일, 카드 결제를 승인하는 일, 주소를 지도 위의 좌표로 바꾸는 일 같은 것입니다. 이런 기능이 필요한 쪽은 이미 자기 제품을 만들고 있고, 그 안에서 이 일이 조용히 처리되기를 바랍니다. 다른 사이트로 넘어가 로그인하고 돌아오라고 하면 쓰던 흐름이 끊깁니다.

페이지덱에서도 같은 일을 겪었습니다. 문서에 전자서명을 붙이면서 서명 회사 사이트로 창을 띄워 보냈더니 서명까지 도달하는 사람이 절반으로 줄었습니다. 다른 회사로 바꿔 보니 그쪽은 화면이 아예 없었습니다. 요청을 보내면 서명 요청이 만들어지고 결과가 돌아오는 통로만 있었고, 사용자가 보는 화면은 페이지덱이 직접 그렸습니다. 이탈은 원래대로 돌아왔습니다.

그래서 화면 없이 통로만 파는 형태가 제품의 한 모양으로 자리 잡았습니다. 기술 쪽에서 API가 프로그램끼리 주고받기로 약속한 창구를 뜻한다면, 그 창구 자체를 상품으로 내놓고 값을 매긴 것이 API 제품입니다.

해결하는 문제

이 형태가 실제로 푸는 것은 넷입니다.

  1. 흐름이 끊기지 않습니다. 고객의 사용자는 고객의 화면 안에서 일을 끝냅니다. 결제든 서명이든 우리 이름이 화면에 나타나지 않는 편이 고객에게는 오히려 좋은 조건입니다.
  2. 고객이 직접 만들지 않아도 되는 것을 사 갑니다. 결제 하나를 스스로 만들려면 카드사 연동과 정산과 규제 대응이 따라오는데, 그 전부를 호출 한 줄로 바꿔 줍니다.
  3. 값을 매기기 쉽습니다. 오간 건수가 그대로 기록에 남으니 사용량 기반 과금, 곧 쓴 만큼 받는 방식과 잘 맞습니다. 요청 1,000건에 2,600원 같은 식이라 고객도 늘어나는 비용을 미리 계산합니다.
  4. 한번 붙으면 잘 떠나지 않습니다. 우리 창구가 고객의 코드 안에 직접 적혀 있어서, 바꾸려면 그쪽이 코드를 고치고 시험하고 다시 배포해야 합니다.

파는 방식도 달라집니다. 광고를 아무리 돌려도 개발자는 먼저 문서를 열어 보고, 예제 코드를 그대로 복사해 십 분 안에 응답을 한 번 받아 보는 데 실패하면 그 자리에서 떠납니다. 그래서 이 형태에서는 문서가 랜딩 페이지 노릇을 합니다. OpenAPI처럼 창구 목록과 주고받는 값을 기계가 읽을 수 있게 적어 두는 표준을 쓰면, 그 파일 하나에서 문서 화면과 연동용 코드가 함께 나옵니다.

대안

같은 기능을 내놓는 껍데기가 이것만은 아닙니다.

  1. 웹앱 — 브라우저에서 사람이 직접 쓰는 화면입니다. 고객이 개발자가 아니면 통로만 열어 두는 쪽은 아무에게도 닿지 않습니다. 개발자 없는 회사도 쓰게 하려면 화면이 하나는 있어야 합니다.
  2. SDK — 상대의 앱 안에 끼워 넣어 쓰도록 포장한 도구 묶음입니다. 휴대폰 앱처럼 기기 안에서 처리해야 하는 일이 섞여 있으면 통로만으로는 부족합니다.
  3. 플랫폼 — 남이 만든 기능을 우리 제품 위에 얹게 여는 형태입니다. 방향이 반대입니다. API 제품은 우리 기능을 남의 제품 안으로 보내고, 플랫폼은 남의 기능을 우리 제품 안으로 들입니다.
  4. 노코드 연동 — 코드를 쓰지 않고 화면에서 조건을 골라 두 서비스를 잇는 방식입니다. 통로는 같은 것을 쓰지만 중간에 누군가 만들어 둔 연결 도구가 끼어듭니다. 개발자가 없는 고객까지 닿습니다.

고르는 기준은 두 가지입니다. 돈을 내는 쪽이 코드를 쓰는 사람인가, 그리고 그 기능이 상대 제품의 어느 자리에 들어가야 하는가입니다. 서버에서 처리해도 되는 일이면 통로로 충분하고, 사용자의 기기 안에서 벌어져야 하는 일이면 끼워 넣는 형태가 필요합니다.

실무 용례

"이건 화면 만들지 말고 API 제품으로 냅시다. 고객이 자기 화면에 넣고 싶어 해요."

사용자를 우리 쪽으로 데려오지 말고 고객의 제품 안에서 끝내자는 제안입니다.

"문서가 곧 랜딩 페이지예요. 예제 코드부터 고칩시다."

개발자가 처음 만나는 화면이 문서라서 거기부터 손보자는 말입니다.

"이번 장애는 우리만 멈춘 게 아니라 위에 붙은 서비스 열두 곳이 같이 멈췄어요."

한 번의 중단이 고객의 고객에게까지 번졌다는 뜻입니다.

페이지덱은 문서 안의 내용을 다른 도구가 가져다 쓰게 하는 창구를 열면서 처음 이 형태를 다뤘습니다. 지현이 가장 오래 고민한 것은 기능이 아니라 약속이었습니다. 화면이라면 버튼 위치를 바꿔도 사용자가 새로 찾으면 그만이지만, 창구는 이름 하나를 바꾸는 순간 붙어 있던 회사들의 코드가 멈춥니다.

그래서 내보내기 전에 세 가지를 먼저 정했습니다. 규격을 바꿀 때 얼마나 미리 알릴지, 옛 방식을 얼마나 오래 같이 받아 줄지, 멈췄을 때 어디에 공지할지입니다. 기능을 만든 기간보다 이 셋을 정하는 데 걸린 시간이 길었습니다.

흔한 오해

창구를 열어 두면 그것이 곧 API 제품이라고 보는 경우가 가장 많습니다. 화면을 만드는 것에 비하면 일이 적어 보여 더 그렇습니다. 하지만 제품이 되려면 창구 말고 붙어야 하는 것이 있습니다. 읽고 따라 할 수 있는 문서, 값을 매긴 요금표, 막혔을 때 물어볼 창구, 그리고 규격을 언제 어떻게 바꿀지에 대한 약속입니다. 이 넷 없이 주소만 공개하면, 붙은 회사들은 어느 날 조용히 바뀐 응답 형식 때문에 멈추고 다시는 돌아오지 않습니다.

고객이 개발자니 마케팅이 필요 없다는 읽기도 흔합니다. 기능과 성능만 좋으면 알아서 골라 줄 것 같기 때문입니다. 실제로는 고르는 자리가 다른 곳으로 옮겨 갔을 뿐입니다. 예제 코드가 복사해서 바로 도는지, 시험용 환경이 가입 없이 열리는지, 오류가 났을 때 무엇이 잘못됐는지 메시지에 적혀 있는지가 그 자리입니다. 이쪽에 사람을 붙이지 않으면 기능이 더 나은데도 문서가 친절한 경쟁 제품에 밀립니다.

자주 헷갈리는 용어

용어어디에서 도는가API 제품과의 차이
SDK고객의 앱 안에 함께 설치돼 돎이쪽은 우리 서버에서 돌고 고객은 부르기만 합니다. 고치면 그 순간 모두에게 적용되는 대신 우리가 멈추면 붙은 곳이 같이 멈춥니다. SDK 는 고객이 새 판을 다시 붙이기 전까지 옛 버전이 그대로 남습니다

같이 보면 좋은 페이지

  • 제품 형태

    여덟 가지 껍데기 중 이것이 어디쯤 놓이는지 봅니다

  • 웹앱

    같은 갈래에서 가장 흔한 형태이고, 대개 둘을 같이 굴립니다

  • API

    이 제품이 팔고 있는 기술 쪽 개념입니다

마지막 업데이트 2026-09-16