SDLC: Software Development Life Cycle
SDLC는 ‘소프트웨어 개발 수명 주기’라는 뜻을 가진 단어다. 소프트웨어를 개발할 때 거치는 일련의 단계들을 말한다. 소프트웨어 개발 프로젝트들은 대개 ‘기획 -> 설계 -> 구현 -> 테스트/QA -> 배포 -> 유지보수’ 의 단계를 거친다. 각 단계에서 부족한 부분이 있으면 이전 단계로 돌아가기도 하고, 한 사이클이 끝나면 다시 처음으로 돌아가서 새로운 기능의 기획부터 진행하기도 한다.
요즘 AI를 쓰면서 SDLC의 구현 단계는 확실히 빨라진 것 같다. 코드를 직접 손으로 작성하지 않은지 꽤 오래 되었다. 그렇다면 전체 개발 속도가 빨라졌을까? 그건 아니다. 여전히 마감에 쫓기며 많은 시간을 개발에 쏟고 있다.
왜 시간이 줄어들지 않을까? 지난 경험들을 돌아보면, AI가 한번에 제대로 구현해주지 못하고 여러 번 재작업을 하기 때문이라고 생각한다. 이상적으로 SDLC의 각 단계를 한 번씩만 지나가고 다시 이전 단계로 돌아가지 않는다면 작업이 꽤 빨리 끝날 것이다. 그렇지만 지금은 AI가 아무리 빠르게 구현을 해줘도 테스트와 QA 이후에 다시 구현 단계로 돌아가서 기능 수정하는 걸 반복하고 있다 보니 작업 시간이 오래 걸린다.
그리고 여전히 사람이 개입하는 부분이 많아서 시간이 오래 걸리는 것 같다. AI를 활용한 개발을 그래도 1년 가까이 해오다 보니 이제는 워크플로우가 꽤 정립되었다. 그런데 이 워크플로우를 여전히 내가 직접 수행하고 있다. 물론 Skill 같은 것도 만들어두고 테스트 코드 같은 장치들도 만들어둬서 일부는 자동화가 되어 있다. 하지만 여전히 SDLC 전반적으로 인간의 개입이 많다.
- AI가 한번에 제대로 만들지 못하고 여러 번 재작업
- SDLC 전반적으로 많은 횟수의 인간 개입
이 두 가지 원인 때문에 AI를 열심히 쓰고 있지만 작업 속도는 그렇게까지 만족스럽게 향상되지 않는 것 같다.
지금까지는 주어진 요구사항을 쳐내느라 생산성 개선에 대한 고민을 많이 하지 못했다. 당장 눈 앞에 닥친 업무를 끝내기 바빴다. 근데 이제는 생산성 개선 없이는 이 업무들을 제 시간에 다 쳐내기가 어렵다는 생각이 든다. 의도적으로 여유를 갖고 SDLC 전반에 대해 고찰하고 개선하는 시간이 필요하다고 생각한다.
AI-Native SDLC
현재 우리 팀에서는 전통적인 SDLC에 가깝게 일하고 있다. 구현 단계에서는 AI를 적극적으로 사용하고 있지만, 나머지 단계에서는 AI를 충분히 활용하지 못하고 있다. AI를 더욱 적극적이고 효과적으로 사용해야 생산성이 올라갈 것으로 보인다. 요즘은 이러한 개발 워크플로우를 AI-Native SDLC라고 부르는 것 같다.
AI-Native SDLC는 SDLC의 각 단계를 AI에 맞게 수정한 방식이다.
전통적인 SDLC에서는 사람이 작업물을 만들고 사람이 검토했다. 그리고 구현 단계가 가장 큰 병목이었다. SDLC의 주기가 길었고, 모든 단계는 사람에게 맞춰져 있었다. 각 단계에서 책임성과 통제를 확보하기 위해 프로세스가 무겁게 설계되어 있었다. 코드 작성이 가장 시간과 비용이 많이 드는 단계였던 시대에 효율을 극대화하기 위해 만들어졌었다.
근데 AI를 활용해 개발을 할 때는 이러한 전통적인 방식이 잘 맞지 않는다. AI를 활용하게 되면 더 이상 구현이 병목이 아니게 된다. 병목은 구현 단계의 앞뒤로 이동하게 된다. 기획, 설계, 리뷰, 테스트, 배포 등으로 병목이 이동하게 된다. 또한 AI는 굉장히 많은 코드를 만들어낸다. 이전에 사람이 직접 코드를 작성할 때는 모든 코드를 사람이 검토하는게 가능했다. 근데 이제는 사람의 검토 속도가 AI의 코드 생산 속도를 따라갈 수 없다. 모든 단계를 사람이 직접 검증하던 방식을 이제는 더 이상 사용할 수 없다.
AI에 맞게 SDLC의 각 단계를 수정할 필요가 있다. AI에 맞게 SDLC의 각 단계를 수정한 방식을 AI-Native SDLC라고 한다.
우리 팀의 SDLC를 AI-Native하게 바꿔보려고 한다. 각 단계를 어떻게 바꾸면 좋을지 생각 정리를 할 겸 쭉 적어보겠다.
공통 사항
SDLC 공통적으로 적용할 사항들이 있다.
우선 Slack과 GitHub를 AI와 사람의 주요 인터페이스로 사용하고자 한다. Slack과 GitHub가 가장 접근성과 사용성이 좋다고 판단했다. 그리고 Slack과 GitHub를 사용하면 다른 사람이 어떤 작업을 하는지 보기 쉽고, 팀 전반적인 SDLC를 강제하기 좋다고 생각한다.
물론 적절한 시점에 필요하다면 직접 AI CLI 툴을 사용할 수도 있겠지만, 일단 기본적으로 Slack과 GitHub를 AI와 사람의 인터페이스로 사용하고자 한다.
그리고 팀 내부의 지식을 Skill로 정리하고자 한다. 계속 사람이 명령을 내리기 보다는, AI가 Skill을 참고해서 알아서 작업하게 하는게 목표다. 사람이 피드백을 주기 전에 AI가 알아서 팀의 정책에 맞게 구현하게 하려고 한다. 사람이 검수해서 재작업하는 걸 최대한 줄이고 싶다.
또한 Hook도 적절히 설정하고자 한다. Skill은 항상 실행되는게 아니기 때문에 Hook으로 이러한 비결정론적인 특성을 보완하고자 한다.
Step 1: 기획 @ AI-Native SDLC
기획 단계의 최종 산출물은 intent.md 이다. 개발자와 AI가 질문과 답변을 주고 받으면서 개발자의 의도를 정리해서 intent.md 라는 하나의 파일에 정리하게 하려고 한다.
지금 생각하고 있는 워크플로우는 다음과 같다.
- 슬랙에서 AI 봇을 호출하면서 요구사항을 입력한다.
- AI 봇이 요구사항의 모호한 부분을 찾고 사람에게 추가 질문을 던진다. 모호함이 사라질 때까지 이 과정을 반복한다.
- 모호함이 사라졌다면, AI 봇이
intent.md파일의 초안을 작성하여 사람에게 승인을 받는다. 사람은 승인을 하거나 수정 요청을 보내서 수정 작업을 반복한다. intent.md를 사람이 승인했다면, AI 봇이 GitHub에intent.md파일을 담은 PR을 올린다.- 필요할 경우 관련자의 리뷰를 받고 수정하거나 머지한다.
- 머지되면 자동으로 다음 단계인 설계 단계가 트리거 된다.
다음 단계인 설계 단계가 자동으로 트리거 되게 해서 개발자가 SDLC 의 각 단계를 신경쓰지 않아도 AI-native SDLC를 준수할 수 있도록 하려고 한다.
Step 2: 설계 @ AI-Native SDLC
설계 단계의 최종 산출물은 spec.md 이다. 기획 단계에서 만들었던 intent.md 를 바탕으로 요구사항의 스펙을 작성해서 spec.md 에 적으려고 한다.
이 단계는 기획 단계에서 intent.md 가 머지되면 자동으로 트리거 되는 것을 생각하고 있다.
이 단계를 제대로 설정해두는 것이 다음 단계들을 위해 중요하다고 생각한다. 이 단계에서 스펙을 빠트리거나 잘못된 스펙을 적으면 이후 단계에서 구현도 당연히 제대로 안 될 것이고 검증도 제대로 하기 힘들다. AI의 속도를 제대로 만끽하기 위해서는 재작업을 최대한 줄이는게 중요하다. 스펙을 최대한 꼼꼼하고 명확하게 적는 것이 재작업을 줄이는 길이라고 생각하기 때문에 이 단계가 전체 SDLC 단계 중 가장 중요하다고 생각한다.
또한 설계 문서인 spec.md 는 낡지 않도록 지속적으로 관리해줘야 한다. 유지 보수 단계에서 기능 수정을 하게 되면 spec.md 도 맞춰서 수정을 해줘야 한다. spec.md 와 코드의 괴리가 없도록 만드는 것이 중요하다. 이건 뒷 단계에서 추가로 적어보겠다.
설계 단계는 다음과 같은 플로우로 만들고자 한다.
- 기획 단계에서 작성한
intent.md가 머지된다. - 설계 단계가 트리거 된다.
- 슬랙 AI 봇이 슬랙 채널에 설계 단계 시작 메시지를 보낸다. 적절한 정보를 요약해서 시작 메시지에 담는다.
- 그 메시지의 댓글에 AI 봇이 사람에게 질문을 남긴다. 사람은 해당 질문에 대한 답변을 작성하면서 스펙을 완성해 간다.
- AI가 스펙이 완성되었다고 판단하면
spec.md초안을 작성하여 사람에게 승인을 받는다. - 사람은 승인을 하거나 수정 요청을 한다. 최종적으로 승인이 되면, AI 봇은 PR을 올린다.
- 관련자의 리뷰가 필요하면 리뷰를 요청하고, 필요한 경우 수정한다. 최종적으로 머지한다.
- 머지되면 자동으로 다음 단계인 구현 단계가 트리거 된다.
이 설계 단계에서는 스펙 완성 기준을 어떻게 잡을지가 고민이다. 스펙이 완성되었다는 것이 굉장히 주관적이고 모호하다고 생각한다.
설계 단계에서 스펙을 작성한다는 것은 사람이 당연하게 생각하는 동작들을 문서로 옮기는 작업이 있겠고, 보안, 성능 등 기술적인 기준들을 문서로 옮기는 작업이 있겠다. 여기서 소프트웨어의 동작, 기능과 관련된 스펙을 어떻게 빠짐없이 만들지, 그리고 스펙이 빠짐 없이 적혔다는 것을 보장할 수 있을지 그 기준이 고민된다.
한편으로는 처음부터 완벽한 스펙을 만드는게 정말 가능할까 싶기도 하다. 이후 구현과 QA/테스트 단계를 거치면서 스펙의 부족한 점을 발견하고 다시 스펙을 보완하는 식으로 가야할까 싶기도 하다.
NASA에서 쓴 Systems Engineering Handbook 이라는 책이 있는데 이 책을 참고해서 기준을 정해도 괜찮을 것 같다. 이건 조만간 읽어봐야겠다. 링크: https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf , https://www.nasa.gov/reference/systems-engineering-handbook/
정리하면, 스펙을 AI 로 만드는 건 좋은데, 어느 시점이 되었을 때 AI가 완성되었다고 판단하게 시킬지를 모르겠다. 이건 더 고민해보고 방법을 찾아봐야겠다.
Step 3: 구현 @ AI-Native SDLC
설계 단계가 끝나면 자동으로 구현 단계가 트리거 되게 하려고 한다. 구현 단계는 plan.md 를 먼저 만들고, 이 plan.md 파일을 따라서 AI 에이전트가 구현 작업을 진행하게 하려 한다.
- 설계 단계에서
spec.md가 머지되면서 설계 단계가 종료되고 구현 단계가 트리거된다. - AI는 슬랙 채널에 구현 단계 시작 메시지를 적당한 정보와 함께 남긴다.
- 해당 메시지에 댓글을 통해 필요한 경우 사람과 소통하고
plan.md파일을 작성한다. - AI가
plan.md의 초안을 작성해서 슬랙을 통해 사람의 승인을 받는다. - 사람의 승인을 받으면 PR을 올린다.
- 필요한 경우 PR의 리뷰를 거쳐서 머지한다.
plan.md가 머지되면 AI 에이전트가 구현을 시작한다.- 필요한 경우 AI 에이전트가 슬랙을 통해 사용자의 의견을 구한다.
- 필요한 경우 테스트 / QA 방법을 이용해 AI 스스로 검증하고 개선하도록 한다.
- 작업이 완료되면 AI 에이전트가 PR을 올린다.
- 이후 단계를 거친다. PR은 테스트/QA 단계가 완료되면 머지한다.
AI가 재작업을 최대한 하지 않도록 만드는게 중요하다. 이전 기획과 설계 단계에서 intent.md 파일과 spec.md 파일을 잘 만들어서 모호함을 줄이는게 필요하다.
또한 Skill과 Hook을 잘 설정해서 재작업 없이 한번에 사람의 의도대로 구현할 수 있는 환경을 만드는 것도 필요하다.
PR은 바로 머지하지 않는다. QA 단계를 거쳐서 통과하면 머지한다.
Step 4: 테스트 / QA @ AI-Native SDLC
테스트, QA 를 위해서는 시나리오가 중요하다. 어떤 시나리오를 테스트할지 정하는게 중요하다. 설계 단계에서 테스트 시나리오를 함께 뽑는다. 테스트 시나리오가 충분할 때까지 반복해서 뽑는다.
테스트 시나리오를 만들 때도 AI의 도움을 최대한 받도록 한다. 대신 너무 AI에 의존하지 않게 만드는 장치가 필요할 것 같다. 이건 더 많은 고민이 필요하다.
테스트 시나리오를 기반으로 테스트 코드를 작성하고 실행한다. 구현 작업 중간에는 가벼운 테스트 위주로 실행하고 CI에서는 전체 테스트를 실행한다.
QA 작업을 사람이 수동으로 하기에는 시간이 너무 오래 걸린다. AI 에이전트가 E2E 테스트를 실행하고 이를 스크린샷과 영상으로 찍어서 사람은 사진과 영상을 보고 확인하게 한다. 이러한 사진과 영상은 슬랙과 깃허브에 모두 남겨서 리뷰하는 사람이 확인하기 편하게 하면 좋겠다.
Step 5: 배포 @ AI-Native SDLC
PR 리뷰에서도 AI를 활용한다. 인간이 모든 코드를 리뷰할 수는 없기 때문에 AI가 일단 리뷰를 진행하고 사람이 체크해야 하는 범위를 줄이고자 한다.
팀과 제품의 정책을 Skill로 만들어두고 리뷰할 때는 이 Skill을 이용해서 정책을 충족하는지 AI가 검사하게 하려 한다. 또 한편으로는, 변경들의 중요도를 나눠서 중요한 부분이 무엇인지 사람에게 알려주고 사람은 중요한 부분 위주로 리뷰하게 하고자 한다.
깃허브 PR에서도 AI 에이전트를 호출할 수 있게 하여 리뷰 과정에서 AI의 도움을 받도록 하려 한다.
AI 리뷰 사항에 대한 CI 게이트도 만들면 안전성을 높이기 더 좋을 것 같다. 어떠한 기준을 threshold로 잡을지는 더 고민이 필요하다. 특히 보안처럼 크리티컬한 리뷰 사항들은 꼭 CI 단계에서 차단하고자 한다.
CI 단계를 더욱 촘촘하게 만들어서 최대한 검증된 코드만 main 브랜치에 머지가 되게 만들고 main 브랜치는 언제든 배포해도 괜찮은 상태를 유지하고자 한다.
Step 6: 유지보수 @ AI-Native SDLC
정해진 일정에 따라서 주기적으로 코드 베이스를 스캔하고, 리팩토링 포인트를 찾은 다음에 AI 에이전트가 자동으로 이슈 생성, 코드 작업, PR 생성까지 진행하도록 하려 한다. 어떤 요소를 리팩토링 할지, 어떤 기준으로 평가할지는 정해야 한다. 그리고 코드 베이스가 작지 않은데, 이 코드 베이스를 전부 탐색할 것인지, 나눠서 탐색한다면 어떤 기준으로 나눌지도 정해야 한다.
그리고 모니터링 툴과 연결하여 이슈가 생길 경우 AI 에이전트가 우선 대응하게 만들고자 한다. 일단 문제 상황에 대한 설명을 슬랙 채널에 업로드하는 정도는 모든 경우에 수행하게 할 것 같다. 코드 작업까지 진행하게 할지는 더 검토가 필요해 보인다.
마무리
AI Native SDLC에 대한 생각은 어느 정도 정리가 된 것 같다. 각 단계의 품질에 대한 세부적인 기준을 세우고 실제로 구축을 해봐야겠다.