수년에서 수 시간으로
요약
과거 Stackery나 AWS Infrastructure Composer가 제공했던 IaC 시각화 기술이 Stripe Projects의 등장으로 새로운 국면을 맞이했습니다. 저자는 Stripe Projects를 통해 프로비저닝된 서비스들의 상태 파일과 환경 변수를 분석하여, 복잡한 분산 시스템의 아키텍처 다이어그램을 자동으로 생성하는 시각화 도구를 개발했습니다.
핵심 포인트
- Stackery와 AWS Infrastructure Composer는 드래그 앤 드롭을 통한 양방향 IaC 시각화 기능을 제공해 왔음
- Stripe Projects를 통해 CLI 기반으로 호스팅, 인증, AI, 데이터베이스 등 다양한 서비스를 빠르게 프로비저닝할 수 있음
- 에이전트가 사용자의 의도를 파악하여 필요한 인프라를 직접 프로비저닝하는 시대가 도래함
- 저자는 .projects/state.json 파일과 환경 변수를 분석하여 서비스 간 연결 관계를 보여주는 시각화 도구를 직접 구현함
제가 "2018년부터 인프라를 시각화해 왔습니다"라고 말하는 것은 자랑이 아니라 실제 사실입니다. 그해 저는 Stackery라는 포틀랜드 기반의 멋진 스타트업에 합류했습니다. 그곳은 코드형 인프라 (IaC, Infrastructure as Code)를 다루며 다음과 같은 아키텍처 다이어그램을 생성했습니다: [IMG:1] 그 비결은 양방향으로 작동한다는 점이었습니다. 리소스를 드래그 앤 드롭하면, 이를 배포할 수 있는 IaC를 얻을 수 있었습니다. 비록 그 스타트업은 2021년 이후로 존재하지 않지만, 실제로 여전히 라이브 에디터를 사용해 볼 수 있습니다 ;) 왜 이런 옛날 이야기를 꺼내는 걸까요? 음, Stackery는 AWS에 인수되었고 (이제는 그곳에 고용된 상태가 아니기에 말할 수 있습니다), AWS Infrastructure Composer (전 Application Composer)가 되었습니다. 이는 코드형 인프라를 가져와 다음과 같은 아키텍처 다이어그램을 생성합니다: [IMG:2] 그리고 이 역시 양방향으로 작동합니다. 리소스를 드래그 앤 드롭하면, 배포 가능한 Cloudformation 템플릿을 얻을 수 있습니다. 하지만 더 중요한 점은, 이것이 서버리스 (Serverless) 서비스를 구성하는 분산 시스템 (Distributed Systems)과 그들이 서로 어떻게 상호작용하는지를 시각적으로 이해할 수 있는 강력한 방법이라는 것입니다.
현대 시대
현재 저는 Stripe에 재직 중인데, 이곳은 클라우드 제공업체가 아니므로 새로운 직장에서 IaC를 시각화할 유스케이스 (Use case)가 없을 것이라고 생각할 수도 있습니다. 지난달 Stripe Projects가 출시되기 전까지는 그것이 사실이었습니다. 하지만 Projects가 출시되면서 갑자기 Stripe CLI가 무엇이든 구축할 수 있는 수단이 되었습니다! Projects를 통해 누구나 Stripe CLI를 사용하여 호스팅, 인증 (Auth), AI, 데이터베이스 등 취미용 또는 실제 애플리케이션에 필요한 거의 모든 것을 제공하는 빠르게 확장되는 제공업체 카탈로그로부터 서비스를 프로비저닝 (Provision)할 수 있습니다. 하지만 더 흔한 경우는, 사용자들이 CLI를 통해 에이전트 (Agent)를 설정하고 "X를 수행하는 앱을 만들어줘"라고 말하는 것입니다. 그러면 에이전트는 이 유스케이스에 데이터베이스가 필요하다는 것을 파악하고, 신이 의도한 대로 CLI에서 직접 이를 프로비저닝할 수 있습니다.
이제 우리는 개발자가 완전히 이해하지 못할 수도 있는, 점점 더 복잡해지는 다중 서비스로 구성된 애플리케이션을 갖게 되었습니다. #believeinserverless 시대에 주변에 계신 분들에게 익숙한 상황인가요?
프로젝트 시각화 (Visualizing Projects)
최근 저는 팀을 위한 전사(transcription) 앱을 구축하기 위해 Projects를 사용했으며, 그 과정에 대해 여기 [From init to deploy]에 작성했습니다. 해당 애플리케이션은 상당히 단순하고 Vercel과 OpenRouter라는 단 두 개의 프로바이더 (provider)만 사용함에도 불구하고, 프로젝트에 기여하고 싶어 하는 팀원들에게 시각화 자료가 유용할 것이라고 생각했습니다. 그래서 약간 광기 어린 어느 오후 한나절 동안 stripe-projects-visualizer 앱을 만들었습니다. 이 앱은 프로비저닝된 서비스의 신뢰할 수 있는 원천 (source of truth)인 프로젝트의 .projects/state.json 파일을 살펴보고, 코드베이스 전반에서 프로바이더 환경 변수 (environment variables)가 어떻게 사용되는지 분석하여, 프로비저닝된 서비스들이 어떻게 연결되고 데이터가 어떻게 흐르는지를 보여주는 아키텍처 다이어그램 (architecture diagram)을 생성합니다. 예를 들어, 여기 제 전사 앱을 위해 생성된 다이어그램이 있습니다: [IMG:1]
수년에서 수 시간으로
이 도구가 멋지고 유용하냐고요? 물론 그렇다고 생각하고 싶습니다. 기능이 부족하냐고요? 당연합니다. 하지만 투입된 시간에 비하면 생각만큼 많지는 않습니다. 한 오후 만에 이 앱을 만들며 얻은 가장 큰 깨달음은 제가 할 수 있었다는 점입니다.
Stackery는 수많은 엔지니어 6명이 이를 구축하고 유지 관리하는 데 아주 오랜 세월이 걸렸습니다. Infrastructure Composer는 엔지니어 5명으로 시작하여 거의 12명과 UX 팀으로 확장되었지만, re:Invent 2022에서 출시된 초기 프리뷰 버전조차 9개월 이상의 집중적인 구축 기간이 필요했습니다. 그 후, 제 이전 팀은 캔버스 (canvas) 부분을 더 이식성 있고 확장 가능하게 재설계(re-architecting)하는 데 또 1년을 보냈습니다. 반면, Stripe Projects Visualizer는 단 한 명의 사람이 한 오후 만에 구축했습니다. 저는 아마 내일이라도 웹 앱 버전을 출시할 수 있을 것입니다. 이것은 제가 8년 전 처해 있었던 상황과는 완전히 다른 패러다임입니다.
8개월 전, Infrastructure Composer의 기반이 되는 캔버스 기술 (canvas tech)을 개선하기 위해 Kiro와 Claude Code를 사용하며 여전히 서툴게 헤매고 있었던 때와는 완전히 다릅니다. 저는 이 포스트의 제목을 "수년에서 수 시간으로의 공포스러운 현실"이라고 지을 뻔했습니다. 왜냐하면 어떤 측면에서는 (제가 반드시 고용 상태를 유지하고 싶은 바로 그 측면에서), 이것은 공포스럽기 때문입니다. 보안 (Security) 측면 또한 마찬가지입니다. 비록 저의 적대적 에이전트 (adversarial agent)가 제 저장소 (repo)에 보안 취약점이 없다고 안심시켜 주긴 하지만 말입니다 (휴!). 하지만 이것은 또한 흥미진진한 일이기도 합니다. 수년이 걸렸거나 아예 시작조차 못 했을 프로젝트들이, 이제는 팀이 다듬고 유지 관리할 수 있는 거친 형태(rough state)로라도 존재할 기회를 얻었기 때문입니다. 그러니 저는 이 공포스러울 정도로 멋진 여정에 함께 가보려 합니다. 여러분도 함께하고 싶다면, Stripe Projects를 사용해 보세요: brew install stripe/stripe-cli/stripe && stripe plugin install projects 를 실행한 다음, 다음 명령어로 여러분의 공포스러울 정도로 멋진 창작물을 시각화해 보세요: npx stripe-projects-visualizer visualize. 여러분이 무엇을 만들어낼지 기대하겠습니다!
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기