AI-DLC 개발
AI 주도 개발 라이프사이클
AI-DLC란 요구사항 정의·설계·구현·리뷰·테스트·운영이라는 소프트웨어 개발의 전 과정에 AI가 참여하고, 그 방향을 정하고 결과를 책임지는 것은 엔지니어라는 방식입니다. “AI가 코드를 쓴다”는 뜻이 아닙니다. 기계적인 작업을 AI에 맡기고 사람은 판단에 집중하는, 규율 있는 라이프사이클입니다.
하나의 루프, 하나의 명세
모든 단계가 같은 명세서를 읽고 그 결과를 다시 명세서에 적습니다. 모델과 엔지니어와 리뷰어가 서로 비슷한 세 개의 시스템이 아니라 하나의 시스템을 만들어 갈 수 있는 이유입니다.
일하는 원칙
명세에서 출발합니다
요구사항과 인수 조건은 문서로 남기고 항상 최신으로 유지합니다. 사람도 AI도 그것을 기준으로 구현하기 때문입니다.
리뷰를 거친 생성
AI가 도운 구현도 사람의 리뷰, 자동 테스트, 정적 분석을 모두 통과한 뒤에야 병합됩니다. 예외는 없습니다.
지속적인 검증
모든 변경에는 테스트가 따릅니다. 무엇이 준비되었는지를 판단하는 것은 사람이 아니라 파이프라인입니다.
기록된 의사결정
아키텍처 의사결정은 내려질 때마다 기록합니다. 그 근거가 계약 기간보다 오래 남도록 하기 위해서입니다.
세 개의 실행 영역
신규 개발은 그중 하나일 뿐입니다. 멈출 수 없는 시스템을 옮기는 일, 그리고 고객사 팀이 스스로 이 라이프사이클을 돌리도록 돕는 일도 같은 비중으로 맡고 있습니다.
01 / 03실행 영역
AI-DLC 기반 소프트웨어 개발
AI 주도 라이프사이클 아래에서 신규 시스템을 처음부터 끝까지 구축합니다. 요구사항·설계·구현·리뷰·테스트의 기계적인 작업은 AI가 맡고, 판단과 병합의 책임은 엔지니어가 집니다.
- 명세와 인수 조건을 먼저 문서로 남기고 최신으로 유지하며, 사람과 모델 양쪽의 구현 계약으로 사용합니다
- AI가 도운 구현은 사람의 리뷰, 자동 테스트, 정적 분석을 반드시 거칩니다
- 아키텍처 판단은 그때그때 기록해, 그것을 정한 팀보다 오래 근거가 남게 합니다
- 무엇을 내보낼지 판단하는 주체가 담당자가 아니라 파이프라인인 지속적 배포
일반적인 기간3 – 9개월
02 / 03실행 영역
마이그레이션과 현대화
멈출 수 없는 시스템을 옮깁니다. 사람이 읽어서는 따라갈 수 없는 속도로 AI가 레거시 코드를 읽히게 만들고, 이전 자체는 그 자체로 배포 가능한 단위로 나눠 진행합니다.
- 레거시 진단: 의존 관계와 호출 그래프 파악, 죽은 코드 식별, 그리고 문서가 사라진 부분의 동작을 코드에서 복원
- 점진적 스트랭글러 피그 이전. 새 기능을 앞에 두고 기존 시스템을 경로 단위로 퇴역시키며, 트래픽이 실제로 옮겨질 때까지 둘을 함께 돌립니다
- 재플랫폼화와 재설계: 런타임과 프레임워크 업그레이드, 값하는 범위에서의 모놀리스 분해, 그리고 값하지 않을 때는 그렇다고 그대로 말씀드립니다
- 대사를 동반한 데이터 이전: 스키마 매핑, 백필, 이중 쓰기 또는 이중 읽기, 그리고 문서로만이 아니라 실제로 예행연습을 마친 롤백을 갖춘 전환
일반적인 기간4 – 12개월
03 / 03실행 영역
AI-DLC 트랜스포메이션
저희가 대신 해 드리는 것이 아니라, 고객사 팀이 이 라이프사이클을 몸에 익히도록 돕는 일입니다. HCT 인력이 자리에 없어도 돌아가는 순간이 완료 시점입니다.
- 현재의 개발 프로세스와 도구와 제약에 대한 진단. 보안 부서와 법무 부서가 무엇을 허용하고 무엇을 허용하지 않는지까지 확인합니다
- 도구 정비: AI 코딩 도구, 저장소 규약, 리뷰 게이트, 그리고 리뷰를 거치지 않은 생성 코드가 운영에 들어가지 않게 하는 CI 검사
- 엔지니어·리뷰어·QA·프로덕트 각각을 위한 역할별 교육. 튜토리얼 저장소가 아니라 고객사 코드베이스에서 진행합니다
- 동행하는 파일럿, 그리고 인수인계: 플레이북, 사내 추진자, 그리고 파일럿이 무엇을 바꿨고 무엇을 바꾸지 못했는지에 대한 솔직한 회고
일반적인 기간6 – 12주
AI가 하는 일, 엔지니어가 지는 책임
의미 있는 질문은 “AI를 쓰는가”가 아니라 “AI에 어떤 판단을 맡기는가”입니다. 맡기는 판단은 하나도 없습니다. 모든 프로젝트에 적용하는 단계별 역할 분담을 그대로 적었습니다.
요구사항
AI가 하는 일
주신 자료에서 스토리와 인수 조건 초안을 만들고, 요구사항끼리 어긋나는 지점을 짚어 냅니다.
엔지니어의 책임
무엇을 범위에 넣을지, 시스템이 결코 해서는 안 되는 일이 무엇인지, 그리고 각 충돌을 어느 쪽으로 정리할지.
설계
AI가 하는 일
설계안을 여러 개 만들어 제시된 제약과 대조하고, 결정 기록의 초안을 씁니다.
엔지니어의 책임
아키텍처, 그와 함께 받아들이는 트레이드오프, 그리고 프로젝트보다 오래 남을 결정 기록에 대한 서명.
구현
AI가 하는 일
명세에 맞춰 코드를 쓰고, 저장소에 이미 있는 규약에 맞추며, 테스트도 함께 만듭니다.
엔지니어의 책임
코드가 지켜야 할 경계, 그리고 공유 브랜치에 닿기 전에 모든 줄을 읽는 일.
리뷰
AI가 하는 일
뻔한 결함, 빠진 테스트, 규약에서 벗어난 부분을 먼저 걸러 사람의 리뷰가 깔끔한 차이에서 시작되게 합니다.
엔지니어의 책임
승인 또는 반려. AI의 1차 확인은 그 대체가 될 수 없고, 승인자 이름이 없는 브랜치는 병합되지 않습니다.
테스트
AI가 하는 일
사람이 지나치기 쉬운 경계 조건까지 포함해 케이스를 만들고, 스키마 변경에 픽스처를 맞춥니다.
엔지니어의 책임
“맞다”의 정의, 어떤 실패가 릴리스를 막는지, 그리고 깨진 채로 운영에 나갔을 때의 답변.
운영
AI가 하는 일
장애를 요약하고 로그와 트레이스를 맞춰 보며 첫 가설을 제시합니다.
엔지니어의 책임
판단과 조치, 그리고 새벽 3시의 호출.
게이트는 어디에 있는가
게이트 없는 속도는 같은 결함에 더 빨리 닿을 뿐입니다. 이 세 가지는 저희 일에서도 고객사 일에서도 움직이지 않으며, 트랜스포메이션에서 가장 먼저 세우는 것도 이 세 가지입니다.
리뷰 없이 병합되지 않습니다
생성된 코드와 사람이 쓴 코드는 완전히 같은 경로를 지납니다. 먼저 자동 검사, 그다음 이름이 있는 승인자. 브랜치 보호로 강제하기 때문에, 여유 없는 주에 누가 버텨 주는지에 기대지 않습니다.
판단은 파이프라인이 하고, 사람이 하지 않습니다
테스트, 정적 분석, 의존성과 시크릿 스캔이 모두 통과해야 합니다. 마감이 가깝다고 밀어 넣는 사람은 나오지 않습니다. 밀어 넣을 수단 자체가 없기 때문입니다.
출처가 남습니다
커밋에는 어떻게 만들어졌는지가, 결정 기록에는 왜 그렇게 했는지가 남습니다. 반년 뒤에도 무엇이 생성되었고 무엇이 리뷰되었으며 누가 승인했는지 확인할 수 있습니다.
다루는 기술
프로젝트마다 선택합니다. 모든 과제에 밀어 넣는 자사 표준 스택은 두지 않으며, 고객사 팀이 이미 운영하고 있는 기술에 맞춥니다.
언어와 프레임워크
고객사 팀이 이미 운영하고 있는 기술로 개발합니다. 돌아가는 시스템을 저희가 편한 언어로 다시 쓰는 것은, 저희 편의를 고객이 비용으로 치르는 일입니다.
- TypeScript
- Python
- Java
- Spring
- Go
- .NET
- React
데이터와 플랫폼
만들어 드린 시스템이 돌아가는 실행 기반, 그리고 현대화라면 그곳으로 들어가고 나오는 이전 경로.
- PostgreSQL
- Redis
- Kafka
- Docker
- Kubernetes
- Terraform
- AWS
- Azure
품질 게이트와 배포
AI가 돕는 개발을 “빠르지만 후회하는” 것으로 만들지 않는 장치가 게이트입니다. 저희 일에서는 양보하지 않는 부분이며, 고객사 환경에도 같은 형태로 세웁니다.
- Claude Code
- Git
- GitHub Actions
- SonarQube
- Playwright
- Vitest
- OpenAPI
- ADRs
프로젝트 진행 방식
1 – 3주 차
파악
요구사항, 제약, 그리고 이전 프로젝트라면 기존 시스템이 실제로 어떻게 동작하는지. 산출물은 제안 슬라이드가 아니라 명세서입니다.
2 – 5주 차
설계
아키텍처, 인터페이스, 테스트 전략, 리뷰 게이트. 각 회차의 “완료”가 무엇인지는 그 회차를 시작하기 전에 합의합니다.
2개월 차 이후
구현
2주 단위로 끊고, 그 끝에는 반드시 무언가가 배포되어 있게 합니다. AI가 빠르게 만드는 것은 그 안쪽이고, 주위의 게이트는 움직이지 않습니다.
마지막 2 – 4주
인수인계
문서, 런북, 결정 기록, 그리고 앞으로 운영할 팀과 함께하는 실작업 세션. 트랜스포메이션 프로젝트에서는 이것 자체가 목적입니다.
남게 되는 것
- 마지막에 한꺼번에가 아니라 회차마다 운영에 닿는 동작하는 소프트웨어
- 왜 이런 형태가 되었는지 설명할 수 있는 명세서와 결정 기록
- 저희 없이도 실행하고 확장할 수 있는 테스트 스위트와 파이프라인
- 이전 프로젝트에서는, 대사를 마친 데이터 전환과 예행연습을 마친 롤백
- 트랜스포메이션에서는, 가드레일이 갖춰진 상태에서 자사 엔지니어가 라이프사이클을 돌리는 상태
이 영역에서 상의할 일이 있으십니까
문제의 윤곽을 알려 주십시오. 저희가 적임인지 아닌지 솔직하게 말씀드리겠습니다.