루프 엔지니어링을 DevOps에 어떻게 접목할 것인가
Jaewoo Kim · 조회 0 · 6분 읽기목차
생성 AI 코딩 에이전트가 등장한 지 제법 세월이 흘렀다. 그사이에도 모델의 진화는 멈추지 않았고, 2026년에 들어설 무렵부터 "루프 엔지니어링"이라는 말을 듣게 된 사람도 많지 않을까.
이는 사람이 코드를 쓰는 게 아니라, 구현 → 리뷰의 사이클을 생성 AI가 자율적으로 계속 돌리며 요건을 채울 때까지 구현을 이어 가는 개발 스타일을 가리킨다.
확실히, 이 덕분에 개발 효율은 비약적으로 올라갔다. 그러나 한편으로 환각(할루시네이션)의 리스크와, 예상 이상으로 비용이 불어나는 과제도 동시에 떠오르고 있다.
그래서 이 글에서는, 지난번에 소개한 "AI 시대의 문서 구동 개발"의 사고방식을 토대로, 이런 루프 엔지니어링식 개발을 DevOps에 어떻게 짜 넣을지를 생각해 보려 한다.
일어날 수 있는 리스크: 환각
루프 엔지니어링을 하지 않는 사람도 자주 느낄 텐데, AI와 주고받기를 이어 가다 보면 점점 방향성이 어긋날 때가 있다.
사람이 채팅으로 주고받으며 리뷰하고 구현을 진행하는 방식이라면, 어긋남이 생긴 그 시점에 알아차려 바로잡을 수 있다. 그러나 리뷰까지 AI에게 맡겨 버리면, 알아차렸을 때는 이미 손쓸 수 없게 되어 있는 일이 일어날 수 있다.
어떻게 대책을 세울 것인가
여기서의 대책으로는, 지난 글 "AI 시대의 문서 구동 개발"을 참조해 주었으면 한다.
즉, 처음에 AI에게 로드맵을 깔아 준다는 것이다. 그리고 리뷰도 그 로드맵과의 대조로 한다.
그렇다고 해도, 그것만으로 완전히 막을 수 있는 건 아니다. 아니, 완전히 막는 것은 구조상 불가능하다. 다만 장치를 어떻게 짜느냐에 따라 발생 확률을 더 낮출 수는 있다.
루프 엔지니어링을 실무에 어떻게 접목할 것인가
우선 중요한 전제가 2가지 있다.
- 루프 엔지니어링은 루프 하나만으로 완결되는 것이 아니다. 그 루프 하나 안에도 다시 다수의 루프가 존재한다. 즉, 루프의 집합체로 파악할 것
- 되도록 잘게 쪼개면서 구현을 진행할 것
많은 경우 루프 엔지니어링은 "구현 → 리뷰"의 루프를 AI가 실행하는 것으로 이야기된다. 그러나 나는 그것만으로는 부족하다고 생각한다.
내가 생각하는 루프 구성은 다음과 같다. 참고로 이것은 기능마다 돌리는 루프이며, 전체 기능의 설계가 끝난 뒤에 일괄로 구현 페이즈에 들어가는 게 아니다. 기능 하나마다 "페이즈 1 → 페이즈 2"를 한 바퀴 돌리고, 그것을 기능의 수만큼 반복해 가는 이미지다.
페이즈 1: 요건·설계
- 요건 정의 → 리뷰의 루프
- 설계 → 리뷰의 루프
여기까지를 AI가 한 차례 하고, 그 뒤에 사람이 사양 리뷰를 한다. 요건·설계를 채우지 못했다면 다시 루프를 돌린다. 이것을 반복한다.
페이즈 2: 구현·테스트
페이즈 1에서 사양 리뷰를 통과하면, 다음은 이쪽 루프로 옮겨 간다.
- 구현 → 리뷰의 루프
- 테스트 → 리뷰의 루프
여기까지를 AI가 한다. 이때, 테스트 커버리지를 보여 주는 문서와 구현 사양서를 반드시 성과물로 출력시킨다.
그 뒤에, 구현 사양서가 설계 시점의 내용에서 바뀌지 않았는지를 리뷰·수정하는 루프를 돌린다. 이어서 테스트 커버리지 검증을 사람이 하고, 충분하다고 판단되면 전체를 관통하는 리뷰를 시킨다.
여기서 중요한 것은, 설령 MVP라 해도 되도록 잘게 구현 내용을 나눠서 루프를 돌리는 것이다.
페어 프로그래밍과 몹 프로그래밍의 차이에서 생각한다
이 차이를, 페어 프로그래밍(페어프로)과 몹 프로그래밍(몹프로)의 차이에 빗대어 생각해 보고 싶다.
페어프로를 할 때는 리뷰 담당인 사람과 구현 담당인 사람이 각각 존재했다. 사람끼리 리뷰하면서 구현을 진행해 가는 이 구도가 그대로, 루프 엔지니어링 이전의 종래 AI 활용 개발에도 들어맞는다. 즉 사람이 리뷰 담당, AI가 구현 담당이라는 역할 분담이다.
한편 루프 엔지니어링은, AI에게 "몹프로"를 시키는 것과 같다고 말할 수 있다.
그렇다고 해도, AI에게 티켓을 배정해 작업을 시킨다고 해서 완전히 맡겨 둘 수는 없다. 우선 해 줬으면 하는 범위를 정하고, 그 인식에 어긋남이 없도록 협의를 하고, 그 위에서 구현을 진행하게 한다.
즉, 이것은 사람에게 일을 의뢰하는 것과 그다지 다르지 않다. 차이가 있다면, 상대가 조금 잘 까먹는 편이라는 정도다. 그렇기에 "상대는 AI니까"라며 특별 취급하는 게 아니라, 인간 동료와 똑같이 대해 가는 것이야말로 루프 엔지니어링을 실무에 도입하기 위한 조건이 아닐까 생각한다.
루프 엔지니어링을 DevOps에 어떻게 대응시킬 것인가
지금까지 DevOps라고 하면, CI/CD로 막힘없이 릴리스를 한다는 사고방식이 주류였다. 이 방향성 자체는 앞으로도 변하지 않을 것이다. 그러나 개발 프로세스 자체가 루프 엔지니어링으로 다층화·세분화되어 가는 이상, CI/CD 쪽에도 더 잘게 쪼갠 수준의 루프가 요구되게 되리라 생각한다.
구체적으로는, 기능별 루프가 완료된 시점에 AI가 자동으로 PR을 만들고 작게 배포까지 돌리는 흐름을 생각하고 있다.
나아가 말하면, 이것은 구현 페이즈만의 이야기가 아니다. DevOps의 루프에는 일반적으로 Plan → Code → Build → Test → Deploy → Operation → Monitor → Feedback이라는 페이즈가 있다. 이 중 "Feedback → Plan" 페이즈에서도 같은 사고방식을 살릴 수 있을 것이다. 즉, 얻은 피드백이 정말 이 구현 내용으로 대응해야 할 것인지를 잘게 검증하는 페이즈로서 루프를 짜 넣는다는 것이다.
여기서 중요한 것은, Plan·Code·Build·Test·Deploy·Operation·Monitor·Feedback이라는 각 페이즈에 "구체적인 성과물 → 리뷰"라는 흐름을 그대로 적용할 수 있다는 점이다. 즉, 단지 "구현 → 리뷰"라는 하나의 큰 루프만 보는 게 아니라, DevOps를 구성하는 각 페이즈마다 작은 "성과물 → 리뷰"의 루프를 만들고, 그 작은 루프의 집합체로서 DevOps 전체라는 큰 루프를 돌려 간다. 이것이야말로 루프 엔지니어링을 DevOps에 도입한다는 것의 본질이 아닐까 생각한다.
정리
여기까지, 루프 엔지니어링이라는 새로운 개발 스타일과 거기에 숨은 리스크, 그리고 DevOps로의 응용을 생각해 봤다.
루프 엔지니어링은, 사람이 프롬프트를 계속 치는 대신 AI를 자율적으로 달리게 하는 장치 그 자체를 설계한다는, 개발에서 추상도가 한 단계 위로 옮겨 가는 전환이다. 효율화의 가능성이 큰 한편, 리뷰까지 AI에게 맡겨 버리면 모르는 사이에 방향성이 어긋나 손쓸 수 없게 된다는 리스크를 구조적으로 안고 있다.
이 글에서 제안한 것은 크게 2가지 사고방식이다.
첫째는, 루프를 "구현 → 리뷰"라는 단일한 수준으로 파악하는 게 아니라, 요건 정의·설계·구현·테스트 각각에 작은 루프를 갖게 하고 그것을 기능마다 쌓아 간다는 발상이다. 지난 글에서 소개한 "AI 시대의 문서 구동 개발"로 로드맵을 깔고, 각 루프의 리뷰를 그 로드맵에 비추어 함으로써 드리프트의 발생 확률을 낮춰 갈 수 있다.
둘째는, 이 "작은 루프의 집합체"라는 사고방식을 DevOps 전체로 넓히는 것이다. Plan → Code → Build → Test → Deploy → Operation → Monitor → Feedback이라는 기존 DevOps 루프의 각 페이즈에 저마다 "성과물 → 리뷰"의 작은 루프를 짜 넣고, 그 집합체로서 큰 DevOps 루프를 돌려 간다. 기능별 루프가 완료될 때마다 AI가 자동으로 PR을 만들고 작게 배포까지 돌린다. 그런 장치가 앞으로 DevOps의 전제가 되어 가지 않을까 생각한다.
그리고 마지막으로, 실무에 루프 엔지니어링을 들일 때 내가 가장 중요하다고 생각하는 것은, AI를 특별 취급하지 않는 것이다. 티켓을 배정하고, 인식을 맞추고, 맡긴 범위 안에서 일하게 한다. 이것은 인간 동료에게 일을 의뢰하는 프로세스와 본질적으로는 다르지 않다.
루프라는 장치 그 자체는 중립이며, 그것을 살리는 것도 죽이는 것도 설계하는 사람 쪽에 달려 있다. 루프 엔지니어링을 DevOps에 대응시킨다는 것은, 결국 AI라는 새 팀 멤버를 어떻게 맞아들이고 어떻게 장치 안에 자리매김할 것인가 하는, 조직 만들기의 이야기이기도 하다고 생각한다.
이 글이 도움이 됐다면 추천해 주세요