나는 약 20년간 전문 소프트웨어 개발자로 꾸준하게 일해왔으며, 그동안 다양한 API를 사용해왔다. 젊은 시절에는 BASIC과 Z80 기계 코드로 어드벤처 게임을 함께 해킹하면서 보냈는데, 내가 만든 코드가 인터페이스로 연결되는 것은 물론 다른 사람이 내가 만든 코드를 사용할 것이라고 생각조차 하지 않았다. 1999년 대학 입학 전에 ‘푸이(pooeys)’라는 애칭을 갖고 직원으로 IBM에 입사하고 나서야 다른 사람이 사용할 수 있도록 작성된 코드를 처음 접하게 됐다. 어느 여름에는 C++ 네트워킹 라이브러리를 테스트 프레임워크에 통합하기 위해 간단한 소개서만을 갖고 용기 있게 도전한 적이 있는데, 그 당시엔 보안보다는 이해할 수 없는 컴파일러 오류 메시지를 해독하는 데 더 신경을 썼던 것으로 기억한다.
시간이 지나면서 API(Application Program Interface)의 개념은 원격으로 접근하는 인터페이스를 포함하도록 변경됐기 때문에 더 이상 보안을 염두에 두지 않을 수 없게 됐다. 코드를 실행할 때 불안해했던 C++ 대신에 결국 엔터프라이즈 자바빈(Enterprise Java Beans)을 사용하게 됐는데, 고유한 방식의 원격 API 호출과 엄청난 인터페이스 및 상용구 코드가 있었기 때문이었다. 그 당시 내가 무엇을 만들고 있었는지는 기억나지 않지만 그것이 무엇이든지 간에 이 모든 코드는 중요하게 사용됐을 것이다. 나중에 SOAP(Simple Object Access Protocol) 및 XML-RPC(Remote Procedure Call) 형식으로 많은 XMLe/(Xtensible Markup Language)을 추가했지만 도움이 되지는 않았다. RESTful(REpresentational State Transfer) API와 JSON(JavaScript Object Notation)의 등장은 마치 신선한 공기와 같았고, 마침내 API를 세상에 공개하는 것을 멈추고 생각할 만큼 충분히 간단해졌다. 보안에 대해서도 진지하게 관심을 갖게 된 것도 이 무렵이었다.
2013년에는 선 마이크로시스템즈(Sun Microsystems)의 잿더미에서 부상한 신생 기업인 포지록(ForgeRock)에 합류하게 됐다. 회사는 인증 및 접근 관리 제품을 위한 최신 REST API 개발 때문에 바빴고 나는 바로 작업에 투입됐다. 그 과정에서 최근 몇 년 동안 API 보안을 변화시키고 이 책의 상당 부분을 형성하는 최신의 토큰 기반 인증 및 권한 부여 기술에 대해 집중적으로 배웠고, 매닝(Manning)으로부터 책 집필 제안을 받았을 때도 API 보안이 주제라는 것을 바로 알아차릴 수 있었다.
집필하는 동안 책의 윤곽은 여러 번 바뀌었지만 보안의 세부 사항이 중요하다는 원칙은 유지했다. 보안은 ‘인증’ 또는 ‘접근 통제’라는 박스를 추가해서 순전히 아키텍처 수준에서만 실현할 수 없으며, 보호해야 할 대상과 각각의 박스가 제공할 수 있는 것과 제공할 수 없는 것을 정확히 이해해야만 하지만 반면에 보안이 모든 것을 처음부터 다시 만들도록 하지는 않는다. 이 책의 입장은 완전히 중간이길 바란다. 일반적인 보안 문제에 대한 현재 상태를 설명하면서 최신의 상용 솔루션에 대한 많은 정보를 제공할 것이기 때문이다.
두 번째 원칙은 보안 기술이 여러 곳에 적용되는 경우는 거의 없다는 것이다. 웹 애플리케이션에서 작동하는 것을 마이크로서비스(microservice) 아키텍처에서 사용하는 것이 완전히 맞지 않을 것이다. 직접적인 경험을 바탕으로 웹 및 모바일 클라이언트용 API, 쿠버네티스(Kubernetes) 환경의 마이크로서비스용 API, 사물 인터넷(IoT, Internet of Things)용 API 보안에 대한 장을 포함했는데 각각의 환경에는 고유한 문제와 해결책이 존재한다.
