TL;DR

  • 개발자 프로세스 자동화(Developer Process Automation, DPA)는 반복 가능하고 범위가 좁은 개발 업무를 에이전트가 수행하도록 개발자가 설정하는 방식임.
  • Sentry의 웹훅이나 크론 작업으로 에이전트를 실행해 버그 분류와 수정 PR 작성, 문서 관리 등을 자동화할 수 있음.
  • 유틸리티 사용, 폴더 구조, 테스트 정리처럼 에이전트의 코드 품질을 관리하는 작업도 DPA의 대상임.
  • 대규모 리팩터링이나 에이전트의 자체 개선·자동화 설정은 신뢰하기 어렵고, 결과를 사람이 검토하는 절차가 필요함.
  • DPA를 하나씩 쌓으면 팀의 표준 자동화 기반이 되고, 장기적으로는 사람의 개입을 줄인 소프트웨어 개발 수명 주기로 이어질 수 있음.

개발 업무 자동화의 사례

  • 프로덕션 제품에는 언제 발생할지 모르는 버그가 있을 수 있으며, 오류가 발생하면 알림이 개발자의 호출기로 전달될 수 있음.
  • Sentry 웹훅으로 nori의 클라우드 에이전트를 실행하고 필요한 자격 증명을 제공하면, 에이전트가 원인을 분석하고 수정 PR을 작성해 검토 대기열에 올리는 흐름을 구성할 수 있음.
  • 제품 코드베이스의 문서는 시간이 지나며 실제 제품과 달라질 수 있고, 문서가 낡으면 코드 품질이 저하되고 새 기능 배포가 어려워질 수 있음.
  • 크론 작업으로 에이전트를 정기 실행하고 코드베이스를 점검하게 하는 방식으로 문서를 관리할 수 있음. 웹훅 대신 크론 작업을 사용하고 프롬프트를 조정하는 점 외에는 오류 대응 자동화와 구성이 유사함.

개발자 프로세스 자동화란

  • 비기술 조직에서 이러한 흐름은 여러 출처의 데이터를 연결하고 변환하는 업무 프로세스 자동화(Business Process Automation, BPA)와 유사함. Zapier나 Retool에 익숙한 사람이라면 개념을 쉽게 떠올릴 수 있음.
  • 개발 조직에도 지속적 통합·지속적 배포(CI/CD)처럼 BPA와 비슷한 자동화가 있었지만, 자유 형식 입력을 다루는 개발 업무를 자동화하기는 최근까지 사실상 어려웠음. 코드는 기본적으로 자유 형식 입력이기 때문임.
  • 대형 언어 모델(LLM)과 코딩 에이전트가 많은 엔지니어의 기본 코드 작성 방식이 되면서, 사람이 개입하지 않아도 실행되는 프로세스에 반복적인 엔지니어링 업무를 맡기기가 점점 쉬워짐.
  • 이 범주의 작업을 개발자 프로세스 자동화(DPA)라고 부름. ‘소프트웨어 공장’이나 ‘자율 주행 코드베이스’ 같은 표현보다 과장되지 않고, BPA와 마찬가지로 개발자가 의도적으로 설정하는 프로세스를 가리킴.
  • DPA는 주로 변화가 적은 반복 작업을 단순화하고 표준화하며, 범위가 작고 검토하기 쉬워야 함. 필요하면 쉽게 무시하거나 수정할 수 있어야 함.
  • DPA가 개발자의 필요성을 없애거나 모델에 맹목적으로 프롬프트를 입력해도 된다는 뜻은 아님. BPA가 도입돼도 운영 담당자의 일이 사라지지 않고, 오히려 워크플로를 설정하고 관리하는 것이 업무의 일부인 것과 같은 맥락임.

현재 운영 중인 DPA

  • 클라우드 에이전트로 운영 중인 자동화 사례는 다음과 같음.
  • 자동 버그 분류: 프로덕션 오류가 발생할 때마다 에이전트를 실행해 근본 원인을 분석하고 PR 초안을 작성함.
  • 문서 관리: 며칠에 한 번 에이전트가 내부·외부 문서와 실제 제품이 일치하는지 점검함.
  • 미사용 코드 제거: 일주일에 한 번 코드베이스에서 실행되지 않는 코드 경로를 찾고 제거 PR을 작성함.
  • 기능 플래그 정리: 한동안 프로덕션에 배포된 기능 플래그의 코드 경로를 제거함.

에이전트가 정해진 규칙을 따르도록 관리

  • 에이전트가 작성하는 코드가 늘고 사람이 검토하는 코드가 줄어들면서, 에이전트가 정해진 규칙을 벗어나지 않도록 하는 자동화도 유용함.
  • 유틸리티 정리: 에이전트가 이미 잘 테스트된 공통 유틸리티를 외면하고 같은 코드를 다시 작성하는 경우가 있음. 며칠마다 다른 에이전트가 이를 찾아 기존 유틸리티를 사용하도록 정리함.
  • 폴더 구조 점검: 관찰하지 않으면 에이전트가 코드를 코드베이스의 임의 위치에 조금씩 쌓을 수 있음. 폴더별 요구 사항을 지키지 않는 코드가 있는지 동적으로 표시하는 평가기를 두면 이를 방지할 수 있음.
  • 테스트 정리: AI가 품질이 낮은 테스트를 많이 작성할 수 있으므로, 중복 테스트를 제거하는 점검으로 테스트 스위트 실행에 필요한 연산 자원을 줄일 수 있음.
  • 전체 리팩터링을 자동화하지는 않음. 대신 일주일에 한 번 에이전트가 가능한 리팩터링 목록을 복잡도 순으로 제안하게 함. 대부분은 쓸모없지만, 열 건 중 한 건은 기존 작업을 멈추고 진행할 만큼 유용함.

자동 개선과 사람의 검토

  • 스스로 개선하는 자동화는 대체로 경계함. 에이전트가 기억을 작성할 때는 ‘앞으로 유용할 정보인지’보다 ‘요약’에 치우치는 경향이 있음.
  • 이러한 의도를 성공적으로 담아내는 스킬은 아직 만들지 못했으며, 에이전트가 장기 기억을 스스로 선택하거나 자체 자동화를 설정하는 방식은 신뢰하지 않음.
  • 대신 사람이 결과를 빠르게 평가해 쓸모없는 산출물인지 판단하는 절차를 둘 수 있음.

DPA에서 소프트웨어 개발 자동화로

  • 현재 소프트웨어 공장을 비판하는 유행이 있지만, 팀은 약 8개월 동안 소프트웨어 공장을 운영하면서 그 기간의 약 90%에는 코드 자체를 살펴보지 않았음.
  • 이는 코드 모델을 이해하는 어려운 일을 그만두려는 접근이 아니라, DPA를 하나씩 도입해 온 결과임.
  • 개발자 프로세스 자동화는 아직 새로운 분야이며, 무엇을 의미하는지와 어떤 도구를 구매해야 하는지가 충분히 정립되지 않은 상태임.
  • 시간이 지나면 모든 팀이 갖추는 표준 DPA 묶음이 생길 수 있음. 이는 소프트웨어 개발 수명 주기를 더 많이 자동화하는 기반이 되고, 결국 사람의 개입을 줄여 대부분 실행되는 시스템으로 이어질 가능성이 있음.
  • 에이전틱스(Agentics)는 에이전트를 활용하고 추론하는 방법을 다루는 분야임.