AI 보조 소프트웨어 개발을 위한 퍼스트 클래스 컨텍스트로서의 아키텍처 모델

AI 보조 소프트웨어 개발을 위한 퍼스트 클래스 컨텍스트로서의 아키텍처 모델

소프트웨어 엔지니어로서, 우리는 지난 수십 년 동안 아키텍처 다이어그램을 개발 산출물(artefacts)이라기보다는 문서로 취급해 왔습니다.

우리는 시스템을 설계하고, 충분히 절제력이 있다면 아키텍처 다이어그램을 생성한 뒤 개발을 시작합니다. 코드가 진화함에 따라 아키텍처도 변하며, 결국 다이어그램은 최신 상태를 유지하지 못하게 됩니다. 우리 모두 이것이 이상적이지 않다는 것을 알고 있었지만, 인간만이 소프트웨어를 작성하던 시절에는 대개 그것으로 충분히 넘어갈 수 있었습니다.

오늘날 소프트웨어는 엔지니어에 의해서만 작성되지 않습니다. 우리에게는 AI 코딩 어시스턴트(AI coding assistants), 바이브 코딩(vibe coding), 그리고 우리를 대신해 구현을 생성하는 점점 더 자율적인 에이전트(autonomous agents)가 있습니다. 이제 질문은 단순히 "우리가 의도한 것을 구축했는가?"가 아니라, "우리의 AI가 클라우드 환경 내부에 어떤 종류의 정글을 만들어냈는지 어떻게 알 수 있는가?"가 되었습니다.

현대의 코딩 어시스턴트들은 주어진 컨텍스트(context)를 기반으로 구현을 생성합니다. 지난 1년 동안 우리는 그러한 컨텍스트를 제공하는 방법으로서 명세 주도 개발(specification-driven development)의 부상을 목격했습니다. SpecKit과 같은 표준과 AWS Kiro와 같은 도구들은 명세가 리포지토리(repository)의 일부가 되도록 장려하며, AI가 임시방편적인 프롬프트(prompts) 대신 구조화된 요구사항을 바탕으로 작업할 수 있게 합니다.

명세(Specifications)는 큰 진전이지만, 시간이 지나면서 저는 리포지토리 곳곳에 흩어져 있는 수십 개의 부분적으로 구현된 명세들을 마주하게 되었습니다. 그것들은 개별 기능들을 충분히 잘 설명하고 있었지만, 저는 그 기능들이 어떻게 서로 맞물려 있는지에 대한 시야를 잃어가고 있었습니다. 요구사항은 있었지만, 아키텍처 컨텍스트(architectural context)가 부족했던 것입니다.

나에게 필요했던 것은 또 다른 다이어그램이 아니었습니다. 컴포넌트(components), 신뢰 경계(trust boundaries), 보안 제어(security controls), 계약(contracts), 그리고 배포 구성(deployment configuration)을 포착하는 아키텍처 모델이 필요했습니다. 그리고 그 모델이 설계 검토(design reviews)나 온보딩(onboarding) 세션 중에만 사용되는 것이 아니라, 전체 소프트웨어 개발 생명주기(software development lifecycle) 동안 유용하게 유지되기를 원했습니다.

그것은 저를 하나의 단순한 질문으로 이끌었습니다.

만약 아키텍처 모델이 사후에 생성되는 문서가 아니라, AI 보조 소프트웨어 개발을 위한 퍼스트 클래스 (First-class) 입력값이 된다면 어떻게 될까요?

완성된 시스템을 설명하는 다이어그램 대신, 아키텍처 모델이 사양 (Specifications), 구현 가이드 (Implementation guidance), 보안 통제 (Security controls) 및 평가 기준 (Evaluation criteria)을 결정론적으로 생성할 수 있다면 어떨까요? 아키텍처는 신뢰할 수 있는 단일 원천 (Source of truth)이 되며, 사양은 별도로 관리되는 것이 아니라 아키텍처로부터 파생됩니다. 모델이 진화함에 따라 사양도 함께 진화합니다.

소프트웨어 팀이 자율 에이전트 (Autonomous agents)와 AI 보조 워크플로우 (AI-assisted workflows)를 도입함에 따라 이는 더욱 설득력을 얻습니다. AI 시스템이 구현 결정을 내릴 것으로 기대된다면, 이들에게는 단순한 소스 코드뿐만 아니라 아키텍처적 의도 (Architectural intent)에 대한 접근 권한이 필요합니다. 아키텍처는 거버넌스 (Governance)의 원천이 되어, 생성된 소프트웨어가 보안 목표, 조직 정책 및 설계 제약 조건과 일치하도록 보장하는 데 도움을 줍니다.

저에게 이것은 아키텍처를 생각하는 방식의 전환입니다. 아키텍처를 단순한 문서로 취급하는 대신, 소프트웨어 인도 (Software delivery) 과정에 능동적으로 참여하는 실행 가능한 지식 (Executable knowledge)으로 취급하기 시작하는 것입니다.

지난 몇 달 동안 저는 iSecureByDesign이라는 프로젝트를 통해 이 아이디어를 실험해 왔습니다. 목표는 단순히 다이어그램을 그리는 것이 아니라, 아키텍처 모델을 요구사항, 통제 항목 및 구현 가이드의 원천으로 취급하는 것입니다. 저는 이를 사용하여 서버리스 애플리케이션 (Serverless applications), LangGraph 기반의 에이전트형 지식 시스템 (Agentic knowledge systems) 및 기본 보안 통제가 내장된 기타 아키텍처들을 모델링했습니다. 구현의 성공 여부는 다른 이들이 판단할 몫이지만, 이 실험을 통해 저는 이곳에 정말로 구체화할 가치가 있는 무언가가 있다는 확신을 얻었습니다.

AI의 능력이 향상됨에 따라, 소프트웨어의 품질은 프롬프트 (Prompts)만으로 결정되지 않을 것이라고 생각합니다. 소프트웨어의 품질은 프롬프트와 함께 우리가 제공하는 아키텍처 지식의 품질에 점점 더 의존하게 될 것입니다.

어쩌면 소프트웨어 아키텍처의 다음 진화는 더 나은 다이어그램을 만드는 것이 아닐지도 모릅니다.

어쩌면 소프트웨어 아키텍처의 다음 진화는 AI 보조 소프트웨어 개발 생명주기 (Software Development Lifecycle, SDLC)에서 아키텍처 모델을 퍼스트 클래스 시민 (First-class citizens)으로 만드는 것일지도 모릅니다.

여러분도 동일한 변화를 목격하고 계신가요, 아니면 AI를 위한 아키텍처 컨텍스트 (Architectural context)를 유지하는 다른 방법을 찾으셨나요?