빌드 운영에서 무엇이 힘든가

빌드가 실패한 아침

여러 팀이 만든 코드를 합쳐 빌드(소스 코드를 실행할 수 있는 결과물로 만드는 작업)하는 조직에서는 밤마다 통합 빌드를 돌립니다. 빌드가 실패한 날 아침, CM(Configuration Management, 형상관리) 담당자는 보통 이런 순서로 움직입니다.

빌드 서버(Jenkins)에서 실패를 확인하고, 수천 줄의 로그에서 오류를 찾고, 소스 저장소(Gerrit)에서 밤사이 들어온 커밋(개발자가 올린 소스 변경 한 묶음)과 대조하고, 작성자에게 연락하고, 문제 커밋을 뺀 채로 다시 빌드하고, 결정 경위를 메일이나 문서로 따로 정리합니다.

왜 어려운가

• 도구가 흩어져 있습니다 — 빌드 서버·로그·소스 저장소·메신저·메일을 사람이 오가며 잇습니다. 숙련자가 자리에 없으면 대응이 늦어집니다.
• 원인 찾기가 사람에게 달려 있습니다 — 어느 커밋이 빌드를 깼는지 로그와 변경 내역을 대조하는 방법이 사람마다 다릅니다.
• 결정 경위가 남지 않습니다 — "누가 언제 왜 그 커밋을 빼고 다시 빌드했는가"가 메신저와 메일에 흩어집니다. 감사나 납품 검수 때 다시 모아야 합니다.
• 개발자는 자기 실패를 늦게 압니다 — 내 커밋이 빌드를 깼다는 사실을 CM 담당자의 연락을 받고서야 압니다.

AEGIS(Autonomous Engine for Governed Integration Services — 통제된 통합 서비스를 위한 자율 실행 엔진)는 이 일을 없애는 것이 아니라 한 화면과 한 흐름으로 모으고, 결정만 사람에게 남기고, 경위를 자동으로 기록하는 것을 목표로 합니다.