API 연동 API Integration
홈 › 용어 사전 · 안녕소프트 최재원 · 2026. 9. 22. 작성
API 연동은 두 시스템이 미리 정한 규격의 요청과 응답으로 데이터를 직접 주고받도록 연결하는 방식입니다. 쇼핑몰 주문을 ERP로 가져오거나, 회계 프로그램의 전표를 은행 자료와 맞추는 일이 사람 손을 거치고 있다면 API 연동의 대상입니다. 파일을 주고받는 방식이나 데이터베이스를 직접 여는 방식과 자주 비교되는데, 안정성과 권한 관리 면에서 차이가 큽니다. 다만 상대 시스템이 API를 열어 두어야 가능합니다.
API 연동이 하는 일
API는 프로그램이 다른 프로그램에게 일을 시키는 창구입니다. 사람이 화면에서 버튼을 누르듯, 프로그램은 API에 정해진 형식으로 요청을 보내고 정해진 형식의 응답을 받습니다. 예를 들어 쇼핑몰 API에 어제 주문 목록을 달라고 요청하면 주문 번호, 상품, 금액이 정형 데이터로 돌아옵니다. 그 데이터를 우리 ERP에 넣으면 사람이 주문을 옮겨 적을 일이 없어집니다.
실무에서 API 연동이 쓰이는 장면은 다음과 같습니다.
- 쇼핑몰·마켓 주문을 ERP나 창고 시스템으로 자동 수집
- 택배사에 송장 발급을 요청하고 결과를 받아 등록
- 회계 프로그램과 은행·카드 거래 내역 동기화
- 메신저·문자 발송 서비스로 알림 전송
- 공공 데이터나 환율·날씨 같은 외부 정보 조회
핵심은 사람이 중간에 끼지 않고 시스템끼리 직접 대화한다는 점입니다. 화면을 흉내 내는 RPA와 달리 화면이 바뀌어도 영향이 없고, 요청과 응답이 기록으로 남아 문제가 생겼을 때 원인을 찾기 쉽습니다.
파일 연동·DB 연동·API 연동 비교
시스템을 잇는 방법은 크게 세 가지입니다. 어느 것이 옳다기보다 상황에 따라 맞는 방식이 다릅니다.
파일 연동은 한쪽이 엑셀이나 CSV 파일을 내보내고 다른 쪽이 읽어 들이는 방식입니다. 만들기 쉽고 상대 시스템에 요구할 것이 적습니다. 대신 실시간이 아니고, 파일 형식이 조금만 바뀌어도 읽기에 실패하며, 누가 언제 어떤 파일을 넣었는지 관리가 어렵습니다.
DB 연동은 상대 시스템의 데이터베이스에 직접 접속해 읽거나 쓰는 방식입니다. 빠르고 자유롭지만 위험합니다. 상대 시스템이 내부 구조를 바꾸면 바로 깨지고, 잘못 쓰면 상대 데이터를 손상시킬 수 있습니다. 대부분의 외부 서비스는 DB 접속을 허용하지 않고, 같은 회사 안의 시스템끼리도 권장되지 않습니다.
API 연동은 상대가 공개한 창구만 이용합니다. 내부 구조가 바뀌어도 창구 규격이 유지되면 영향이 없고, 권한을 세밀하게 나눌 수 있으며, 요청마다 기록이 남습니다. 대신 상대가 API를 제공해야 하고, 인증과 호출 한도 같은 규칙을 지켜야 합니다. 상대가 API를 열어 두었다면 API 연동을 우선 택하고, 없을 때 파일 연동을 차선으로 보는 것이 일반적인 순서입니다.
인증: API 키와 OAuth
API는 아무나 부를 수 없습니다. 누가 요청하는지 확인하는 절차가 인증이고, 실무에서 만나는 방식은 두 가지가 대부분입니다.
API 키는 서비스가 발급한 긴 문자열을 요청마다 함께 보내는 방식입니다. 집 열쇠와 비슷합니다. 단순해서 서버끼리 연결할 때 널리 쓰이지만, 키가 새면 누구든 우리 이름으로 요청할 수 있습니다. 그래서 키는 소스 코드나 문서에 적어 두지 않고 별도로 보관하며, 주기적으로 바꾸고, 필요한 권한만 부여합니다.
OAuth는 사용자가 직접 로그인해 우리 프로그램에 권한을 허락하는 방식입니다. 외부 서비스에 접속하면 나오는 권한 동의 화면이 이것입니다. 허락 결과로 토큰을 받는데, 이 토큰은 유효 기간이 있어 만료되면 갱신해야 합니다. 비밀번호를 우리 쪽에 저장하지 않아도 되고 권한을 항목별로 제한할 수 있어 안전합니다.
어느 방식을 쓸지는 우리가 고르는 것이 아니라 상대 서비스가 정합니다. 연동을 설계할 때는 토큰 만료와 갱신, 키 보관 위치, 권한 범위를 반드시 정해 두어야 합니다. 이것을 빠뜨리면 다음 항목에서 설명하는 끊김의 원인이 됩니다.
연동이 끊기는 흔한 이유
잘 되던 연동이 어느 날 멈추는 일은 드물지 않습니다. 원인은 대개 몇 가지로 좁혀집니다.
- 인증 만료: 토큰이나 키에 유효 기간이 있는데 갱신 절차가 없었던 경우입니다. 가장 흔합니다
- API 규격 변경: 상대 서비스가 새 버전을 내고 옛 버전 지원을 끝내는 경우입니다. 보통 몇 달 전에 공지가 나오지만 담당자 메일함에 묻히기 쉽습니다
- 호출 한도 초과: 하루 또는 분당 호출 횟수를 넘기면 응답이 거부됩니다. 데이터가 늘거나 재시도 로직이 잘못되면 한도를 넘깁니다
- 데이터 형식 변화: 없던 항목이 생기거나 날짜 표기가 바뀌면 받는 쪽이 처리하지 못합니다
- 상대 서비스 장애: 우리 잘못이 아니지만 대응은 우리 몫입니다
그래서 연동은 만들 때보다 끊겼을 때를 어떻게 알아차리고 복구하느냐가 더 중요합니다. 실패하면 즉시 담당자에게 알림이 가고, 실패한 건은 나중에 다시 처리할 수 있도록 보관하며, 상대 서비스의 변경 공지를 받는 연락처를 등록해 두는 것이 기본입니다. 이 세 가지만 갖춰도 끊김이 사고로 번지는 일을 대부분 막을 수 있습니다.
| 구분 | 파일 연동 | DB 연동 | API 연동 |
|---|---|---|---|
| 방식 | 엑셀·CSV 내보내기와 가져오기 | 상대 데이터베이스에 직접 접속 | 상대가 공개한 창구에 요청·응답 |
| 실시간성 | 낮음(주기 실행) | 높음 | 높음 |
| 상대 구조 변경 시 | 형식이 바뀌면 실패 | 구조가 바뀌면 바로 깨짐 | 창구 규격이 유지되면 영향 없음 |
| 권한·안전 | 파일 관리에 의존 | 잘못 쓰면 상대 데이터 손상 | 권한을 세밀하게 제한, 요청 기록 |
| 전제 조건 | 거의 없음 | DB 접속 허용(대부분 불가) | 상대가 API를 제공해야 함 |
API 연동 자주 묻는 질문
상대 시스템에 API가 없으면 연동이 불가능한가요?
API 연동은 불가능하지만 다른 길은 있습니다. 파일 내보내기 기능이 있으면 파일 연동으로, 화면만 있으면 RPA로 대신할 수 있습니다. 다만 안정성은 API보다 낮으므로 상대 업체에 API 제공 계획이 있는지 먼저 확인해 보는 것이 좋습니다.
API 키는 어디에 보관해야 하나요?
소스 코드, 엑셀, 메신저에 적어 두면 안 됩니다. 서버의 환경 설정이나 별도 비밀 저장소에 두고 접근 권한을 제한합니다. 키가 유출된 것으로 의심되면 즉시 새 키를 발급받고 옛 키를 폐기해야 합니다.
연동을 만든 뒤에도 비용이 드나요?
상대 서비스의 규격 변경, 인증 갱신, 장애 대응이 계속 생기므로 유지보수는 필요합니다. 규모는 연동 개수와 상대 서비스의 변경 빈도에 따라 다릅니다. 견적 단계에서 실패 알림과 변경 대응 범위를 함께 정해 두는 것이 좋습니다.
실무에서 이 개념이 어떻게 쓰이는지는 4대보험 API 종류와 연동 방법 · ERP 구축·제작, 어떻게 진행되나 · 프로그램 제작 의뢰, 이렇게 준비하면 견적이 정확해집니다 에 정리했습니다.
API 연동, 우리 회사 업무에 어떻게 적용할지 궁금하시다면
지금 쓰시는 엑셀이나 업무 순서를 알려주시면, 어디까지 시스템으로 옮길 수 있는지 단계별로 정리해 드립니다.