neozest : neo+zest

관점은 세계를 만들고, 세계와 세계가 만나는 곳에는 경계가 생긴다. 정보는 그 경계를 통해 이동하고, 많은 동작은 바로 그 접점에서 일어난다. 그 세계가 우리가 만든 세계였던 때도 있고, 전혀 알지 못했던 세계를 만나게 되는 때도 있었다. 개발자들은 이렇게 살아 움직이는 경계를 API라고 부른다. 이번에 읽은 책, 책만 출판사에서 나온 <모던 API 아키텍처 설계 전략>을 읽은 후 처음 머리에 떠오른 생각이다.

책의 원제는 Mastering API architecture인데, 제목처럼 API를 중심에 두고, 개발자(생산자/소비자)의 관점, 인프라 엔지니어의 관점, 운영의 관점, 보안의 관점, 아키텍처의 관점으로 나눠서 이야기를 풀고 있다. 자신의 주된 역할을 중점적으로 읽되, 다른 역할의 이야기를 훑어가면서 다른 입장도 이해할 수 있는 계기가 되어 좋았다.

API는 결국 우리가 만들려는 세계(시스템/서비스)의 추상화가 표현된 방식이라 생각한다. 그래서 오히려 다양한 API 설계 방식을 통해 어떤 식으로 바라본 세계인지, 어떤 것이 자주 변하고 어떤 것이 덜 바뀌는지에 따라 생각의 흐름이 달라졌음을 역으로 생각하게 되었다. 예를 들어 리소스를 중심으로 바라보는 관점이 REST를 낳고, 같은 언어(스키마)로 생각을 나눠야 한다는 관점에서 gRPC가 등장했다.한편으로는 수레바퀴의 끊임없는 재발명처럼 여겨지기도 했지만...

이런 API의 지속적인 변화는 어쩔 수 없이 존재하는데, 이런 변화를 만드는 동력이 기술뿐만 아니라 비즈니스 요구사항과 규제 등도 있다는 점을 저자가 이야기하는 게 좋았다. 사실 하나의 관점으로 변화를 설명하기엔 참 어렵다는 생각이 든다.

책 내용은 괜찮은데, 부분 부분 글 표현이 좀 더 매끄러웠으면 좋았겠다는 아쉬움은 있었다.

예를 들어 p.57에서 "기존의 레거시 시스템 상위에 그래프QL을 적용해 복잡도를 제거할 수 있는 퍼사드로 사용하는 것도 가능하지만, 잘 설계된 API 상위에 그래프QL을 적용한다는 것은 퍼사드를 쉽게 구현하고 유지할 수 있음을 의미한다. 그래프QL은 보완적인 기술로 생각하여 API를 설계하고 구현할 때 함께 고려해야 한다. 또한 전체 API 생태계를 구현하는 완전한 방법으로 바라봐도 무방하다."라는 문단이 있다. 내가 이해한 바로는, 이 문단은 기존의 레거시 시스템 위에 그래프QL을 적용하는 퍼사드 구조로 복잡도를 감출 수 있는데, 잘 설계된 API라면 그 위에 그래프QL을 적용하여 퍼사드를 구현하고 유지하는 것이 쉬운 경우가 많다는 점, 그리고  API를 설계하고 구현할 때 그래프QL을 보완적인 기술로 생각할 수도 있지만, 전체 API 생태계를 구현하기 위한 완전한 관점으로 볼 수 있다는 점으로 이해했다. 다만 한 번에 이렇게 이해되지 않아서 조금 고민의 시간을 가졌다.

배포(deployment)와 릴리즈(release)를 따로 구분하자는 소트웍스의 주장을 자세히 설명해 준 섹션에서 CI/CD에 대해 또 다른 관점을 얻었다. 배포와 릴리즈의 관점에 따라 배포 및 기능 릴리즈의 프로세스와 구조, 방식에 차이가 날 수밖에 없겠다. 두 개념을 나눠서 프로세스를 설계하는 것이 맞겠다는 깨달음을 얻었다.

결국 API 아키텍처는 단순한 엔드포인트를 나누는 문제가 아니라 구축하는 시스템이 외부 세계와 어떤 방식으로 관계를 맺을 것인지를 설계하는 일이다. 이 책은 그 관계를 개발, 운영, 인프라, 보안, 비즈니스 변화의 관점에서 훑어보는 그런 책이다.

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

개인의 일상사에 AI 에이전트 바람을 일으킨 오픈클로. 올해 1월말에  SNS나 인플루언서들을 통해 엄청난 바이럴을 일으키더니, 이 사용법을 다룬 책이 나왔다. 알려진지  얼마 지나지 않았는데도 한빛 말고도 몇 군데 출판사에서 관련 실습서가 출간되었다. 참 빠른 대응이다. 이런걸 보면 오픈클로를 비롯한 개인 에이전트에 대한 세상의 높은 관심도를 알 수 있다. (업계 1인으로 참 재미있으면서도 기술 확산 속도에서 FOMO를 느끼게 된다.)

오픈클로를 처음 접했을 때 기존 LLM 기반 AI 도구들과 달리 개인의 워크플로에 깊숙하게 개입한다는 점에서 실험적이면서 재미있는 시도라는 생각도 들었지만 로컬 환경 접근 권한과 자동 실행 구조에 따른 보안 문제도 두렵고(정확히는 어디까지 AI에게 믿고 맡길 수 있을까라는 위임의 문제), 사실 이게 맞는 방향인가에 대한 고민도 하던차라 바로 사용해보지 않았는데(이런 걸 보면 나는 즉시 도입보다는 검증 이후 적용하는 성격에 가깝다.), 서비스형 오픈 클로도 나오고 보안 문제도 점차 하나씩 해결되어 가고 있고 활용 사례 면에서도 어느정도 모범 답안들이 나온 것 같아서 직접 시도하기 위해 책과 동영상을 보고 있다.

중국 선전에서 오픈클로 설치 행사까지 열렸다고도 하고 오픈 클로 실행을 위해 맥미니를 기꺼이 구매한다고 한다. 주변에서 오픈클로를 사용해 보는 경우가 많다. 그 과정에서 도움 요청을 받는다. 오픈클로를 사용하려면 터미널환경을 사용해야 하는데, 사내에서 AI를 도입했을 때 나름 AI를 잘쓰던 동료도 클로드 코드나 코덱스 사용을 주저하는 이유로 터미널만 가면 뭘해야할지 모르겠다고 말했던 기억이 났다. 엔지니어가 아닌 지인들을 보면 터미널 자체를  여는 것 조차 여전히 어려워 한다. 이 책이 그런 분에게 도움이 될 것 같다.

이 책은 오픈클로의 설치부터 기본적인 사용법까지 매우 쉽게 조분조분 설명한다. 물론 개발자인 나에게는 책에서 다룬 설치 및 사용법 설명이 다소 기초적인 수준에 머물러 있는 수준이다. 오픈클로는 개발자보다는 일상생활에서 AI비서를 두는 효과가 있으니 개발업무보다는 일상 업무 자동화에 적합한 도구다. 그렇게 보면 엔지니어 직무가 아닌, 터미널 환경에 부담을 느끼시는 분들에게는 유용한 내용이라 생각된다. 

AI 도구들의 사용을 조금씩 늘여가다 보면 여전히  편리함과 동시에 어떤 식으로 접근해 가는 것이 나의 생산성 및 사고 체계 발전에 도움이 되는가라는 방향성에 대해 고민하게 되는데, 책의 뒷부분에서 저자분이 적은 내용에 공감이 많이 되었다. 개발 업무 이외의 업무에 오픈클로를 비롯한 다른 AI 에이전트를 어느 정도까지  적용할 수 있을지 추가로 검증을 해볼 필요가 있을 것 같다. 개인용 생산성 향상 인프라로 발전할 가능성은 충분해 보인다.

책을 읽고 난 후 관련 동영상을 찾아봤는데, 오픈클로를 만든 피터 스테인버그의 동영상이 눈에 띄어 함께 소개해 본다. 하나는 TED에서 발표한 내용이고, 또하나는  AI Engineer 컨퍼런스에서도 발표한 내용이다.