소프트웨어 엔지니어링 개선을 위한 AI 프로그래밍 에이전트 활용 5가지 실천법

AI 프로그래밍 에이전트는 소프트웨어 팀이 단순한 코드 작성 이상의 아키텍처 문제를 해결하도록 도울 수 있지만, 그 유용성은 팀이 정의하는 목표와 제약 조건의 명확성에 달려 있다. Pierre Pureur, Kurt Bittner, Todd Miller가 작성하고 Daniel Bryant가 검토한 InfoQ 게재 글은 에이전트에 기능 요구 사항만 제공한다고 해서 확장 가능하고 안전하며 유지 관리하기 쉬운 아키텍처가 보장되는 것은 아니라고 경고한다.

제안된 접근 방식은 성능, 보안, 확장성 같은 품질 속성 요구 사항(Quality Attribute Requirements 또는 QARs)과 에이전트가 고려해야 할 트레이드오프를 명확히 하는 데 기반을 둔다. 또한 이 글은 단순히 코드를 검사하거나 에이전트의 권고를 신뢰하는 대신, 명확한 측정 기준으로 에이전트가 생성한 결과를 테스트해야 한다고 강조한다.

1. 의존하기 전에 레거시 서비스 문서화하기

현대적인 아키텍처는 IMS 데이터베이스를 기반으로 구축된 레거시 시스템에서 보험 증서 데이터를 검색하는 것과 같은 특정 기능을 수행하는 레거시 서비스에 의존할 수 있다. 문제는 이러한 서비스에 정확한 문서가 부족한 경우가 많아 데이터 흐름을 이해하거나 개발 후반 또는 프로덕션 전환 이후에 나타날 수 있는 논리적·보안적 결함을 발견하기 어렵다는 점이다.

에이전트는 서비스 설계를 도식화하고 데이터 흐름을 문서화한 뒤, 코드를 검사하고 서비스가 이해하거나 유지 관리하기 어려운 경우 수정 또는 리팩터링을 제안할 수 있다. 그러나 이러한 활용이 해당 서비스를 유지할 수 있는지, 아니면 위험 때문에 교체해야 하는지에 대한 인간 엔지니어의 판단 필요성을 없애지는 않는다.

2. 아키텍처 결함 찾기

에이전트에게 아키텍처 표준 위반, 품질이 저하된 프로그래밍 관행 또는 리팩터링이 필요한 부분을 찾도록 지시할 수 있다. 검사 사례로는 API 설계, 복잡하거나 안전하지 않거나 비효율적인 인터페이스, 도메인 주도 설계(DDD) 경계 위반 등이 있다.

이 글은 에이전트가 대개 많은 개선점을 찾아낼 것이므로, 팀은 중요한 문제와 가치가 낮은 제안을 구분해야 한다고 지적한다. 엔지니어가 필요한 기능을 설명하는 데 그치지 않고 측정 가능한 목표, 알려진 대안, 명확한 트레이드오프를 제시할 때 결과의 품질이 향상된다.

3. 에이전트를 격리한 보안 감사

에이전트는 데이터 흐름을 도식화하고, 위험도가 높은 파일을 식별하며, 복잡한 논리적 결함을 검사하고, 악용 시도를 모방하는 테스트 또는 스크립트를 작성한 다음 발견된 문제에 대한 패치를 제안하는 데 사용할 수 있다. 이 글은 보안 위험을 나타내는 것으로 분류된 npm 패키지를 대상으로 한 실험을 소개한다. 두 패키지는 업데이트했고, 한 패키지는 교체했으며, 다른 한 패키지는 경고가 오탐으로 판단되어 그대로 유지했다.

그러나 이러한 활용에는 명시적인 운영 제약이 필요하다. 에이전트의 접근을 승인된 파일로 제한하고, 데이터베이스 비밀번호와 비밀 정보를 숨기며, 격리된 네트워크에서 테스트를 실행하고, 변경 사항을 병합하기 전에 인간 검토를 의무화해야 한다.

4. 프로토타입을 위한 아키텍처 기반 만들기

에이전트의 속도 덕분에 프로토타입을 빠르게 만들 수 있지만, 아키텍처 목표를 정의하지 않으면 생성된 프로토타입은 임시적이며 적합하지 않을 수 있다. 이 글은 코드 작성 방식, 데이터베이스 설계, 인터페이스, 선호하는 플랫폼과 프레임워크 및 Markdown 형식으로 작성된 QARs를 포함하는 미리 구조화된 애플리케이션을 준비할 것을 제안한다.

GitHub 템플릿을 사용해 애플리케이션의 초기 구조를 표준화하고 팀 표준을 처음부터 포함할 수도 있다. 에이전트에 미리 세부적인 해결책을 강요하기보다는 목표와 제약 조건, 그리고 목표 달성 여부를 검증하는 방법을 설명하는 것이 더 바람직하다.

5. 테스트 가능한 초기 아키텍처 생성하기

이 글은 에이전트를 사용해 최소 실행 가능 아키텍처(Minimum Viable Architectures 또는 MVAs)를 생성할 것을 제안한다. 이는 기능을 증명하는 코드에만 국한되지 않고 QARs를 검증하는 데 필요한 테스트, 테스트 데이터 및 실행 환경도 포함한다. 에이전트는 테스트 도구와 컨테이너 설정을 생성할 수 있지만, 팀은 테스트가 실제로 요구된 속성을 측정하는지 확인해야 한다.

또한 MVA가 아키텍처 변경 시나리오를 수용할 수 있는지도 평가해야 한다. 자동으로 생성된 아키텍처가 발전을 고려해 설계되지 않았다면 확장하는 데 많은 비용이 들 수 있기 때문이다.

실무적으로 무엇이 달라지는가?

이 글의 핵심 메시지는 프로그래밍 에이전트가 코드 생산을 빠르게 만들지만 요구 사항, 제약 조건 및 테스트를 작성하는 일의 중요성을 높인다는 것이다. 코드 작성과 관련된 기술이 사라지는 것은 아니지만, 무엇을 구축해야 하는지, 어느 수준을 허용 가능한 품질로 볼 것인지, 이를 어떻게 측정할 것인지를 정하는 일이 더욱 중요해진다. 따라서 에이전트는 아키텍처 감독을 받는 도구로 다뤄야 하며, 엔지니어링 판단을 대신하는 도구로 보아서는 안 된다.