이미 소장하고 있다면 판매해 보세요.
|
0장 API 아키텍처 설계 여정을 시작하며
아키텍처 여정 API에 대한 간략한 소개 실전 예제: 컨퍼런스 시스템 사례 연구 __컨퍼런스 사례 연구의 API 종류 __컨퍼런스 시스템을 변경해야 하는 이유 __다계층 아키텍처에서 API 모델링으로의 전환 __사례 연구: 진화적 단계 __API 인프라스트럭처와 트래픽 패턴 __컨퍼런스 사례 연구의 로드맵 C4 다이어그램의 활용 __C4 컨텍스트 다이어그램 __C4 컨테이너 다이어그램 __C4 컴포넌트 다이어그램 ADR의 사용 __참석자 개선 ADR __API 마스터하기: ADR 가이드라인 정리 [1부] API 설계부터 구현, 테스트까지 1장 API 설계, 구현, 명세 사례 연구: 참석자 API의 설계 REST에 대한 소개 __예시를 통한 REST와 HTTP 소개 __리처드슨 성숙도 모델 원격 프로시저 호출(RPC) API에 대한 소개 그래프QL에 대한 간단한 소개 REST API 표준과 구조 __컬렉션과 페이징 __컬렉션 필터링 __에러 처리 __ADR 가이드라인: API 표준의 선택 OpenAPI로 REST API 명세 작성하기 OpenAPI 명세의 실질적 활용 __코드 생성 __OpenAPI 검증 __예제와 모의 데이터 __변경의 탐지 API 버저닝 __시맨틱 버저닝 __OpenAPI 명세와 버저닝 gRPC로 RPC 구현하기 교환 방식과 API 형식의 선택 __트래픽이 높은 서비스 __대용량 데이터 페이로드 __HTTP/2의 성능 이점 __구형 형식들 가이드라인: 교환 데이터의 모델링 다중 명세 __월등한 명세는 존재하는가 __다중 명세를 제공할 때의 어려움 정리 2장 API 테스트 이번 장에서 다룰 컨퍼런스 시스템의 시나리오 테스트 전략 __테스트 사분면 __테스트 피라미드 __테스트 전략에 대한 ADR 가이드라인 계약 테스트 __계약 테스트를 더 선호하는 이유 __계약의 구현 __ADR 가이드라인: 계약 테스트 API 컴포넌트 테스트 __계약 테스트와 컴포넌트 테스트의 비교 __사례 연구: 컴포넌트 테스트로 동작 검증하기 API 통합 테스트 __스텁 서버를 사용해야 하는 이유와 방법 __ADR 가이드라인: 통합 테스트 __테스트 컴포넌트의 컨테이너화: Testcontainers __사례 연구: Testcontainers를 이용한 통합 검증 종단 간 테스트 __종단 간 검증의 자동화 __종단 간 테스트의 종류 __ADR 가이드라인: 종단 간 테스트 정리 [2부] API 트래픽 관리 3장 API 게이트웨이: 인그레스 트래픽 관리 API 게이트웨이가 유일한 해결책일까? 가이드라인: 프록시, 로드밸런서 또는 API 게이트웨이의 선택 사례 연구: 참석자 서비스를 소비자에게 노출하기 API 게이트웨이의 정의 API 게이트웨이의 기능 API 게이트웨이의 배포 위치 API 게이트웨이와 다른 에지 기술의 통합 API 게이트웨이를 사용해야 하는 이유 __프론트엔드와 백엔드의 낮은 결합도: 어댑터/퍼사드 패턴의 활용 __사용법의 간소화: 백엔드 서비스의 종합과 해석 __남용 및 오용으로부터 API 보호: 위협 탐지와 완화 __API 활용 방식에 대한 이해: 관측용이성 __API를 제품으로 관리하기: API 수명주기 관리 __API의 수익화: 계정 관리, 비용 청구, 결제 모던 API 게이트웨이의 역사 __1990년대 이후: 하드웨어 로드밸런서 __2000년대 초반 이후: 소프트웨어 로드밸런서 __2000년대 중반: 애플리케이션 전달 컨트롤러(ADC) __2010년대 초: 1세대 API 게이트웨이 __2015년 이후: 2세대 API 게이트웨이 현재의 API 게이트웨이 분류 __전통적인 엔터프라이즈 게이트웨이 __마이크로서비스/마이크로 게이트웨이 __서비스 메시 게이트웨이 __API 게이트웨이 유형 비교 사례 연구: API 게이트웨이를 이용한 컨퍼런스 시스템의 개선 __쿠버네티스에 엠버서더 에지 스택 설치하기 __URL 경로와 백엔드 서비스의 매핑 설정 __호스트 기반 라우팅을 이용한 매핑 설정 API 게이트웨이 배포: 장애에 대한 이해와 관리 __API 게이트웨이도 단일 실패 지점이다 __문제의 탐지와 해결 __장애와 문제의 해결 __위험의 완화 API 게이트웨이 구현의 보편적인 위험 __API 게이트웨이 루프백 __API 게이트웨이를 ESB처럼 활용 __모두가 거북이(API 게이트웨이)가 되는 현상 API 게이트웨이의 선택 __요구사항의 파악 __구현과 구입의 비교 __ADR 가이드라인: API 게이트웨이의 선택 정리 4장 서비스 메시: 서비스 간 트래픽 관리 서비스 메시가 유일한 해결책인가 가이드라인: 서비스 메시를 도입해야 할까 사례 연구: 세션 기능을 서비스로 분리하기 서비스 메시란 서비스 메시가 제공하는 기능들 서비스 메시를 배포하는 위치 서비스 메시는 다른 네트워크 토폴로지와 어떻게 통합될까 서비스 메시를 사용해야 하는 이유 __라우팅, 신뢰성, 트래픽 관리에 대한 세분화된 제어 __투명한 관측용이성의 제공 __보안의 적용: 전송 보안, 인증, 인가 __여러 언어의 교차 기능적 통신의 지원 __인그레스 트래픽과 서비스 간 트래픽 관리의 분리 서비스 메시의 진화 __초기의 역사와 그 동기 __구현 패턴 서비스 메시의 분류 사례 연구: 서비스 메시를 이용한 라우팅, 관측 가능성 그리고 보안 __이스티오를 이용한 라우팅 __링커드를 이용한 트래픽 관측 __콘설을 이용한 네트워크 분할 서비스 메시의 배포: 장애의 이해와 관리 __서비스 메시는 단일 실패 지점이다 서비스 메시 구현의 공통적인 어려움 __서비스 메시를 ESB로 사용하는 경우 __서비스 메시를 게이트웨이로 사용하는 경우 __네트워크 계층이 너무 많은 경우 서비스 메시의 선택 __요구사항 분석 __구현과 구입의 비교 __체크리스트: 서비스 메시의 선택 정리 [3부] API의 운영과 보안 5장 API의 배포와 릴리스 배포와 릴리스의 분리 __사례 연구: 기능 플래그 __트래픽 관리 사례 연구: 컨퍼런스 시스템의 릴리스 모델링 __API 수명주기 __수명주기에 릴리스 전략을 결합하기 __ADR 가이드라인: 트래픽 관리와 기능 플래그를 이용한 배포와 릴리스의 분리 릴리스 전략 __카나리 릴리스 __트래픽 미러링 __블루-그린 사례 연구: 아르고 롤아웃으로 롤아웃 수행하기 성공에 대한 모니터링과 장애의 인지 __관측용이성을 지탱하는 3가지 요소 __API에서 중요한 지표 __신호 읽어내기 효율적인 소프트웨어 릴리스를 위한 애플리케이션의 대응 __응답 캐싱 __애플리케이션 수준 헤더 전파 __디버깅을 돕기 위한 로깅 __규약형 플랫폼 고려하기 __ADR 가이드라인: 규약형 플랫폼 정리 6장 운영 보안: API의 위협 모델링 사례 연구: 참석자 API에 OWASP 적용하기 외부 API가 안전하지 않을 때의 위험 위협 모델링의 기초 공격자 입장에서 생각하기 위협 모델링 실습 __1단계: 목표를 정의한다 __2단계: 올바른 정보를 수집한다 __3단계: 시스템을 분할한다 __4단계: 위협을 정의한다(스트라이드의 활용) __5단계: 위협의 위험도를 평가한다 __6단계: 검증한다 정리 7장 API의 인증과 인가 인증 __토큰을 이용한 최종 사용자 인증 __시스템 간 인증 __키와 사용자를 혼합하면 안 되는 이유 OAuth2 __API 사용 시 인가 서버의 역할 __JSON 웹 토큰(JWT) __OAuth2 승인 관련 메커니즘과 용어 __ADR 가이드라인: OAuth2를 고려해야 할까 __인가 코드 승인 __리프레시 토큰 __클라이언트 자격증명 승인 __추가 OAuth2 승인 __ADR 가이드라인: 지원할 OAuth2 승인의 선택 __OAuth2 범위 __인가의 수행 OIDC 소개 SAML 2.0 정리 [4부] API의 진화적 아키텍처 8장 API 주도 아키텍처로의 재설계 시스템의 진화에 API가 필요한 이유 __유용한 추상화: 응집도의 향상 __도메인 경계의 정립: 낮은 결합도의 촉진 사례 연구: 참석자 도메인 경계의 확립 최종적인 아키텍처의 선택 __모놀리식 __서비스 지향 아키텍처 __마이크로서비스 __함수 진화적 절차의 관리 __목표의 결정 __적합성 함수의 활용 __시스템을 모듈로 나누기 __확장의 ‘이음새’가 될 API 구현하기 __시스템 내에서 변경 유발 지점 식별하기 __지속적 전달과 검증 API로 시스템을 진화시키기 위한 아키텍처적 패턴 __교살자 무화과나무 __퍼사드와 어댑터 __API 계층 케이크 어려운 부분과 기회를 식별하기 __업그레이드와 유지보수 이슈 __성능 이슈 __의존성의 제거: 결합도가 높은 API들 정리 9장 클라우드 플랫폼으로의 진화 사례 연구: 참석자 서비스를 클라우드로 이전하기 클라우드 마이그레이션 전략의 선택 __유지하거나 재검토 __호스트 교체 __플랫폼 교체 __재구매 __리팩토링/아키텍처 재설계 __퇴출 사례 연구: 참석자 서비스의 플랫폼을 클라우드로 교체하기 API 관리의 역할 수직 및 수평 트래픽: 트래픽 관리의 경계를 흐리게 하기 __에지부터 시작해 점차 내부로 마이그레이션을 수행하자 __경계 건너기: 네트워크 간 라우팅 구역화 아키텍처에서 제로 트러스트로의 이전 __구역으로의 진입 __아무도 믿지 말고 검증하자 __제로 트러스트 아키텍처에서 서비스 메시의 역할 정리 10장 지속적인 아키텍처 진화를 위해 사례 연구: 지금까지의 변화 API, 콘웨이의 법칙 그리고 여러분의 조직 의사결정 종류의 이해 미래를 위한 준비 __비동기 통신 __HTTP/3 __플랫폼 기반 메시 API 아키텍처를 계속 학습하기 위한 방법 __기반 기술을 계속해서 연마한다 __업계의 최신 정보를 얻는다 __레이더, 쿼드란트, 트렌드 리포트 __권장 기법과 사용 사례를 학습한다 __실전을 통해 학습한다 __가르치면서 학습한다 |
James Gough
제임스 고프의 다른 상품
Daniel Bryant
Matthew Auburn
장현희의 다른 상품
|
[여는 글]
10여 년 전 「파이낸셜 타임스」에서 처음 API를 개발할 때만 해도 그렇게 많은 API를 개발하지는 않던 시기였다. 우리는 모놀리식 아키텍처를 채택했고 API는 서드파티가 우리 콘텐츠에 접근하게 하기 위한 용도로만 사용했었다. 하지만 지금은 어디에나 API가 존재하며 API야말로 성공적인 시스템 구현의 핵심이 되고 있다. 그 이유는 지난 10년간 몇 가지 요인으로 인해 우리가 소프트웨어를 개발하는 방식이 바뀌었기 때문이다. 첫 번째 요인은 우리가 사용할 수 있는 기술이 많이 달라졌다는 점이다. 클라우드 컴퓨팅의 등장으로 대고객용 서비스의 제작과 수요에 따른 프로비저닝이 가능해졌다. 자동화된 빌드와 배포 파이프라인 덕분에 지속적 통합과 배포가 가능해졌으며, 컨테이너 및 오케스트레이션 같은 관련 기술로 인해 작고 독립적인 서비스로 하나의 분산 서비스를 구성할 수 있게 됐다. 그렇게 하는 이유는 뭘까? 바로 두 번째 요인 때문이다. 연구 결과에 따르면 소프트웨어를 성공적으로 개발하는 조직은 느슨하게 결합된 아키텍처를 채택하고 있으며 팀에 자율성과 권한을 부여한다. 여기서 성공적이라는 단어는 비즈니스에 긍정적인 영향, 즉 시장 점유율, 생산성, 수익성의 증가 등을 의미한다. 요즘 채택하는 아키텍처는 결합이 느슨하며 분산 환경에서 API를 활용해 구현하는 경향이 있다. 따라서 발견 가능하고 일관적이며, 설령 예상치 못하게 변경되거나 사라져도 고객에게 문제를 유발할 가능성이 낮은 API를 구현하고 싶을 것이다. 이 외의 방법들은 서로 결합되어 동작하며 팀의 속도를 저하시킨다. 이 책의 저자인 제임스, 대니얼, 매튜는 효과적인 API 아키텍처를 구현하기 위한 포괄적이면서도 실용적인 가이드를 제공한다. 개별 API를 개발하고 테스트하는 기본적인 것부터 그 API를 배포할 생태계, 이를 효과적으로 릴리스하고 운영하는 방법 그리고 더 중요한 주제, 즉 API를 이용해 아키텍처의 진화를 이끌어내는 방법에 이르기까지 수많은 주제를 다룬다. 내가 처음 「파이낸셜 타임스」에서 개발했던 API는 이제 더 이상 존재하지 않으며, 해당 시스템을 처음부터 다시 개발했다. 그 과정에는 비용이 따른다. 제임스, 대니얼, 매튜는 API를 핵심 도구로 사용해 불가피한 변화를 다루고 시스템을 진화시키는 방법에 대한 템플릿을 제공한다. 소프트웨어 아키텍처는 중요하기도 하지만 바꾸기 어려운 결정에 의해 정의되어 왔다. 이런 결정은 프로젝트의 성패 여부를 결정한다. 저자들은 추상적인 아키텍처가 아니라 여러분의 조직에 아키텍처를 적용하는 방법에 집중한다. API 게이트웨이 또는 서비스 메시를 도입하고 또 그중 어떤 것을 도입할 것인지를 결정하는 것이 바로 되돌리기 어려운 결정이므로 주의를 기울여 조심히 평가해야 할 결정이다. 제임스, 대니얼, 매튜는 적절한 경우에는 규약이 명확한 가이드를 제시하며, 옵션이 명확하지 않을 때는 여러분의 상황에 맞는 최선의 선택을 내릴 수 있는 프레임워크를 제공한다. 저자들은 실용적이면서도 실질적인 사례 연구를 통해 개념을 소개하고 실제로 동작하게 만드는 방법을 보여준다. 이 책에서 소개하는 사례 연구는 마치 실제 시스템처럼 책을 읽어가는 동안 계속해서 개선된다. 저자들은 모든 것을 미리 할 필요는 없다는 점을 보여준다. 여러분은 필요에 따라 아키텍처를 조금씩 개선하고 서비스를 추출하며 API 게이트웨이와 서비스 메시 같은 도구를 추가해 가면 된다. 나는 첫 API를 개발하면서 무수히 많은 실수를 저질렀다. 그때 이 책이 있었더라면 방향을 이해하고 더 유용한 결정을 내리는 데 큰 도움이 되었을 것이다. API를 중점적으로 활용하는 시스템을 다루는 사람이라면 누구나 이 책을 읽어볼 것을 강력히 권한다. 이 책을 통해 조직 내에서 API를 구현하는 모든 팀을 지원하기 위한 도구와 표준을 구현해낼 수 있을 것이다. - 사라 웰스(Sarah Wells) / QCon 런던 컨퍼런스의 공동 운영자, 독립 컨설턴트이자 전 「파이낸셜 타임스」의 기술 디렉터 [지은이의 말] 우리 저자 중 짐과 매튜는 2020년 초에 뉴욕에서 열린 오라일리 소프트웨어 아키텍처 컨퍼런스에서 API에 대한 워크숍과 API 게이트웨이에 대한 발표를 진행했다. 그리고 짐과 대니얼은 런던 자바 커뮤니티를 통해 이미 서로를 알고 있는 상태였고, 다른 아키텍처 세미나에서와 마찬가지로 우리는 API 아키텍처에 대한 생각과 이해를 공유하는 대화를 주고받았다. 우리가 대화를 계속 이어가자 몇몇 컨퍼런스 대표들도 우리와 어울려 API에 대한 자신의 경험을 얘기하기 시작했다. 그리고 자신들의 API 구현에 대한 우리의 생각과 가이드를 요청했다. 그러자 컨퍼런스에서 다른 아키텍트들과 나눴던 내용을, API를 주제로 하는 책을 통해 공유하는 것도 좋겠다는 생각이 들었다. 이 책은 API 아키텍처의 설계, 운영, 개선에 대한 완전한 밑그림을 제공하기 위해 집필했다. 글과 함께 참석자들이 발표 세션을 보고 예약할 수 있는 실서비스 수준의 이벤트 관리 컨퍼런스 시스템의 구현 사례를 통해 우리의 경험과 조언을 공유한다. 이 사례는 추상적인 개념을 실제 애플리케이션에 반영하는 방법을 보여주기 위해 이 책 전반에 걸쳐 활용하고 있다. 이 구현 사례의 개선에 대한 전체적인 이해가 필요하다면 10장을 참고하기 바란다. 이 책은 그저 새로운 기술을 다루는 책이 아니다. 기존의 아키텍처를 더 적합한 API 아키텍처로 개선하는 방법을 보여주는 것이 여러분에게 가장 도움이 되는 방법이라고 생각한다. 또한 API 아키텍처라는 주제 안에서 기존 아키텍처의 개선과 새로운 기술 및 개발 사이의 균형을 맞추고자 노력했다. [옮긴이의 말] API는 더 이상 단순한 인터페이스가 아닙니다. 오늘날 API는 조직의 경계를 잇고, 팀 간 협업의 방식을 규정하며, 시스템의 확장성과 안정성을 좌우하는 핵심 아키텍처 요소가 되었습니다. 이 책은 이러한 변화 속에서 API를 어떻게 설계하고, 운영하며, 조직 전반의 아키텍처 전략으로 끌어올릴 수 있는지를 매우 현실적인 관점에서 다루는 책입니다. 이 책의 가장 큰 강점은 이론에 머무르지 않고, 실제 대규모 시스템과 분산 환경에서 API가 직면하는 문제들을 구체적인 사례와 함께 설명한다는 점입니다. 보안, 확장성, 관측 가능성, 거버넌스, 그리고 팀과 조직 구조에 이르기까지, API 아키텍처가 영향을 미치는 범위를 폭넓게 조망합니다. 번역 과정에서는 이러한 맥락과 저자들의 의도가 한국어 독자에게도 자연스럽게 전달될 수 있도록, 단순한 직역보다는 의미와 흐름을 살리는 데 중점을 두었습니다. 또한 API, 마이크로서비스, 클라우드 네이티브 환경에서 이미 통용되고 있는 용어들은 불필요하게 번역하지 않고 원어를 유지하되, 이해에 도움이 필요한 부분에는 설명을 덧붙였습니다. 이를 통해 현업에서 API를 설계·운영하는 개발자와 아키텍트 모두가 실제 업무에 바로 적용할 수 있는 번역본을 만드는 것을 목표로 했습니다. 이 책이 API를 단순한 기술 요소가 아닌, 시스템과 조직을 관통하는 아키텍처적 결정으로 바라보는 데 도움이 되기를 바라며, 여러분의 설계 판단과 기술적 선택에 신뢰할 수 있는 길잡이가 되기를 기대합니다. - 장현희 --- 본문 중에서 |
|
| 이 책에서 다루는 내용 |
· API의 기초와 API 플랫폼을 구현하기 위한 아키텍처 패턴 학습 · 실용적인 예제를 통해 API 기반 시스템의 설계, 구현, 테스트 방식 이해 · API 플랫폼의 배포와 운영 및 핵심 컴포넌트 구성 방법 · 사례 연구를 통한 API 게이트웨이와 서비스 메시의 활용 방안 · API 아키텍처의 핵심적인 보안 기법과 보편적인 취약점 이해 · 위협 모델링과 OAuth2 및 TLS 기술을 이용한 데이터와 API 보호 방안 · 기존의 시스템을 API와 클라우드 기반 아키텍처로 진화시키는 방법 |
|
사람들은 컨테이너와 마이크로서비스에 집중하느라 정작 운영 중인 서비스들의 상호작용과 관련된 부분을 경시하는 경향이 있다. 이 책은 API의 구조와 진화에 대한 깊은 통찰을 제시함으로써 이 점을 바로잡는다. - 샘 뉴먼 (『마이크로서비스 도입, 이렇게 한다』 저자)
|
|
수많은 팁과 예시, 실용적인 조언으로 가득한 훌륭한 책이다. - 스테파니 채플린 (깃랩(GitLab) & DevStefOps)
|
|
클라우드 서비스나 디지털 프로덕트를 개발하다 보면 결국은 API로 이야기들이 모아진다. 그리고 디지털 트랜스포메이션을 지나서 AI 트랜스포메이션을 향해 나아가는 시대에 API는 더 이상 인터페이스가 아니라 시스템의 경계이자 상호 계약의 틀이 된다. 초기에는 간단한 한두 개의 역할을 하던 API들이 꼬리에 꼬리를 무는 형태로 설계가 확장되어 API 게이트웨이, 그리고 서비스 디스커버리 등등이 엮여 더 커지면, API는 그저 트래픽 통로가 아니라 보안·확장·운영 전략이 응축된 아키텍처, 그리고 회사의 핵심 제품이 되어 또 다른 거대한 활용의 축이 된다.
이 책은 그런 순간순간마다 단지 ‘API를 어떻게 구현할 것인가’보다 ‘어떤 판단을 언제 내려야 하는가’에 중심을 두고 있다. REST, 오픈API, 게이트웨이, 서비스 메시를 나열하는 것을 넘어, 실제 서비스가 성장하고 바뀌는 과정에서 API가 어떤 역할을 해야 하는지를 단계적으로 설명한다. 특히 API와 API 게이트웨이를 도입하거나, 이미 도입한 이후 ‘이게 맞는 선택이었는가’를 다시 점검해야 하는 팀이라면 이 책의 내용은 충분히 실무적인 도움과 설계의 기준점을 제시해 준다. 오늘날의 IT 시대에 API와 API 게이트웨이를 설계/운영해야 하는 개발 리더, 아키텍트라면 한 번쯤은 봐야 할 이야기가 담긴 책이다. - 공용준 (KT Cloud 클라우드 본부장) |
|
훌륭한 아키텍처의 근간에는 효과적인 API 아키텍처가 있다.
API 아키텍처를 설계하고 구현하여 운영하면서 기술과 시장의 변화에 따라 이 아키텍처를 진화시키는 일은 조직에서 가장 높은 우선순위를 가져야 할 일이다. 최근 몇몇 개발자를 양성하는 교육 과정의 학생들을 가르치고 프로젝트를 멘토링하면서, 견고하고 좋은 서비스를 구축하는 데 필요한 API 설계와 구현에 대해 제대로 된 커리큘럼이 없다는 점을 아쉽게 생각했었다. API 개념에서 시작해 고객 중심으로 API를 설계하는 단계까지 이끌어줄 커리큘럼이 필요했다. 우연한 기회에 리뷰 요청을 받은 이 책은 나의 아쉬움을 충분히 달래고도 남을 만큼 체계적인 내용을 담고 있었다. API 설계를 어떻게 가르칠지 손에 잡히지 않는 체계를 고민하느라 꽤 많은 시간을 보냈는데, 이 책의 저자들이 추상적인 개념을 실세계에 적용할 수 있는 API 설계와 구현의 경험적인 프레임워크를 체계적으로 풀어나간 흐름에서 앞으로 나의 멘토링이나 수업 커리큘럼 설계에 중요한 힌트를 얻었다. 이 책에서 사용한 ‘컨퍼런스 시스템’이라는 시나리오와 간결한 C4 다이어그램은 기술적 내용에 대한 독자들의 이해도를 점진적으로 높이면서 명확한 개념을 전달하는 도구로 매우 훌륭했다. API 아키텍처가 전혀 반영되지 않은 레거시 컨퍼런스 시스템을 API 주도 아키텍처로 마이그레이션하는 과정과 함께, 각 과정에 병행해 기술적 백그라운드를 소개하는 이 책의 전개방식은 이제 막 API 설계에 관심을 갖게 되었거나 현업에서 관련 업무를 수행하고 있는 많은 독자에게 큰 도움이 될 것이다. - 김도균 (마이크로소프트 MVP, 공인 애저(Azure) 트레이너) |
|
이 책은 API를 어떻게 구현하는지를 기술적으로 설명하는 데 그치지 않고, 다양한 기술적 선택지를 제시하며 왜, 언제, 어떤 맥락에서 어떤 기술을 선택해야 하는지를 친절히 알려준다. 하나의 기술이 항상 정답이 될 수 없다는 점을 전제로, 구체적인 사례를 통해 상황에 맞는 기술을 어떻게 평가하고 적용할 수 있는지도 보여준다. 또한 API를 중심으로 설계, 트래픽 관리, 보안, 클라우드 이전까지 단계적으로 확장해 나가는 구성 역시 이 책의 장점이다.
거의 모든 개발 환경에서 API를 다루는 개발자와 아키텍트라면 이 책을 외면하기 어려울 것이다. - 김명신 (42dot 클라우드&인프라 그룹) |
|
바이브 코딩 시대가 왔다고 하지만 그건 결국 분산 컴퓨팅의 유산이며, 분산 컴퓨팅의 핵심은 API입니다. 아마 API를 찾아서 골라 쓰는 개발자는 없을 것입니다. 그러나 대규모 시스템을 구성하고 오래도록 지속되는 시스템을 내 손으로 책임지고자 한다면 API에 대해 더 많은 지식과 경험이 필요할 것입니다.
인공지능 시대가 본격적으로 전개될수록 클라우드 기반에서 작동하는 API의 위치는 더욱 견고해질 것입니다. API에 대한 방대한 지식을 빠르게 따라가고자 한다면, 이 책은 분명 훌륭한 선택이 될 것이라 믿습니다. - 안영회 (베터코드 대표) |
|
백엔드 API 개발자들은 농담을 섞어서 “우리는 JSON 상하차를 하지”라고 말하곤 한다. 단순 작업이라는 자조적인 비유이지만 잠시 더 생각해 보면 상하차 작업이 그저 단순해 보여도 실제로는 그렇지 않은 것처럼, API 개발도 실제로는 단순하지 않다는 점에서 괜찮은 비유라는 생각도 든다. 더욱이 상하차 작업도 숙련자가 하면 더 안전하게, 더 많이, 더 빠르게 싣고 내릴 수 있는 것처럼, API도 숙련자가 만들면 보안성이 높고, 유연하며, 확장성 있고, 복원력 있고, 성능까지 좋고, 사용하기도 좋게 만들 수 있다.
이 책은 언뜻 목차만 보면 굉장히 방대해 보이지만 다양한 사례 중심으로 압축 설명돼 있어 전혀 지겹지 않으며, 무엇보다도 숙련자의 군더더기 없는 깔끔한 번역 덕분에 읽는 데 막힘이 없다. AI 시대, 논리적 노동을 하는 모든 사람의 미래가 불투명하지만 숙련자에게 AI는 위협이 아니라 초고성능 도구가 될 수 있다. 일단 나부터 이 책을 읽고 API 설계/개발/운영 숙련자, API꾼이 돼야겠다. - 오명운 (네이버제트 개발자, 『OpenAPI와 스웨거를 활용한 실전 API 설계』 역자) |