도입은 이렇게 진행됩니다
기본 틀과 고객마다 채울 것
AEGIS(Autonomous Engine for Governed Integration Services — 통제된 통합 서비스를 위한 자율 실행 엔진)의 기본 흐름은 공급자 시험 환경에서 동작하지만, 실제 고객 연동을 준비하면서 고객마다 달라지는 지점이 계속 드러났습니다. 보완한 것만 해도 Gerrit 변경 알림 형식, 사내 암호화 없는 연동 허용, 메일 중계 서버 방식, 기존 빌드 작업 전환 절차, AD(Active Directory — 사내 계정 디렉터리) 연결 안내, 서비스 계정 최소 권한입니다. 그래서 AEGIS 도입은 "설치해 드립니다"가 아니라 "고객 요건을 받아 고도화하고 고객 환경에 맞춰 함께 구축합니다"입니다. 아직 만들지 않은 기능을 완성된 것처럼 약속하지 않고, 무엇을 만들지는 진단으로 정해 계약서에 적습니다.
- 소스 저장소·빌드 도구 — 지금 되는 것: Gerrit, Jenkins. 고객에 따라 추가로 만드는 것: GitHub·GitLab·Bitbucket, 다른 빌드 도구는 연동 모듈(어댑터) 개발
- 로그인 — 지금 되는 것: LDAP(Lightweight Directory Access Protocol, 사내 계정 조회 표준)(AD 포함 — AD 실환경 연결은 첫 구축에서 확인). 고객에 따라 추가로 만드는 것: 통합 로그인(SSO — Single Sign-On)
- 알림 — 지금 되는 것: 메일, Telegram, Slack. 고객에 따라 추가로 만드는 것: MS Teams 등 다른 메신저
- AI(Artificial Intelligence, 인공지능) 분석 — 지금 되는 것: 사내 모델 연결, 모델 없이 운영. 고객에 따라 추가로 만드는 것: 고객 모델의 분석 품질 확인과 지시문 조정
- 운영 규칙·화면 — 지금 되는 것: 역할·권한, 프로젝트 범위, 결정 네 가지, 알림 시간 규칙, 운영 화면 12종. 고객에 따라 추가로 만드는 것: 고객 승인·보고 체계에 맞춘 설정, 고객 보고서·통계, 사내 결재·이슈 관리 시스템 연계
도입 단계
- 소개·시연 — 현재 빌드 운영 현황을 듣고, 시험 환경에서 기본 흐름(빌드 실패 → 원인 분석 → 승인 → 제외 후 재시도 → 감사 기록)을 보여 드립니다. 결과: 진단 여부 결정
- 유료 진단 — 요건 워크숍과 환경 조사 — 소스 저장소·빌드 도구, 기존 빌드 작업 구조, 계정·메일·AI 모델, 승인 체계, 보안 심사 요구, 지금 실패 대응에 드는 시간. 결과: 진단 보고서, 구축 계획
- 구축 — 진단에서 정한 고도화 개발, 설치, Gerrit·Jenkins·계정·메일·모델 연결, 기존 빌드 작업 전환. 결과: 기능 검수
- 병행 운영·튜닝 — 기존 방식과 함께 돌리며 분석 품질·승인 흐름·알림 대상을 맞춤. 과거 실패 로그와 시험용 실패 빌드로 먼저 맞춰, 실제 실패를 무작정 기다리지 않습니다. 결과: 안정화, 효과 측정
- 운영·유지보수 — CM(Configuration Management, 형상관리) 담당자·개발자·운영자 교육과 운영 이관, 이후 운영 기록으로 다음 개선을 찾음. 결과: 운영 전환
진단만으로도 남는 것이 있습니다. 진단 보고서는 AEGIS 견적서가 아닙니다. ① 현재 빌드 운영의 문제와 실패 대응에 드는 시간, ② 개선 대안 비교(현 방식 유지 / 스크립트·기존 도구 개선 / AEGIS 도입의 비용·효과·위험), ③ AEGIS를 도입할 경우 이미 된 것·고도화할 것·하지 않을 것의 구분과 고객 준비 사항을 드립니다. 구축하지 않기로 해도 이 결과는 고객에게 남습니다.
구축 계약에는 기능 검수와 효과 측정을 나눠 적습니다. 기능 검수는 합의한 시나리오가 고객 환경에서 동작하는지이고, 절감 시간 같은 효과는 운영 기록으로 따로 측정합니다. 병행 운영 기간에는 상한을 둡니다.
고객이 준비할 것
- amd64 Linux 서버 1대와 Docker, TLS(암호화에 쓰는 인증서 방식) 인증서(사설 인증기관 가능)
- Gerrit·Jenkins 서비스 계정 — 최소 권한으로 Jenkins는 전역 읽기·job 읽기·빌드, Gerrit은 대상 저장소 브랜치 읽기로 확인했습니다
- 기존 Jenkins job 전환 — 되감을 커밋을 입력으로 받도록 설정하고 소스 되감기 도구를 빌드 앞에 둡니다. Jenkins 빌드 노드에 Python 3.6 이상, Git 2.12 이상이 필요합니다
- Gerrit 변경 알림(웹훅) 설정, 프로젝트별 저장소 목록
- LDAP·AD 연결 정보, 메일 발송 경로, 사내 AI 모델 주소(있으면)
- 백업 주기 설정과 서버 밖 백업 보관 위치
- CM 담당자·개발 리더·보안/인프라 담당자의 진단·구축 참여 일정
잘 맞는 조직, 먼저 따져 볼 조직
잘 맞는 조직
- Gerrit·Jenkins로 빌드를 운영하고 있다
- CM 담당자나 빌드·배포 팀이 빌드 실패 대응과 재시도에 반복적으로 시간을 쓴다
- 빌드·배포 결정의 추적성과 감사 기록이 필요하다(규제 산업, 납품 검수, 내부 감사)
- 사내 Linux 서버와 Docker를 운영할 수 있다
먼저 따져 볼 조직
- 클라우드 빌드 서비스만 쓴다 — 연동 모듈 개발이 커집니다
- 빌드 운영 자체가 드물다 — 효과가 작습니다
- 이중화(HA — High Availability, 한 서버가 멈춰도 다른 서버가 이어받는 구성)가 필수다 — 현재 단일 서버 구성입니다
- ARM 계열 서버만 쓸 수 있다 — 현재 amd64만 지원합니다