API란 무엇인가 – 비개발자도 이해하는 쉬운 설명

API란 무엇인가 – 비개발자도 이해하는 쉬운 설명

개발팀과 회의하다 보면 “API로 연동하면 됩니다”, “API 명세서 주세요” 같은 말을 자주 듣습니다. 고개는 끄덕이지만 속으로는 “API가 정확히 뭐지?” 하는 생각이 들 수 있습니다.

기획서를 쓸 때도 “외부 서비스와 API 연동 필요”라고 적어야 하는데, 정확히 뭘 요청하는 건지 애매할 때가 있습니다. 개발자에게 물어보면 “그냥 API 호출하면 돼요”라는 답이 돌아오고, 더 헷갈리기도 합니다.

이 글에서는 코드 한 줄 없이 API가 무엇인지 설명합니다. 읽고 나면 개발팀과의 대화에서 “API”라는 단어가 나와도 당황하지 않게 됩니다.

API를 한 문장으로 정의하면

API는 프로그램끼리 대화하는 방법입니다.

사람은 말이나 글로 소통합니다. 한국어, 영어처럼 서로 약속된 언어를 사용해야 대화가 됩니다. 프로그램도 마찬가지입니다. 프로그램끼리 데이터를 주고받으려면 정해진 규칙이 필요합니다. 그 규칙이 바로 API입니다.

API는 “이렇게 요청하면, 이렇게 응답해줄게”라는 약속입니다. 예를 들어 “서울 날씨 알려줘”라고 요청하면 “맑음, 15도”라고 응답하는 식입니다. 요청 형식과 응답 형식이 미리 정해져 있어서, 그 규칙만 따르면 누구나 사용할 수 있습니다.

API는 Application Programming Interface의 약자입니다. 직역하면 “응용 프로그램 프로그래밍 인터페이스”인데, 이 이름은 외울 필요 없습니다. 중요한 건 “프로그램 사이의 대화 규칙”이라는 개념입니다.

레스토랑으로 이해하는 API

API를 설명할 때 가장 많이 쓰는 비유가 레스토랑입니다. 한 번 제대로 이해하면 API 개념이 확실히 잡힙니다.

레스토랑에서 식사하는 상황을 떠올려보세요. 손님, 웨이터, 주방 세 가지 역할이 있습니다.

[손님] → [웨이터] → [주방]
  ↑         ↓         ↓
  └── 음식 받음 ←──────┘
역할 설명 API에서는
손님 음식을 주문하는 사람 요청하는 프로그램 (클라이언트)
웨이터 주문 받아서 주방에 전달 API
주방 음식을 만드는 곳 요청 처리하는 프로그램 (서버)

손님은 주방에 직접 들어가지 않습니다. 주방에서 어떤 재료를 쓰는지, 어떤 도구로 요리하는지 알 필요도 없습니다. 그냥 메뉴판을 보고 “파스타 주세요”라고 웨이터에게 말하면 됩니다. 웨이터는 주문을 받아 주방에 전달하고, 음식이 나오면 손님에게 가져다줍니다.

API도 똑같이 작동합니다. 프로그램 A(손님)가 프로그램 B(주방)의 내부 구조를 몰라도 됩니다. API(웨이터)라는 창구를 통해 정해진 형식으로 요청하면, 정해진 형식으로 응답이 돌아옵니다.

여기서 중요한 포인트가 있습니다. 웨이터가 받는 주문에는 규칙이 있습니다. 메뉴판에 없는 음식은 주문할 수 없습니다. “아무거나 맛있는 거 주세요”라고 하면 웨이터가 처리할 수 없습니다. API도 마찬가지입니다. 미리 정해진 요청만 처리할 수 있고, 규칙에 맞지 않는 요청은 거부됩니다.

실생활 속 API 예시

우리는 이미 API를 매일 사용하고 있습니다. 눈에 보이지 않을 뿐입니다. 스마트폰에서 앱을 쓸 때마다 수십 개의 API가 뒤에서 작동합니다. 구체적인 예시를 살펴보겠습니다.

날씨 앱

아침에 날씨 앱을 열면 현재 기온, 미세먼지 농도, 일주일 예보가 나옵니다. 이 데이터는 어디서 올까요? 스마트폰에 온도계가 달린 건 아닙니다.

[날씨 앱] --"서울 날씨 알려줘"--> [기상청 API]
[날씨 앱] <--"맑음, 15도"-------- [기상청 API]

날씨 앱은 기상청(또는 기상 데이터 회사)의 API에 요청을 보냅니다. “서울시 강남구의 현재 날씨 데이터를 주세요”라고 요청하면, API가 “현재 기온 15도, 습도 45%, 맑음”이라고 응답합니다. 앱은 이 데이터를 예쁘게 화면에 보여주는 역할만 합니다.

전 세계 수천 개의 날씨 앱이 있지만, 데이터 출처는 몇 개 안 됩니다. 모두 같은 API를 사용하기 때문입니다. 앱마다 화면 디자인만 다를 뿐, 뒤에서 가져오는 데이터는 동일합니다.

소셜 로그인

요즘 앱이나 웹사이트에 가입할 때 “카카오로 로그인”, “구글로 로그인”, “애플로 로그인” 버튼을 자주 봅니다. 아이디와 비밀번호를 새로 만들 필요 없이 기존 계정으로 바로 로그인할 수 있어서 편리합니다. 이것도 API 덕분입니다.

[쇼핑몰 앱] --"이 사람 누구야?"--> [카카오 API]
[쇼핑몰 앱] <--"홍길동, hong@email.com"-- [카카오 API]

“카카오로 로그인” 버튼을 누르면 이런 일이 일어납니다. 쇼핑몰 앱이 카카오 API에게 “이 사용자가 카카오 계정으로 로그인하려고 합니다. 누구인지 알려주세요”라고 요청합니다. 사용자가 카카오에서 로그인을 승인하면, 카카오 API가 “이 사람은 홍길동이고, 이메일은 hong@email.com입니다”라고 응답합니다.

중요한 점은 비밀번호입니다. 비밀번호는 카카오만 알고 있습니다. 쇼핑몰에는 절대 전달되지 않습니다. 쇼핑몰은 “이 사람이 카카오에서 본인 확인을 했다”는 사실만 알면 됩니다. 덕분에 쇼핑몰이 해킹당해도 카카오 비밀번호는 안전합니다.

결제 시스템

온라인 쇼핑몰에서 물건을 사고 카드 결제를 할 때도 API가 작동합니다. 쇼핑몰이 직접 카드 결제를 처리하면 어떻게 될까요? 모든 쇼핑몰이 카드사와 직접 계약하고, 결제 시스템을 개발하고, 보안 인증을 받아야 합니다. 너무 복잡하고 비용도 많이 듭니다.

[쇼핑몰] --"5만원 결제해줘"--> [PG사 API]
[쇼핑몰] <--"결제 완료, 승인번호 12345"-- [PG사 API]

그래서 결제 전문 회사(PG사, Payment Gateway)가 있습니다. 토스페이먼츠, KG이니시스, NHN KCP 같은 회사입니다. 쇼핑몰은 PG사의 API를 사용합니다. “이 고객의 5만원 결제를 처리해주세요”라고 요청하면, PG사가 카드사와 통신해서 결제를 처리하고 “결제 완료”라고 응답합니다.

쇼핑몰은 카드번호를 직접 저장하거나 처리하지 않습니다. 민감한 결제 정보는 PG사가 관리합니다. 쇼핑몰 입장에서는 결제 시스템을 직접 만들 필요 없이 API 연동만 하면 되니까 편리하고, 고객 입장에서는 보안이 더 안전합니다.

지도 서비스

배달 앱에서 라이더 위치가 실시간으로 움직이는 걸 본 적 있을 겁니다. 배달 앱이 지도를 직접 만들었을까요? 아닙니다. 카카오맵이나 네이버맵, 구글맵 API를 사용합니다.

배달 앱은 “이 위치를 지도에 표시해줘”라고 API에 요청합니다. 지도 API가 해당 위치의 지도 이미지와 정보를 응답합니다. 라이더 위치가 바뀔 때마다 새로운 요청을 보내서 지도를 업데이트합니다.

API가 왜 필요한가요?

API가 없으면 어떻게 될까요? 모든 기능을 직접 만들어야 합니다. 현실적으로 불가능합니다.

1. 직접 만들 필요가 없다

지도 기능이 필요하면 구글맵 API를 쓰면 됩니다. 직접 지도를 만들려면 위성 사진 수집, 도로 정보 입력, 교통 정보 연동, 검색 기능 개발 등 수년이 걸리는 작업이 필요합니다. API를 쓰면 며칠 만에 지도 기능을 붙일 수 있습니다.

번역 기능이 필요하면 파파고 API나 구글 번역 API를 씁니다. AI 번역 모델을 직접 만들 필요가 없습니다. 문자 발송 기능이 필요하면 문자 발송 API를 씁니다. 통신사와 직접 계약할 필요가 없습니다.

이미 잘 만들어진 기능을 API로 가져다 쓰면 시간과 비용을 크게 아낄 수 있습니다. 개발팀은 핵심 기능 개발에 집중할 수 있습니다.

2. 보안이 좋아진다

앞서 결제 예시에서 봤듯이, 민감한 정보를 직접 다루지 않아도 됩니다. 카드 결제 API를 쓰면 쇼핑몰은 카드번호를 저장하지 않습니다. 카드 정보는 결제 전문 회사가 보안 시스템을 갖춰서 관리합니다.

소셜 로그인 API를 쓰면 사용자 비밀번호를 저장하지 않습니다. 본인 확인은 카카오, 구글 같은 대형 서비스가 책임집니다. 쇼핑몰이 해킹당해도 비밀번호 유출 걱정이 없습니다.

보안은 전문성이 필요한 분야입니다. 결제, 인증 같은 민감한 기능은 전문 업체의 API를 쓰는 게 안전합니다.

3. 서로 다른 시스템을 연결한다

쇼핑몰을 운영한다고 생각해보세요. 주문이 들어오면 여러 시스템이 연동되어야 합니다.

  • 결제 시스템: 카드 결제 처리
  • 재고 시스템: 재고 차감
  • 물류 시스템: 택배사에 배송 요청
  • 알림 시스템: 고객에게 문자/카카오톡 발송
  • 정산 시스템: 판매자에게 정산

이 시스템들은 각각 다른 회사에서 만든 다른 프로그램입니다. 쇼핑몰(웹), 택배 회사(물류 시스템), 은행(결제 시스템), 문자 발송 업체(통신 시스템)가 모두 다릅니다. API가 없으면 이들을 연결할 방법이 없습니다.

API는 서로 다른 시스템 사이의 다리 역할을 합니다. 각 시스템이 제공하는 API를 호출하면 데이터를 주고받을 수 있습니다. 주문 정보를 택배사 API로 보내면 송장 번호가 돌아오고, 그 송장 번호를 고객에게 문자 API로 발송합니다.

기획자가 알면 좋은 API 용어

개발팀과 소통할 때 자주 나오는 용어입니다. 전부 외울 필요는 없지만, 들었을 때 대략 무슨 뜻인지 알면 회의가 수월해집니다.

용어 쉬운 설명 예시
API 호출 API에 요청을 보내는 것 “결제 API 호출해서 결제 처리”
API 명세서 “이렇게 요청하면 이렇게 응답함” 설명서 외부 업체가 API 연동할 때 제공
엔드포인트 API의 주소 api.example.com/weather
요청(Request) “이거 해줘”라고 보내는 것 서울 날씨 요청
응답(Response) “여기 있어”라고 돌려받는 것 맑음, 15도
인증(Auth) API 사용 권한 확인 API 키, 토큰
API 키 API 사용 허가증 (비밀번호 같은 것) 발급받아서 요청 시 함께 전송

API 명세서는 특히 중요합니다. 외부 서비스와 연동할 때 “API 명세서 보내주세요”라고 요청합니다. 명세서에는 어떤 주소로 요청해야 하는지, 어떤 데이터를 보내야 하는지, 어떤 응답이 오는지 다 적혀 있습니다. 개발자는 이 명세서를 보고 연동 작업을 합니다.

기획서에 “외부 서비스 A와 API 연동 필요”라고 적으면, 개발팀은 A 서비스에서 API 명세서를 받아서 연동 작업을 합니다. 기획자가 명세서 내용을 다 이해할 필요는 없지만, “API 명세서가 있어야 연동이 가능하다”는 점은 알아두면 좋습니다.

흔한 오해 바로잡기

“API는 버튼인가요?”

아닙니다. 버튼은 화면에 보이는 UI(사용자 인터페이스)입니다. API는 눈에 보이지 않습니다.

“결제하기” 버튼을 누르면 내부적으로 결제 API가 호출됩니다. 하지만 버튼 자체가 API는 아닙니다. 버튼은 사용자가 클릭하는 화면 요소이고, API는 버튼 클릭 후 뒤에서 실행되는 프로그램 간 통신입니다.

비유하면 버튼은 자동차 시동 버튼이고, API는 시동 버튼을 눌렀을 때 엔진이 작동하는 원리입니다. 사용자는 버튼만 보지만, 뒤에서는 복잡한 작동이 일어납니다.

“API는 개발자만 쓰나요?”

코드를 작성해서 API를 호출하는 건 개발자입니다. 하지만 API가 어떤 기능을 해야 하는지, 어떤 데이터를 주고받아야 하는지 정하는 건 기획 단계에서 논의됩니다.

예를 들어 “회원가입 시 카카오 로그인도 지원하자”라고 기획하면, 개발팀은 카카오 로그인 API를 연동합니다. “주문 완료 시 카카오톡 알림을 보내자”라고 기획하면, 개발팀은 카카오톡 알림 API를 연동합니다. 기획자가 API 개념을 알면 “이런 기능은 API로 가능할까?”라는 판단을 할 수 있고, 개발팀과 소통이 수월해집니다.

“API가 있으면 뭐든 연동 가능한가요?”

두 가지 조건이 필요합니다.

첫째, 상대방이 API를 제공해야 합니다. 아무리 연동하고 싶어도 상대 서비스가 API를 공개하지 않으면 불가능합니다. 예를 들어 인스타그램은 게시물 자동 업로드 API를 제공하지 않습니다. 아무리 개발해도 인스타그램에 자동 포스팅하는 기능은 만들 수 없습니다.

둘째, 사용 권한이 필요합니다. 대부분의 API는 API 키를 발급받아야 사용할 수 있습니다. 누가 API를 쓰는지 추적하고, 무분별한 사용을 막기 위해서입니다. API 키 없이 요청하면 거부됩니다.

그리고 유료 API도 많습니다. 무료로 제공되는 API도 있지만, 사용량에 따라 비용이 발생하는 API도 있습니다. 기획 시 API 비용도 고려해야 합니다.

정리

개념 핵심
API란 프로그램끼리 대화하는 방법, 정해진 규칙으로 요청-응답
비유 레스토랑의 웨이터 역할 (손님-웨이터-주방)
실생활 예시 날씨 앱, 소셜 로그인, 카드 결제, 지도 서비스
왜 필요한가 직접 안 만들어도 됨, 보안 위임, 다른 시스템 연결
기획자에게 API 명세서, 엔드포인트, 요청/응답, API 키 이해
주의사항 상대방이 API 제공해야 함, 사용 권한 필요, 유료일 수 있음

API는 눈에 보이지 않지만, 우리가 쓰는 거의 모든 앱과 서비스 뒤에서 작동하고 있습니다. 스마트폰으로 날씨를 확인하고, 카카오로 로그인하고, 온라인 결제를 할 때마다 API가 일하고 있습니다. 개념만 이해하면 개발팀과의 대화가 훨씬 수월해집니다.

위로 스크롤