기존 DevOps 플랫폼을 AI 시대에 맞게: 설계와 실천에서 생각해 본 것

AI가 코드를 작성하는 장면이 늘어나면서, 개발 플랫폼에도 새로운 질문들이 생겨납니다. 코드가 IDE나 터미널, 샌드박스에서 생성되게 되었을 때, 지금까지 사람이 화면을 조작하는 것을 전제로 했던 빌드(build)·배포(deploy)·릴리스(release) 메커니즘은 어떻게 바뀌어야 할까요?

저희는 기존의 프론트엔드 개발 및 배포 플랫폼을 출발점으로 삼아, CLI를 통한 조작, AI 에이전트의 활용, 실행 절차의 개방, 그리고 태스크 중심의 협업에 대해 고민해 왔습니다. 그 과정에서 AI에 대응하는 것은 기존 시스템의 가치를 재검토하는 측면이 있다는 것을 느꼈습니다.

애플리케이션 정보, 권한, 환경, 산출물(artifact), 릴리스 규칙, 실행 이력 등 이러한 축적된 데이터는 AI가 들어와도 계속해서 필요합니다. 변하는 것은 그것들을 누가, 어디서, 어떻게 조합하여 사용하는가입니다.

이 글에서는 사내 제품명이나 개별 업무 정보를 제외하고, 설계 단계에서 고민했던 점과 실천을 통해 생각한 것을 정리했습니다. 기존 개발 기반과 AI를 연결하려는 분들에게 설계에 대한 단서를 제공할 수 있기를 바랍니다.

개발의 진입점이 바뀌면 플랫폼의 전제도 바뀐다

기존의 개발 플랫폼에서는 사람이 애플리케이션을 선택하고, 변경 사항을 등록하며, 코드 버전과 환경을 지정하여 플로우를 시작합니다. 이 플로우는 빌드, 검증 환경으로 배포(deploy)하고, 운영 환경에 릴리스하는 과정을 거치며, 필요한 지점에서 사람의 확인을 요청합니다.

이 형태에는 합리성이 있었습니다. 자주 사용하는 절차를 템플릿으로 관리할 수 있고, 애플리케이션별 차이점도 흡수할 수 있습니다. 개발자는 매번 모든 절차를 조합할 필요가 없고, 플랫폼 측은 실행 이력과 책임 소재를 관리할 수 있습니다.

AI 에이전트가 개발에 참여하게 되면, 작업의 출발점이 넓어집니다. 사용자는 리포지토리를 열어둔 채로 '이 변경 사항을 검증 환경에 배포해 줘'라고 요청합니다. 다른 에이전트가 코드를 생성하고, 그 다음으로 빌드를 요구할 수도 있습니다. Git 이벤트로부터 자동으로 처리를 진행하고 싶을 때도 있습니다.

이러한 진입점에는 플랫폼 화면에서 순서대로 입력했던 정보가 처음부터 갖춰져 있지 않을 수 있습니다. 현재 있는 디렉터리가 어떤 애플리케이션인지, 어떤 커밋(commit)을 사용할 것인지, 어느 환경에 배포할 것인지 등 매번 실제 정보를 가져와 확인해야 합니다.

여기서 기존 플로우를 재검토하면, 두 가지 역할이 중복되어 있었다는 것을 알 수 있습니다. 하나는 이번에 어떤 절차를 선택할지 판단하는 것입니다. 다른 하나는 선택한 절차를 의존 관계에 따라 실행하고 결과를 기록하는 것입니다. 사람이 정형적으로 사용할 때는 하나의 템플릿으로 정리하기 쉽지만, 진입점과 작업의 종류가 늘어날수록 이 분담을 명확히 할 필요가 생깁니다.

AI 대응을 진행하면서 저는 이 분담을 출발점으로 삼게 되었습니다. 기존 능력을 유지하면서 판단과 조합 방식을 어디까지 개방할 수 있을지. 그 경계를 생각하는 것이 개별 AI 기능을 추가하는 것보다 나중 설계에 더 도움이 됩니다.

CLI화로 보인 것은 조작이 아니라 정보의 설계였다

첫 번째 접점으로서 CLI(Command Line Interface)는 다루기 쉬운 방법입니다. 사람과 에이전트 모두 같은 커맨드를 사용할 수 있고, 기존 업무 API나 플로우를 그대로 활용할 수 있습니다. 에이전트를 위한 Skill에는 조작 순서, 필요한 입력, 결과 읽는 방법을 정리할 수 있습니다.

하지만 화면상의 버튼을 명령어로 대체하는 것만으로는, 에이전트가 작업을 계속하기에 충분한 정보가 부족합니다. 사람은 화면의 색상이나 설명문, 옆 항목에서 상태를 읽어낼 수 있습니다. 커맨드를 호출하는 쪽에는 이를 명시적으로 반환해야 합니다.

예를 들어 '배포를 시작했습니다'라는 응답만으로는 대상 애플리케이션도, 실제로 사용한 코드도, 그 이후의 상태도 알 수 없습니다. '성공했습니다'라는 응답 역시 요청을 받은 것인지, 배포가 끝난 것인지, 애플리케이션이 이용 가능해진 것인지에 따라 의미가 다릅니다.

따라서 하나의 조작을 세 가지 능력으로 보게 되었습니다.

• 실행 전 문의: 대상, 환경, 현재 상태, 필요한 조건을 가져옵니다. -
  조작 시작: 확정된 입력으로 처리를 시작하고 추적에 사용할 식별자를 반환합니다. -
  결과 문의: 상태, 로그, 산출물, 기다리는 조건을 가져옵니다.

이 세 가지가 갖춰지면, 에이전트는 실제 결과를 사용하여 다음 판단을 할 수 있습니다. 실행 중이라면 기다립니다. 확인이 필요하다면 무엇을 확인할지 사용자에게 전달합니다. 실패했다면 대응하는 로그를 읽습니다. 사람도 같은 실행 기록을 열어보면 거기서부터 작업을 이어받을 수 있습니다.

타임아웃 처리에도 같은 사고방식이 필요합니다. 호출이 타임아웃하더라도 상대 측에서 처리가 시작되고 있을 수 있습니다. 응답을 받지 못했다는 이유만으로 동일한 작업을 실행하면 중복 실행을 일으킬 수 있습니다. 발급된 요청이나 실행 상태를 문의하여 무엇이 발생했는지 확인할 경로가 필요합니다.

CLI 설계를 통해, 기계용 인터페이스에는 조작 방법만큼이나 상태 설명이 필요하다는 것을 알게 되었습니다. 호출 측에서 알고 싶은 것은 다음에 사용할 명령어뿐만이 아닙니다. 지금 어디까지 진행되었고, 무엇을 파악했으며, 무엇은 아직 결정되지 않았는지입니다. 그 정보가 지속적으로 작업을 진행하기 위한 재료가 됩니다.

모델의 판단과, 길게 이어지는 실행을 분리하다

CLI를 통해 기존 플로우를 호출할 수 있게 되면, 다음으로는 절차 자체를 조합하고 싶어집니다. 빌드 전에 자체 검증을 넣거나, 여러 애플리케이션을 순차적으로 릴리스하거나, 실패한 부분만 조사하여 그 결과에 따라 계속 진행하는 식입니다. 고정된 템플릿만으로는 표현하기 어려운 요구사항이 나옵니다.

여기서 에이전트에게 모든 절차를 순차적으로 관리하게 하는 방법도 생각해 볼 수 있습니다. 하지만 릴리스에는 모델이 매번 판단할 필요가 없는 시간이 많습니다. 빌드 완료를 기다리거나, 승인을 기다리거나, 단계적인 공개 후 일정 시간 관측하는 등의 처리가 그렇습니다.

이러한 대기(waiting)를 대화의 지속성에 의존하게 되면, 브라우저를 닫았을 때나 에이전트 실행이 끊겼을 때 작업 상태가 모호해집니다. 재개된 모델에게 대화에서 실행 상황을 추측하게 만드는 결과로 이어지기도 합니다.

그래서 모델이 수행하는 판단과 실행 기반(execution foundation)이 유지하는 처리를 분리합니다. 모델은 목표를 정리하고, 정보를 얻고, 절차를 선택하며, 예외를 분석합니다. 확정된 절차는 명시적인 실행 계획(execution plan)으로 전달하고, 의존 관계, 대기, 상태 전이는 실행 기반이 관리합니다. 새로운 결과나 요구사항 변경이 생기면 다시 모델이 판단합니다.

실행 계획에는 YAML을 사용할 수 있지만, 형식 자체가 중심은 아닙니다. 중요한 것은 이번에 무엇을 실행할지가 대화에서 추출되고 있다는 점입니다. 입력(input), 대상(target), 의존 관계(dependency), 산출물 전달(deliverable handover)이 보이면, 실행 전에 확인하고 나중에 문제를 조사하는 것도 가능합니다.

예를 들어

절차의 자유도와, 플랫폼의 책임을 분리하기

배포(deploy)나 릴리스에서는 한 단계 더의 분리가 필요했습니다. 사용자는 절차를 조정하고 싶어 하는 반면, 애플리케이션, 산출물, 동시 실행, 복구에 관한 관리는 지속적으로 플랫폼이 맡고 싶기 때문입니다.

그래서 외부와 내부의 두 가지 파이프라인을 사용합니다. 외부(outer)는 '빌드하여 배포하기', '운영 환경에 릴리스하기', '롤백하기' 같은 요구사항을 나타냅니다. 영역 플랫폼은 이 요구사항을 받아 배포 기록(deployment record)을 만들고, 대상을 확정하며 산출물을 결정한 후 내부 파이프라인을 시작합니다. 내부에는 실제 배포, 단계적 공개(phased rollout), 필요한 확인 등의 절차를 배치합니다.

내부의 절차를 코드와 함께 관리하면 애플리케이션별 변경 사항을 검토할 수 있습니다. 한편, 권한이나 릴리스 제약은 실제로 업무 작업을 수행하는 쪽에서 계속 확인합니다. 절차를 변경할 수 있다는 것과 임의의 작업이 허용된다는 것은 별개의 설계 사항입니다.

이 구성에서 중요한 것이 배포 기록의 역할입니다. 대상, 산출물, 실행 중인 처리, 결과를 연결하는 기록이 있다면 사람도 에이전트도 같은 상태를 참조할 수 있습니다. 외부 처리 역시 그 기록과 내부의 결과에 따라 진행 상황을 추적합니다. 요구사항 접수만으로 외부 처리를 완료하게 되면, 사용자의 인식과 실제 릴리스 상태가 어긋나게 됩니다.

업무별 공개 순서는 조정할 수 있습니다. 애플리케이션의 상태와 작업 책임은 플랫폼이 관리합니다. 이러한 분담을 통해 절차를 개방하면서도 기존의 운영 능력을 활용할 수 있습니다.

대규모 리포지토리에서는, 애플리케이션 식별이 먼저 필요하다

하나의 리포지토리에 여러 애플리케이션이 있는 경우, 에이전트가 리포지토리를 인식했다는 것만으로는 대상을 결정할 수 없습니다. 같은 코드를 공유하고 있더라도 빌드 시작 디렉터리, 산출물, 배포처는 다릅니다.

따라서 애플리케이션의 식별 정보를 소스 경로(source path), 빌드 정의(build definition), 산출물 유형(artifact type), 대상 환경과 연결합니다. 이 대응 관계를 빌드부터 배포까지 계승하고, 각 단계에서 개별적으로 추측하여 재설정하지 않도록 합니다.

메타데이터는 에이전트가 작업 대상을 선택하는 데 중요한 입력값입니다. 다만, 실제 권한이나 환경 상태는 업무 시스템에 문의해야 합니다. 리포지토리에 기록된 선언과 현재 실행 가능한 것을 조합하여 판단하는 설계가 필요합니다.

이러한 연결을 통해 암묵적인 전제(implicit assumption)를 명시적인 입력값으로 바꾸는 것이 AI 대응의 상당 부분을 차지한다고 느꼈습니다. 기존 처리를 사용하기 쉽게 만드는 작업은 사람을 위한 자동화나 API 활용에도 그대로 도움이 됩니다.

대화가 지속되는 것과, 업무가 지속되는 것은 별개로 생각하기

단독 에이전트만으로 여러 작업을 진행할 수 있게 되면, 다음으로는 팀의 업무가 보입니다. 프론트엔드와 백엔드가 병렬로 작업합니다. 도중에 사양이 변경됩니다. 담당자가 교체됩니다. 사용자가 한 번 떠났다가 나중에 계속 확인합니다. 대화 안에서만 관리하기에는 정보의 수명이 길어집니다.

앞으로의 플랫폼을 구상하는 데 있어, 저는 업무를 대화와는 별개의 단위로 가져가는 것이 필요하다고 생각합니다. 하나의 딜리버리(delivery)에 목표, 태스크, 계획, 대화, 코드, 실행, 확인 결과를 연결합니다. 대화는 그 업무를 진행하는 진입점(entry point)이 되고, 업무 상태는 지속적으로 참조될 수 있도록 합니다.

태스크, 대화, 에이전트의 실행을 분리하기

태스크에는 책임 범위와 완료 조건이 있습니다. 대화에는 그 태스크에 대한 논의와 조정이 있습니다. 에이전트의 한 번의 실행에는 그 시점에 읽어 들인 입력과 출력이 있습니다. 이들을 분리하면 '에이전트의 응답이 끝났다'는 것과 '업무가 끝났다'는 것을 혼동하기 어려워집니다.

코드를 생성하여 응답한 후에도 빌드나 검증(validation)이 남아 있을 수 있습니다. 배포가 성공했더라도, 목적의 기능을 이용할 수 있는지는 별도로 확인해야 합니다. 태스크의 완료는 그 태스크가 요구하는 결과로부터 판단하는 것이 자연스럽습니다.

전체를 다루는 대화와 개별 작업을 다루는 대화도 이 단위에 따라 연결합니다. 전체 대화에서는 목표나 작업 간의 관계를 다루고, 개별 대화에서는 담당 범위를 진행합니다. 사용자는 전체 진행 상황을 보면서 필요한 곳으로 들어가 구체적인 조정을 할 수 있습니다.

분담 관계와, 실행의 의존 관계는 다르다

태스크의 부모-자식 관계(parent-child relationship)는 작업의 분담과 결과의 집합을 나타냅니다. 반면, 실행의 의존 관계는 '다음 작업에 무엇이 필요한가'를 나타냅니다.

예를 들어, API 사양이 합의되면 프론트엔드와 백엔드는 각각 작업을 시작할 수 있습니다. 통합 테스트(integration test)를 시작하려면 양측에서 지정된 버전이 같은 환경에서 사용 가능해야 합니다. 의존하는 것은 다른 대화가 끝났다는 사실이 아니라, 특정 출력이나 상태입니다.

따라서 의존 관계는 필요한 결과물이나 버전, 확인 결과로 표현하고 싶습니다. 이렇게 하면 태스크 전체의 종료를 기다리지 않고 다음으로 진행할 수 있는 경우도, 반대로 이미 종료되었더라도 조건이 부족한 경우도 처리할 수 있습니다.

중간 변경을 계획의 변경으로 다루기

긴 작업에서는 중간 변경이 예외가 아닙니다. 사양 추가나 인터페이스 수정 같은 것을 대화에 문장 하나를 추가하는 것만으로 전달하면, 어떤 실행이 그 변경을 채택했는지 알 수 없게 됩니다.

변경은 계획의 새로운 버전으로 기록하고, 영향을 받는 태스크에 반영합니다. 이때는 미개시 처리, 실행 중인 처리, 완료된 결과를 나누어 생각해야 합니다.

• 미개시 처리는 새로운 입력과 조건을 사용합니다.
• 실행 중인 처리는 시작 시점의 입력을 유지하며, 필요에 따라 취소나 새로운 실행을 다룹니다.
• 완료된 결과는 새로운 조건에서도 사용할 수 있는지 확인합니다.

이미 작동하고 있는 빌드의 파라미터를 대화 업데이트만으로 조용히 교체해서는 안 됩니다. 또한, 변경이 생겼다고 해서 관계없는 결과물까지 다시 만들 필요도 없습니다. 무엇이 바뀌었고 어떤 결과에 영향을 미치는지 기록할 수 있다면, 지속과 재시작의 범위를 판단할 수 있습니다.

대화의 편리성과 업무의 연속성을 양립하려면, 이처럼 사소한 모델이 필요합니다. 채팅 기록을 길게 저장하는 것만으로는 얻을 수 없는, 플랫폼 측의 역할입니다.

진단부터 복구까지, 원래 문제와의 연결고리 유지하기

개발의 연속만을 다루는 것이 아니라, 문의나 장애 조사에도 AI가 참여합니다. 로그를 읽거나, 실패한 단계를 확인하거나, 관련 설정을 조사하는 것입니다. 여기에서도 대화의 답변과 업무상의 결과를 분리해서 생각할 필요가 있습니다.

원인을 설명했다는 것, 복구 조치를 실행했다는 것, 원래 문제가 해소되었다는 것은 각각 다릅니다. 답변을 할 수 있어도 이용자의 문제가 남아있다면, 그 업무는 아직 계속되고 있는 것입니다.

진단은 처음부터 일반적인 개발 플로우에 통합하기보다는, 문제, 증거, 조사 경위, 복구 판단 조건이라는 것을 가진 하나의 작업으로 다루는 것이 더 자연스럽다고 생각합니다. 문의 답변만으로 끝나는 경우도 있습니다. 조건과 권한이 갖춰지면 운영상의 조치로 해결할 수도 있습니다. 코드 변경이 필요하다면, 거기서 개발 태스크와 연관시킵니다.

개발 태스크가 완료된 후에는, 원래 문제로 돌아가 결과를 확인합니다. 예를 들어, 수정된 코드가 릴리스된 것과 문의에서 보고된 동작이 고쳐진 것을 연결하여 확인하는 것입니다. 이 왕복 과정이 남아있다면, 수정과 이용자의 문제가 도중에 분리되지 않습니다.

결과의 통지 역시 독립적인 상태로 다룰 수 있습니다. 복구는 끝났지만 통지가 도착하지 않았다면, 다시 시작하는 것은 통지입니다. 통지가 전송되었다는 이유만으로 복구까지 완료했다고 판단하는 것도 피할 수 있습니다.

이러한 생각은 에이전트의 권한에도 연결됩니다. 로그나 설정을 읽을 수 있는 것과 변경할 수 있는 것을 분리합니다. 조치에는 요청한 사람, 대상, 허가된 범위를 연관시킵니다. 경험이나 과거 기억은 조사 단서가 되지만, 현재 상태와 권한은 실제 시스템에서 확인해야 합니다.

AI가 분석을 돕고, 플랫폼이 상태와 조작의 책임을 갖습니다. 이 분담은 개발부터 운영까지 공통적으로 사용될 수 있는 것이라고 생각합니다.

AI와의 연결을 진행할수록, 플랫폼의 역할이 보이기 시작하다

지금까지 생각해 온 것을 보면, 기존 플랫폼에는 활용 방안을 열 여지가 많다고 느낍니다. 화면이나 고정된 플로우 안에 있는 지식을 문의 가능한 정보, 명시적인 입력, 조합 가능한 업무 능력으로 제공하면 사람도 에이전트도 사용하기 쉬워집니다.

그럴 때 처음부터 모든 개발 작업을 AI에 맡길 필요는 없습니다. 하나의 애플리케이션을 정확히 식별하고, 빌드하고, 검증 환경에 배포하고, 결과를 확인하는. 그 작은 일련의 작업에서도 대상의 모호성, 정보 부족, 대기, 실패, 재개와 같은 설계 과제가 보입니다.

조작의 수를 늘리기 전에, 이 일련의 작업을 계속할 수 있는 형태로 만드는 것. 다음으로, 여러 작업을 계획으로 연결합니다. 게다가 담당자나 대화가 바뀌어도 동일한 업무를 진행할 수 있도록 하는 것입니다. 실천 범위를 넓히면서 필요한 설계를 찾아가는 접근 방식이 적절하다고 생각합니다.

봐야 할 성과도, 커맨드를 몇 번 호출했느냐보다 업무가 어디까지 진행되었는지에 있습니다. 이용자가 결과에 도달했는가. 기다리는 이유를 설명할 수 있는가. 실패한 부분을 추적할 수 있는가. 중간부터 재개할 수 있는가. 이러한 점들은 AI를 사용하지 않는 개발자에게도 가치가 있습니다.

제가 이 작업에서 중요하게 생각하는 것은, 모델이 판단하기 쉬운 정보와 실행을 지속할 수 있는 메커니즘, 두 가지를 모두 갖추는 것입니다. 판단은 유연하더라도, 실행과 결과가 모호하면 긴 프로젝트를 진행하기 어렵습니다. 또한, 실행이 안정적이라 하더라도 사용하기 위한 전제가 화면이나 담당자의 경험에 갇혀 있다면, 새로운 관점에서 활용하기 어렵습니다.

애플리케이션, 산출물, 권한, 환경, 실행 이력, 그리고 업무 목표. 이들을 명확하게 연결하는 것이 AI와 기존 개발 인프라를 연결하는 설계의 핵심이 됩니다. 플랫폼의 축적된 기능을 다음 사용 사례로 확장해 나가는 과정에, AI 시대의 개발 및 배포(Delivery) 인프라를 고민하는 재미가 있다고 생각합니다.

Discussion