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

어느새 큰아이가 대학교 졸업반이 됩니다. 오랜만에 저녁 식사를 하다가 문득 아이에게 말했습니다.

"직장이란 너의 꿈, 너의 사업을 가지기 위한 시드 머니를 확보하는 곳 같아"

예전 블리자드를 다닐 때 일입니다. 블리자드에서는 팀 리더와 원-온-원을 주기적으로 하는데, 주로 캠퍼스 주변을 산책하면서 여러 이야기를 나눴습니다. 그때 받은 질문 중 하나가 꿈이 뭐냐는 것이었습니다. 꿈? 글쎄요. 저는 정말 그냥 멋진 중년의 개발자가 되는 것이 꿈이었습니다. 그런데 자신의 꿈은 로스앤젤레스 근처에 빵집을 차리는 것이라는 겁니다. 의외였죠. 그 팀 리더는 개발도 잘하는 멋진 친구였거든요. 제가 물었죠.

"그러면 왜 개발을 하고 있어?"

그 친구는 자신이 개발자로 근무하는 이유가 빵집을 차리기 위한 시드 머니를  마련하기 위한 것이라고 하더라구요. 약간의 놀라움과 함께 그날의 원-온-원은 그 렇게 지나갔습니다.

같은 팀 동료였던 Sam은 UX 기획자였습니다. 그의 책상에는 두꺼운 책들이 많이 있었습니다. 알고보니 항공기 조종사 교재더라구요. Sam은 기장이 되고 싶었지만, 워낙 교육과정이 비싸다 보니 그걸 벌기 위해서 직장을 다니는 것이었습니다. 결국 Sam은 몇년 더 근무하고 블리자드를 그만두고 기장이 되었습니다. 처음에는 화물기를 운행하다가 몇년전 드디어 여객기 기장이 되었습니다.

이제 자타공인 중년의 나이를 먹다보니 여러 생각이 듭니다. 특히 AI의 발전 속도를 몸으로 체감하는 산업분야에 일하다 보니 직장이라는 것, 현재의 직장 구조가 언제까지 유지될 것인가하는 의문이 들 때도 있습니다. 그러다가 예전 직장에서의 일이 생각나면서 진짜 나의 꿈은 무엇인가라는 생각을 해 봅니다.

제가 스스로에게 아쉬워하는 부분은 중년의 개발자는 되었는데, 뭘 만들지 더 명확하게 했어야 하지 않았나 하는 것입니다. 동료들에게 개발은 진짜 꿈을 향한 수단이었는데, 저는 개발자가 되는 것 자체가 꿈이었습니다. 기술을 익히고 아키텍처를 설계하는 과정이 재미있고 즐거웠습니다. 하지만 막상 중년의 개발자가 되고 나니, 그 때 동료들이 빵집 사장님과 비행기 기장이라는 명확한 목적지를 가졌던 것처럼, 나 또한 소프트웨어 개발이라는 수단을 가지고 무엇을 향해 갔어야 할 지를 명확히 했었어야 하는건가 하는 아쉬움이 생깁니다.

AI의 등장으로 예전보다 훨씬 더 많은 것을 쉽게 할 수 있게 된 요즘, 다양한 언어와 여러가지 아키텍처를 배우는데 집중했던 제가 이따끔씩 멍해질 때가 있습니다. 소프트웨어 개발 기술로 무언가를 구현함에 있어 존재했던 여러 장벽은 AI 덕분에 낮아졌는데, 정작 이 기술로 무엇을 만들어야 할까라는 질문에 대한 답을 여전히 찾고 있기 때문입니다. How보다 What이 좀 더 중요한 시대가 된 것이죠. 제가  멍한 느낌이 들었던 이유도 이제는 '어떤 가치를 만들것인가'라는 본질적인 질문을 마주했기 때문일 것입니다.

그래서 요즘은 제가 뭘 만들고 싶은 것인지에 대해 예전보다 훨씬 많이 고민하는 시간을 가져봅니다. 

여러분의 꿈은 뭔가요?