[API] 어디까지 가능한 걸까?

지난 포스팅에서 API의 정의와 원리에 대해서 정리했습니다. 혹시 API라는 개념을 처음 접해보셨다면, 해당 포스트를 읽고 오시는걸 권장드립니다 :)

 

[API] API의 정의와 원리

 

오늘은 이전 포스팅에 이어, API의 종류와 적용 범위에 대해 말씀드리겠습니다.

 

API의 종류 : 약속이 있어야 대화가 된다

API가 무엇인지는 이제 감이 오는데, 이러한 API도 여러가지 방식이 있습니다. 쉽게 말하자면, 대화할 때 어떤 언어를 쓸지 정하는 거죠. 예를 들어, 제가 한국어로 말하는데 상대방이 영어만 한다면 당연히 대화가 안되겠죠? API도 마찬가지입니다. 서로 데이터를 주고받을 때, 어떤 형식과 규칙으로 대화할지 정해둔 게 바로 API 규격입니다.

 

대표적인 규격들

1. REST API

• 지금 웹에서 가장 많이 쓰이는 방식
• 주소(URL)로 자원(Resource)을 표현하고, HTTP 메서드(GET,POST 등)로 행동을 정합니다.
• 예 : /weather?city=seoul => GET이면 날씨 조회, POST면 새 날씨 데이터 추가

 

2. SOAP

• XML 기반, 무겁지만 보안과 트랜잭션 기능이 탄탄해서 금융권에서 주로 사용
• 트랜잭션(Transaction) : DB나 시스템에서 여러 작업을 하나로 묶어서 모두 성공하거나 모두 실패하게 보장하는 단위로, 은행 계좌 이체처럼 절대로 반쪽만 성공하면 안 되는 작업에서 핵심적으로 쓰이는 개념

 

3. GraphQL

• 원하는 데이터만 골라서 가져올 수 있는 방식
• 예 : 날씨는 기온만, 뉴스는 제목만 달라 하고 필요한 정보만 요청할 수 있음

 

4. OpenAPI (Swagger)

• API 문서를 기계가 읽을 수 있는 형식으로 표준화한 것
• 테스트 UI나 자동화된 코드 생성을 쉽게 할 수 있습니다.

 

정리하면, API 규격은 대화의 문법이에요. 문법이 맞아야 시스템끼리 말이 통합니다.

 

 

---

 

API의 권한 : 누가 쓸 수 있을까?

그럼 모든 API를 우리는 사용할 수 있을까요? 정답은 아니다 입니다. 공개 범위에 따라 API는 크게 3가지로 구분됩니다.

 

1. Private API (내부망)

• 기업/기관 내부에서만 사용되는 API
• 예 : 사내 인사 시스템, 내부 전용 대시보드 등
• 외부에 노출되면 안되는 민감한 데이터에 주로 사용

 

2. Partner API (제휴)

• 특정 파트너사만 접근할 수 있는 API
• 예 : 카드사와 제휴된 쇼핑몰이 결제 API를 쓰는 경우
• 비즈니스에서 많이 활용

 

3. OPEN API (Public/공개)

• 누구나 신청만 하면 쓸 수 있는 API
• 예 : 기상청 날씨 API, 카카오맵 API, 공공데이터포탈 API
• 이런 API 덕분에 스타트업이나 개인 개발자가 새로운 서비스를 쉽게 제작

 

즉, API는 누가 접근할 수 있느냐에 따라 3가지로 나뉩니다.

 

여기서 "OPEN API"와 "OpenAPI"가 헷갈리실 수 있는데요, 두 가지는 서로 다른 맥락에서 사용됩니다.

OPEN API(공개 API)는 누구나 사용할 수 있도록 공개된 API를 의미하고, OpenAPI(Swagger)는 API를 문서화하는 규격을 의미합니다. 좀 더 구체적으로 말씀드리자면, 개발자들이 API를 기계가 읽을 수 있는 형태로 정의해두면 자동으로 문서/UI/SDK 코드까지 생성할 수 있게 하는 개념입니다.

 

---

 

API, 어디까지 가능할까?

종류와 규격을 살펴봤으니, 이제 본격적으로 포스팅의 핵심인 적용 범위를 같이 확인해볼까요? 이전 포스팅에서 말씀드렸듯이, API는 메뉴판에 있는 요리만 주문할 수 있다가 핵심입니다.

 

무슨 말이냐면, API는 엄청 강력한 도구지만 그렇다고 무한정 모든게 다 되는 건 아니라는 겁니다. 기본적으로는 문서(API DOCS)에 정의된 기능만 쓸 수 있어요. 예를 들어, 김치찌개 집에 가서 메뉴판에 있는 김치찌개는 주문할 수 있지만, 메뉴판에 없는 닭발은 주문할 수가 없는 거죠.

 

그렇지만, 만약 닭발과 관련된 주문 문의가 계속 들어온다면 주방에서도 메뉴 개발을 고민하겠죠. API 개발도 동일한 원리입니다. 

 

---

메뉴판에 있는 것 : API로 가능한 영역

1. 데이터 조회

API로 제일 많이 하는 게 데이터 조회입니다.

• 날씨 앱이 기상청 API에서 "서울 날씨"를 불러오는 것
• 주식 앱이 한국거래소 API로 삼성전자 현재가를 가져오는 것
• 뉴스 앱이 특정 키워드에 맞는 기사 목록을 불러오는 것

요약하면 있는 데이터를 읽어오기가 API의 특기라고 생각하시면 됩니다.

 

 

2. 기능 실행

단순 조회를 넘어, 실제 행동도 가능합니다.

• 카카오에서 로그인 버튼을 누르면 카카오 API가 인증을 처리하고, 토큰을 발급해주죠.
• 결제 API를 호출하면 카드사 서버에서 결제 승인을 내려줍니다.
• 뉴스 앱이 특정 키워드에 맞는 기사 목록을 불러오는 것도 가능하죠.

단순 데이터를 보는게 아니라, 시스템을 움직이는 역할을 수행합니다.

 

 

3. 서비스 확장

우리가 직접 만들기 부담스러운 기능을 외부 API로 끌어올 수도 있습니다.

• 지도 API를 붙이면 내 앱에서 바로 길찾기가 됩니다.
• 번역 API를 붙이면 내가 번역기를 따로 만들 필요가 없죠.
• 요즘은 이미지 분석, 챗봇, OCR과 같은 기능도 API로 손쉽게 붙입니다.

프리랜서 혹은 스타트업이 빠르게 서비스를 확장할 때 주로 활용할 수 있습니다.

 

---

메뉴판에 없는 것 : API로 불가능한 영역

그렇다면 못하는 건 뭘까요?

 

1. 없는 건 못 한다

날씨 API는 현재 날씨와 예보를 알려줄 수 있습니다. 하지만, "내일 비가 오게 해주세요"와 같은 요청은 API가 못하죠. API는 정보를 불러오거나 기능을 실행하는 창구이지, 세상을 바꾸는 마법이 아니거든요.

 

2. 권한 밖은 못 본다

아까 API의 권한에 대해 말씀드렸죠? 설령 API가 있더라도, 권한이 없으면 접근할 수 없습니다. 보편적으로 API는 사용자별로 고유한 Secret Key를 발급하는데, 내부 직원 전용 API를 외부 고객이 호출하면 Unauthorized(401)과 같은 에러가 return 됩니다.

 

3. 성능 및 용량의 한계

API마다 다르지만, 보통 한 번에 가져올 수 있는 데이터 양이 제한돼 있거나 호출 횟수에 제한(LIMIT)이 걸려 있을 수 있습니다. 예를 들어, 이 API는 하루에 1만 번까지만 호출 가능과 같은 조건이 있죠. 만약 1만번을 넘어가면 서비스가 느려지거나, 호출 자체가 차단당하기도 합니다.

 

---

신규 주문 : AI 챗봇과 그룹웨어 연동

서비스 확장의 사례를 하나 들어볼게요. 고객사에서 AI 챗봇 도입을 희망하는데, 그룹웨어를 연동하고 싶은 니즈가 있다고 가정해보죠. "우리 회사 그룹웨어에 있는 일정이나 결재 현황을 챗봇에서 바로 불러올 수 없을까? 라는 요구는 실제 필드에서 자주 요구되는 주문입니다.

 

원리 자체는 간단합니다. 그룹웨어에서 API를 제공한다면, 챗봇이 그 API를 호출해 데이터를 가져올 수 있습니다. 예를 들어 사용자가 "오늘 내 일정 알려줘"라고 챗봇에 입력하면, 챗봇은 그룹웨어의 캘린더 API를 호출합니다. 응답으로 돌아온 일정 데이터를 챗봇이 다른 데이터에서 가져온 정보와 함께 가공해서 사용자에게 보여주죠. 비슷하게 "휴가 신청해줘"라고 말했을 때, 챗봇이 그룹웨어의 휴가 신청 API를 호출해 전자결재 문서를 자동으로 생성하는 것도 가능합니다.

 

단, 여기에는 중요한 전제가 있습니다.
바로 그룹웨어가 공식적으로 API를 제공해야 한다는 것이죠. 말씀드렸듯이, 메뉴판에 "캘린더"라는 항목이나 "휴가 신청"이라는 항목이 없는데 주문할 수는 없습니다.

또한, 설령 메뉴판이 있다고 해도 몇 가지 확인할 점이 있습니다.

• 권한 문제: 관리자 전용 API인지, 일반 사용자도 호출 가능한 API인지 구분해야 합니다.
• 호출 한도: 하루 몇 번까지 호출 가능한지, 동시 요청 제한이 있는지 체크가 필요합니다.
• 보안 정책: 민감한 데이터가 노출되지 않도록 토큰 인증, 암호화 방식이 제대로 적용되어 있는지 살펴야 합니다.
• 응답 구조 차이: 그룹웨어 API가 반환하는 데이터 형식이 챗봇이 이해하는 구조와 다르면, 중간 변환 계층(어댑터)을 별도로 만들어서 맞춰줘야 합니다.

챗봇과 그룹웨어 연동은 단순히 “API가 있다더라”로 끝나는 게 아니라, 권한·한도·보안·데이터 구조까지 종합적으로 검토해야 안정적으로 돌아갑니다. 즉, 챗봇과 그룹웨어 연동은 "API 메뉴판에 항목이 있느냐"에 따라 달려 있습니다. 메뉴판에 일정/결재/메신저 API가 있다면 챗봇이 호출해 바로 연동할 수 있고, 없는 기능이라면 별도 개발이 필요합니다. 결과적으로 이러한 연동은 단순한 챗봇을 넘어서, 업무 자동화와 생산성 향상으로 이어지는 강력한 서비스 확장 포인트가 됩니다.

 

---

 

마무리

API는 사실 이미 우리 일상 속에 깊숙이 들어와 있습니다.

날씨 앱은 기상청 API를, 카카오 로그인은 카카오 인증 API를, 배달 주문은 결제/메세지 API를 사용하죠. 

 

정리하자면,

• 규격(문법)을 이해하면 개발자와 구체적으로 요건 사항을 논의할 수 있고,
• 종류(공개 범위)를 이해하면 어떤 비즈니스 모델을 만들 수 있을지 감이 오며,
• 적용 가능 범위를 이해하면 고객에게 "이건 API로 바로 가능합니다 / 이건 별도 개발이 필요합니다"라고 명확하게 설명할 수 있습니다.

API는 만능은 아니지만, 제대로 이해하고 설명할 수 있다면 영업과 기획에서 정말 강력한 무기가 됩니다.

이번 포스팅은 여기까지 하고 마무리하겠습니다.
읽으시면서 추가로 궁금한 점이나, 다른 시각에서의 의견·비판도 언제든 환영합니다!