효율적인 개발과 운영을 위해서 개발팀 내에서 다양한 의사 소통 수단은 필수적입니다. 이메일, 메신저, 이슈트래커와 코드 리뷰 등 다양한 방법이 동원되죠. 우리가 만드는 소프트웨어 혹은 서비스간 소통도 매우 중요합니다. 대개 팀 내 혹은 팀간 서비스간 인터페이스(Interface)는 각양각색입니다. CSV나 엑셀 파일을 필요할 때 메일로 보내 준다거나, 주기적으로 XML 파일을 대량 다운로드 받게 하기도 합니다. 최근들어서는 JSON 방식의 REST API를 제공하는 경우가 늘고 있습니다.
사실 API라고 하면 우리가 프로그램을 짤 때, (자바 API나 닷넷 API 처럼) 특정 라이브러리나 플랫폼의 원하는 기능을 호출하는 인터페이스를 말하는 것인데, 최근에는 데이터를 교환하거나 애플리케이션 내 구현 기능을 호출할 때 사용하고 있습니다. API를 통한 메시지 교환 방식은 이른바 서비스 지향 아키텍터(SOA)가 나온 시기로 거슬러 올라가지만, 본격적으로 활용 되기 시작한 때는 바로 웹 2.0이 태동 되던 2000년대 중반이라고 할 수 있습니다.
■ 웹2.0, 오픈 API의 태동
2005년 초반에 저는 Daum의 CTO와 함께 전사 기술 전략과 개발자 채용, 경력 관리 등을 새로 셋팅하는 작업을 하고 있었습니다. 당시 300여명이 넘는 개발자가 20여개가 넘는 개발팀에서 다양한 방식으로 협업을 하는데, 서비스간 소통 방식을 각양각색이었죠. 웹 서비스에서 어떻게 하면 확장 가능하고 효율적인 소통을 만들고, 이를 사내 뿐만 아니라 회사 밖 제3자 개발자에게 전달할 수 있을까 하는 게 주요 관심사였습니다.
2004년 열린 오라일리 웹2.0 컨퍼런스에서는 닷컴버블 이후에 살아남은 인터넷 서비스 기업들이 어떻게 플랫폼 기업으로 살아 남았는지 알려주는 큰 계기가 되었습니다. 즉, 구글, 아마존, 이베이 같은 기업들은 자사의 서비스 인터페이스를 공개함으로서 플랫폼 영향력을 확대했다는 것입니다. 원래 소프트웨어 플랫폼 API는 폐쇄적인데 반해, 웹 서비스 기반 API는 공개되어 있다고 해서 이를 오픈 API라고 불렀습니다.
당시 다음은 웹 검색 엔진을 구글의 유료 API 서비스를 차용하고 있었습니다. 즉, REST API로 검색어 질의를 보내면, 반환된 XML 기반 메시지를 파싱 후 제공하는 간단한 것이었지만, 연간 API 서비스 비용이 수억원에 달하고 있었습니다. 마찬가지로 아마존은 야후 같은 포털에 상품 및 리뷰 API를 제공해 주고, 사용자가 상품 구매 시 커미션을 주는 비지니스를 하고 있었고, 이베이는 경매 상품을 올리는 API를 제공하고 있었는데 무려 50%에 달하는 상품이 리스팅 API를 통해 이루어지고 있었습니다. 대량 판매자들에게 이베이에 상품을 올려주는 프로그램이 엄청나게 많이 만들어지고 있었죠.
■ 플랫폼 vs. 서비스
제가 주목한 건 바로 오픈 API가 플랫폼 사업의 가능성을 보여준다는 사실이었습니다. Daum 사용자는 웹 브라우저와 모바일로 메일, 카페, 검색, 지도를 이용하지만, 이를 오픈 API로 제공하면 이를 활용하는 기업의 또 다른 사용자층까지 확보할 수 있습니다. 예를 들어, 다음 메일을 기업용 인트라넷을 만드는 회사에 API로 제공하면, 이들은 사내용 메일을 구축하려는 기업에게 판매를 할 수 있겠죠. 그러면, 개인용으로만 다음 메일을 사용하는 사람들이 회사에서도 사용하니까, 보이지 않는 사용자의 사용 시간도 대거 확보할 수 있겠죠.
그러나, 이러한 전략은 회사에서 크게 힘을 발휘하지 못했습니다. 왜냐하면, 각 팀의 역량을 모드 일반 사용자에게 쏟고 있는데 외부 기업이나 사용자까지 지원할 여력이 부족하고, 제공하더라도 3자 서비스는 사용하는 다음 밖에 사용자가 다음 사용자냐 아니냐 하는 문제도 있으니까요. 요즘은 일반화한 API 유료 판매 모델이나 광고 등 수익화 방식 제휴 등도 명확하지 않았던 시기였습니다. (왜 플랫폼을 위한 사내 문화가 중요한지 플랫폼은 문화다!라는 글을 참고하세요.)
2006년 3월 저는 웹 기술 커뮤니티 멤버들과 함께 NGWEB 2.0 행사 프로그램에 참여하고 있었는데, 그 행사에는 당시 아마존웹서비스(AWS)의 에반젤리스트였던 Jeff Barr가 방한해 “AWS는 웹 2.0 핵심“라는 주제로 기조 연설을 하였습니다. 당시만 해도 AWS는 오늘날 같은 클라우드 서비스가 아니라, 상품 및 검색 API 등을 제공하고 있었습니다. 제프는 행사 전날 도착해서 기조 연설을 마치고 부랴부랴 귀국길에 올랐는데, 그 날이 AWS 클라우드의 사실상 최초 서비스인 Amazon S3가 출시한 날이었습니다. (왜 그렇게 빨리 갔는지 그 뒤에 알게 되었죠.)
그 해, 저는 이베이 개발자 컨퍼런스 및 Where 2.0 컨퍼런스 그리고 Google Maps Developer Day에서 세상의 변화를 현장에서 목도 할 수 있었습니다. 여기서 보고 느낀 점이 새로운 일을 만드는데 큰 동기 부여가 되었습니다.
■ Daum DNA, 오픈 API 플랫폼을 만들다
안타깝게도 제가 하려고 하는 일에 회사는 관심이 없었지만, 다행히 못하게 말리지는 않더군요. CTO를 설득해서 저의 사이드잡으로 하기로 하고, 우선 검색팀에 가서 막무가내로 몇 가지 API를 만들어달라고 했습니다. 당시는 다음소프트에서 운영하던 검색 서비스를 직접 개발 운영하는 내재화를 시작하고 있었을 뿐 아니라, 때마침 네이버 검색 API가 오픈했던 시기라서 잘 설득할 수 있었습니다. 그리고, 당시 오픈 ID에 관심이 있던 회원정보팀 팀장에게 부탁해서 API를 위한 XML기반 인증 수단(그 이후에 OAuth로 변경)도 만들었습니다. 이는 메일, 블로그, 카페처럼 다음 아이디 기반 서비스 API를 만들 수 있게 하기 위함이었습니다.
이래저래 십시일반 도움을 받아 2006년 10월 다음개발자네트워크(Daum DNA)를 오픈할 수 있게 되고, 1명의 팀원과 인턴을 받아서 작은팀을 꾸렸습니다. 그 후 여러분이 아시는 대로, API 매쉬업과 해커톤 같은 다양한 개발자 전도 활동과 기업간 API 제휴 사업을 확대할 수 있었습니다.
7년이 지나 2013년 연말에는 30여개의 API가 공개되어 있었고, 매일 7천개의 API키에서 월간 3억건의 호출이 일어나고 있었습니다. 검색 및 지도를 비롯해서 다음 오픈 API는 국내에서 가장 앞선 API 서비스였다고 자부할 수 있었습니다.
그 와중에서 오픈 API 플랫폼을 구축하고 운영하는 일은 매우 어려운 일이었습니다. 가장 애로점은 API 공개를 설득하는 일이었습니다. 앞에서 말씀 드린대로 없던 API를 만들고 이를 공개하게 하는 건 서비스 기획자들이 이해하기 힘들 일이죠.
■ 내부 API 활성화라는 부수 효과
그런데, 생각지도 못한 일이 벌어졌습니다. 맨 처음 API를 만든 검색팀의 경우, 오픈 API로 만든 인터페이스를 내부 개발팀이 사용하고 싶다고 요청이 늘어난 것이죠. 블로그나 카페 검색 결과 같은 기능을 내부 여러 서비스에서 추가하려다 보니 필연적으로 편한 API를 활용하겠다는 것입니다. 그러다 보니, 검색팀에서 오픈 API외에도 다른 종류의 내부 API를 추가로 만들고 심지어 API 제공을 위한 서버팜을 구성하기에 이르렀습니다.
실제 검색 API의 경우 오픈 API로 나가는 트래픽은 얼마 되지 않았는데, 내부 API 호출이 기하급수적으로 늘어나는 것이었습니다. 게다가 API를 만들어 공유하는데 소극적인 개발팀들이 좀 더 쉽게 협업을 하기 위해 API를 만들어 직접 내부 공개하고, 심지어 요청하지도 않았는데 Daum DNA에 공개해달라고 부탁하기도 했습니다. 외부 개발자를 위한 플랫폼을 만들겠다고 시작한 일인데, 오히려 사내의 활용도가 더 커지고 있었던 것이죠. 이를 통해 크게 배운 게 있습니다. 결국 내부에서 (개밥먹기 방식으로) 효율성이 인정되면, 결국 옳은 방향으로 가게 된다는 점입니다.
이렇게 API간 직접 호출이 늘어나니 보이지 않은 부작용도 생겼습니다. 예를 들어, 여행 섹션 같이 새로 오픈 하는 섹션은 지도 API나 블로그 검색 API 등을 활용한 정보 페이지가 주요 기능이 되다 보니, 타 팀의 API의 직접 호출이 그 팀 API 서비스 트래픽 및 부하에 영향을 주는 것입니다. 그러다 보니, 타팀에서 오는 운영 부하에 드는 부담을 도대체 어디까지 질건가 하는게 큰 이슈가 되었죠. 공개된 API를 누가 쓰는지 얼마나 쓰는지 알아야 하는 문제도 발생하였습니다.
당시 오픈 API 플랫폼은 외부 개발자 인증/키발급과 캐싱을 통해 어느 정도 부하를 처리하고 있었는데, 오로지 다음 내부 개발자를 위한 API 서비스 플랫폼이 필요하게 되었고 결국 저희팀에서 TF를 만들어 내부 API Hub를 만들게 되었습니다. 그 후 사내에 있었는지도 몰랐던 API들이 하나둘씩 등록하게 되고, 서로 서로 손쉽게 찾고 키 발급 받아 활용할 수 있게 되었습니다. 2013년 내부 API 호출 수는 일간 5억건에 달했습니다. 사실 99% 트래픽이 사내에서 소비되고, 1%만이 외부에서 사용하는 꼴인데, 이건 당시 에버노트나 넷플릭스의 API 사례에서도 마찬가지였습니다.
■ API 소통을 통한 마이크로서비스로의 전환
이제는 API을 통한 소통이 일상화 되었습니다. 작은 스타트업도 자신들의 서비스를 API로 공개해 놓고 있으며, 많은 국내 IT 기업들도 API를 외부에 오픈해 놓고 있습니다. 누구나 이러한 흐름에 동의할 것입니다. 최근에 마이크로서비스(Microservices) 아키텍처가 각광을 받고 있습니다. 즉, 독립적인 작은 서비스 단위로 기능을 쪼개고, API로 소통함으로서 개발 및 배포 속도를 높이는 기법입니다. 하지만, 아직까지 내부 팀간 협업을 REST API로 하고 있지 않다면, 좀 더 민첩한 개발 방식을 도입하는데 큰 장애가 될 것입니다.
당장 모든 기능을 API로 만들 필요는 없습니다. 우선 외부 팀에서 많이 요청하는 몇 가지 기능 부터 별도로 쪼갠 후, API로 만들어 제공하는 것이 좋습니다. 일단 누군가 API를 쓰기 시작하면, 이들 트래픽이 주 사용자에 영향을 미치지 않아야 합니다. 또한, 주기적인 피드백으로 기능 개선을 따로 할 수 있기 때문이죠. 마이크로서비스라는게 어려운게 아니고, 바로 이렇게 시작하는 것입니다. 아직 여러분 회사는 API로 소통하지 않으세요? 지금 시작하세요!
참고. 아래는 제가 발표한 Daum API 사례 및 마이크로서비스 아키텍처 구현 사례에 대한 발표 자료 및 영상입니다.
혹시 API 모범 사례에 대한 다양한 정보를 수집하시려면 아래 해외 컨퍼런스를 참고하시기 바랍니다.
연재 목차
- 훌륭한 개발 문화의 이면(1) – 코딩 테스트인터뷰 제대로 하기
- 훌륭한 개발 문화의 이면(2) – 자율적 개발 환경을 선택하라!
- 훌륭한 개발 문화의 이면(3) – 다른 팀 소스 코드를 볼 수 있는가?
- 훌륭한 개발 문화의 이면(4) – 사내 라이브러리를 잘 관리하려면?
- 훌륭한 개발 문화의 이면(5) – 소통 비용의 절약 – 서로 API로 말하자
- 훌륭한 개발 문화의 이면(6) – 입사하고픈 회사를 위한 오픈 전략 구사하기
- 훌륭한 개발 문화의 이면(7) – 잉여력이냐 vs. 효율성이냐
※ Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources.)
* 이 글의 댓글 일부는 Webmention 도구를 이용하여, 소셜 미디어 공유 반응(Comments, Like, Tweet)을 수집한 것입니다.