마땅한 AI 방법론이 필요한 이유
AI-DLC 개발 방법론
AI 가 발전하면서 가장 크게 체감하는 것은 정보의 접근성이다. 신뢰도를 일부 희생하는 대신 정보의 탐색과 가공에 그리 많은 시간을 쓰지 않는다. 모델 별 확증편향이 발생하기도 하니, 신뢰도를 그리 높게 평가하긴 아직은 어렵다. 무료 플랜 또한 꽤나 괜찮은 성능을 보여주기에 많은 사람들은 AI를 다양한 산업에 앞다투어 활용하기 시작했고, 소프트웨어 산업이 개중 선두를 맡고 있다. 주변 개발자 중 AI 를 활용하지 않는 사람을 이제는 더이상 찾아볼 수 없다.
어떻게 활용하고 있는지를 물어보면, 다양한 답변들이 있다. 그 만큼 성숙하고 있는 기술이며 내부를 볼 수 없는 블랙박스에 가깝고 그 자체로도 꽤나 괜찮(다고 느끼)기 때문이다. 비교 대상이 없으니 얼마나, 어떻게 해야 좋은지 알 수 있을 리가 없다. 실제 AI 를 활용하는 제품 개발 조직도 획일화된 방식을 갖춘 곳이 많지 않다. 월 $200 플랜을 결제하고 자유롭게 쓰게하는 조직부터, 자체적 in-house 모델 혹은 시스템을 개발하여 사용하는 조직, 심지어 AI 도입을 아직 검토중인 조직 또한 필경 존재한다.
이런 조직들이 가진 고민들은, 몇 가지 공통된 키워드로 귀결된다.
관리 용이성. 관리자들은 각 직원들에게 월 $200 씩 소비하고 있는데, 그에 상응하는 성과를 내고 있는지 알 수가 없다. 비싼 비용이지만, 해주지 않으면 내부 구성원의 불만이 적지 않다. 다른 경쟁사들 보다 뒤쳐지진 않을지 걱정되는 마음 또한 있다.
예측 가능성. 모델을 활용하여 제품을 개발할 때, 모델에 따라 결과물의 편차가 크다는 피드백이 적지 않다. 좋은 모델을 쓰지 않으면 결과물이 좋은 품질을 갖추지 못한다는 말을 하지만, 언급되는 모델들은 피드백마다 다르다. 결국 모델의 문제가 아니라, 누가/언제/어떻게 이용하는지가 문제라는 것이다. 결국 회사가 해결해야하는 문제들은 늘 복잡하고 누가/언제/어떻게 이용하는지는 늘 변화하기에, 목표하는 품질이 나올 때 까지 끊임없이 실패해야한다. 언제 성공할지 모르니, 예측하기가 매우 어렵다.
유지보수 용이성. 어떻게든 결과물을 만들어 냈는데, 이것을 유지보수 하자니 엄두가 나질 않는다. 무엇을 목표로 어떤 것들을 포기했는지 모르기에, 결국 기존 기능을 바탕으로 처음부터 다시 만든다. 하지만 개발자는 이미 알고있다. 다음에도 이것이 반복될 것이라는 것을.
언급하진 않았지만 파생되는 문제점들 또한 많다. 개발자는 언제 결과물이 완성될지 모르니 일정을 소통하기 어려워 하며, PM/PO 는 산출물의 기대 품질을 설정하기 어렵다. 관리자들은 제품 개발을 도와주기 위해 AI 를 도입했는데, 오히려 AI로 인해 새로운 어려움에 직면한다.
우로보로스를 아시나요기존의 소프트웨어 개발 방법론 자체가 이전의 제조업에서 출발했고, AI 또한 워낙 급진적으로 발전했기에 큰 도움이 되진 않는다. 속도가 느리고 일정한 품질을 보장하기 위해 초점을 맞추는 방식은 빠른 호흡의 도구인 AI 와는 잘 맞지 않기 때문이다. (이에 관련된 내용은 AWS Blog 글에 첨부된 백서에도 자세히 나와있으니, 시간이 허락한다면 꼭 읽어보기를 권한다.)
the evolution of software development methods has mirrored the evolution in manufacturing paradigms
여기서 말하는 방법론이 다른 그 무엇보다 좋다거나 절대적으로 높은 성능을 보인다는 말이 아니다. 장인에게 도구는 많을수록 좋으며, 장인은 범인(凡人) 보다 그 도구의 사용처를 더 깊이 이해하고 있을 뿐이다. 망치를 손에 쥐면 모든 게 못으로 보인다. 그러니 최대한 여러 도구와 방법론을 이해하고, 그것을 문제에 맞게 활용하는 것이 대 AI 시대에 필요한 역량이다. 그러니 무엇이 되려고 하기보다, 무엇을 할 수 있는지에 집중하자. 나사는 망치로 풀리지 않는다.
방법론도 결국 하나의 도구에 지나지 않는다. 그리고 도구를 설파하려면 지금 당신의 손에 들려진 그것보다 어떻게 다르고 개선되는지를 마땅한 까닭을 들어 설명해야하고, 당신이 공감하는 가치를 제공할 수 있어야 한다. 당신과 나는 기존의 방식이 가진 본질적 단점들을 따져 물어볼 것이며, 서로가 생각하는 단점이 닿는 순간 나는 이미 절반 정도 성공이라 생각한다.
AI 활용의 가장 대표격인 바이브 코딩을 살펴보자. 내가 만들고 싶은 제품(혹은 기능)의 설명을 모델에게 입력한다. 모델은 사전에 입력된 프롬프트에 따라 모호한 부분을 해석하거나 임의로 결정하고 유저에게 승인을 요구한다. 최대한 빨리 결과물을 보고 싶은 유저는 곧바로 진행해달라고 하고, 코드가 실패하면 고치라고 한다. 이를 성공할 때까지 반복하고, 반복한다. N면체 주사위를 주고 M개의 수열이 나올 때 까지 던지는 것과 비슷하다. N 은 모델의 성능이고 M은 문제의 복잡도다.
이 비유를 떠올리면 앞서 언급한 문제점들이 연상된다. 언제 나올지 모르니 일정을 산정하기 어렵고, 어떠한 순서로 모르며 어떤 숫자가 나올지도 모른다. 관리자는 꽤 좋은 주사위를 사주었다고 생각했지만, 그것이 정확히 어떤 도움을 주고 있는지는 아무도 모른다. 혹자는 전혀 무작위가 아니라며 MCP 나 Skills 를 언급할 수도 있겠지만, 그것은 내가 말하고자 하는 내용이 아니다. MCP 가 무엇이고 어떤 이점이 있으며 Skills를 언제 왜 써야하는지를 모른채로 대중의 평가에 이끌려 사용한다면 그 또한 무작위 시도의 본질은 같다.
이것이 전혀 나쁜 것만은 아니다. 시도하는 비용이 저렴하고 목표하는 바가 복잡하지 않으면 충분히 가치있는 방식이다. 육면체 주사위로 두 개의 숫자만 찾아야하는 상황이라면, 빠르게 던지기 시작하는 것이 기댓값 측면에서 훨씬 합리적인 선택이다. 여느 방식보다 간단하고 빠르게 실패할 수 있고 심지어 내가 구체화 하지 않았던 무언가를 그 과정 속에서 찾기도 한다. 하지만 당신이 엔터프라이즈 급 제품을 대규모 조직에서 기여하는 상황이라면 이야기는 달라진다. 가진 것은 똑같은데 관리자는 더 긴 수열을 요구하기 시작한다. (그리고 실패하다보면, 윈도우가 다 소진되었다는 말과 함께 제멋대로 결과를 축소하기 시작한다.)
높은 기회비용과 높은 복잡도를 가진 환경에서는 바이브코딩의 한계가 여실히 드러난다. 그 반대의 가치(장점)과 단점을 가진 방법론이 필요한 이유 또한 바로 그 한계 때문이다.
AI-DLC 는 최대한 시도하지 않기 위한 방법론이다. 바이브코딩은 성공할 때 까지 빠르게 시도하겠다는 접근법이고, AI-DLC 는 시도하기 전 유저의 의도와 맥락을 질문을 통해 파악하는 접근법이다. 방법론을 체험할 수 있는 AWS 워크샵에서도, 실제 코드 생성은 전체 시간 중 20%를 넘게 차지하지 않는다. 코드를 생성하기 전까지 사람은 질의응답을 반복하는 것이 워크샵의 대부분을 차지한다.
반복되는 질문은 처음엔 느리게 느껴질 수 있어도, 그것이 담보하는 가치는 결코 작지 않다. 원하는 기획을 정의하고, 기술적 구현을 설계하며 놓친 부분이 없는지 확인한다. 모든 과정은 마크다운 문서로 저장되며 파일 시스템에 영구히 저장된다. 이 과정에서 생성된 문서들은 지식창고(Knowledge Base) 로 활용된다. 질문을 통해 내가 바라보는 시선과 모델이 가진 정보의 초점을 맞추어야한다. 우리가 명확히 제공하지 않을 수록, 모델은 학습된 추론 가중치의 평균값에 가까운 대답만 생성한다. 우리가 의도된 값이 생성될 수 있도록 확률을 높여야하며, AI-DLC 방법론은 유저와의 질의응답과 그로부터 생성된 문서들을 통해 이를 달성할 수 있도록 제안하는 방법론이다.
대답하는 과정이 길어지다보면 실수가 생길 수도 있다. 혹은 착오로 인해 설계를 바꿔야 하는 경우일 수도 있다. 당황할 필요가 없다. 응답했던 결정은 비가역적이지 않기에 그저 현재의 과정에서 현재의 결정을 표기하고, 바뀐 결정으로 인해 맞지 않는 부분을 찾아달라는 요청을 하면 된다. 거기서 또 모호함이 생긴다면, 해왔던 대로 다시 답변하면 된다.
무턱대고 "질문의 양을 늘려서 성공적 실행에 필요한 정보를 제공받을 확률을 높인다"는 것만이 유일한 가치는 아니다. 또다른 주안점으로 "어떻게" 질문을 하는지, "누가" 질문을 하는지 또한 빠질 수 없다. AI-DLC 가 어떤 기준으로 질문을 하는지 실제 AI-DLC toolkit 을 이용해 프로젝트를 진행한 질문들과 함께 살펴보자.
AI-DLC 가 진행되는 방식은 크게 세 가지로 나누어지며, 다음과 같다.
Inception(Mob Elaboration) 에서는 제품의 기획을 구체화 하는 단계다. 만약 기존 제품이 있다면 분석하는 과정이 여기에 포함된다. 모델이 읽기 시작할 정보의 시작점을 최대한 나와 가깝게 설정해야, 산출물이 내가 목표한 바와 비슷하게 생성될 확률이 높아지기 때문이다. AI-DLC 에서는 7개의 카테고리를 통해 유저에게 질문을 던진다. (Github 링크)
파일의 순서와 진행 순서는 무관합니다.각 프롬프트 파일은 모호성을 줄이기 위해 구성된 주제들을 가진다. 일례로 story-generation-plan.md 를 살펴보면 요구사항을 유저 스토리 (Acceptance Criteria) 형태로 변환하는 프롬프트를 갖고 있음을 알 수 있다.
위와 같이 질의 응답을 설정하면, 아래와 같은 결과물이 생성된다.
앞선 단계들을 진행하면서 답변을 어떻게 제공했는지에 따라 유저 스토리가 달라진다. Lucidity 와 Verbosity 사이에서 많은 줄다리기가 일어나고, 이때 유저의 Scoping 역량에 따라 퀄리티가 나뉘게 되는 것을 볼 수 있었다. 사람의 집중력은 한정적이기에, 얼마나 Deep Dive 할지, 모호함을 감수할지에 대해 직관이 참여하는 모습을 볼 수 있었고 그에 따라 첨예한 차별성을 갖게 된다.
한 가지 팁으로, Inception 단계에서 프로젝트의 Scope 을 정해야한다면, 현재 팀의 상황을 넣는 것도 적절한 방안이 될 수 있었다. 팀원 수(혹은 구성까지)를 제공하고 적절한 범위를 결정해야한다는 프롬프트를 넣게 되면, 만들어낸 결정 별 예상되는 공수 또한 제공받을 수 있었다. Inception 단계에서 팀의 리소스 상황에 대해 제공한 상태에서, Contruction 단계의 질문을 살펴보자.
질문의 분야에서도 알 수 있듯, Construction 에서는 Inception에서 구체화한 기획을 기술적 구현으로 전환하는 단계다. 유저가 생각하는 결과물을 모델이 받아들이고, 모델이 생성하는 결과물을 반대로 유저에게 설명한다. 유저가 의사결정에서 멀어지지 않도록 하면서, 물리적 반복 작업만 모델에게 맡긴다. AI-DLC 에서는 설계 문서와 태스크 분해를 통해 이 과정을 진행한다.
공수의 값이 일정 자체를 의미하진 않지만, (2.0 공수가 2일을 의미하지 않음.) 주어진 옵션들을 정량적 비교가 가능케 함으로써 더 수월한 선택을 할 수 있도록 돕는 것이 인상적이었다. 진행되는 모든 선택들은 별도 디렉토리(기본값 `aidlc-docs`)에 저장되며, 추후 다른 프로젝트를 진행할 때 활용할 수 있도록 저장된다.
질의응답을 마무리하고 나면, 지금까지 작성한 질의응답이 Organizated 된 문서로 정리된다. 앞서 언급했던 Knowledge Base 를 활용할 수 있는 문서들이 바로 여기서 생성된 문서다. 반복되는 Iteration 을 통해 적재되는 문서들은 결국 상세한 히스토리를 가지며 결과적으로는 Inception 을 더 효율적이고 간단하게 만들어준다.
실제로 AI-DLC 를 세 차례만 반복해도, 각 Phase 별 소요되는 시간이 괄목할 만큼 줄어드는 것을 알 수 있다. 기존에 결정한 사항들을 바탕으로 변경되지 않은 가치는 유지하고, 새로운 요구사항이 필요로 하는 변경들만 확인하게 되어 질문의 수 또한 줄어든다. 1. 기존에 만들어낸 사항들을 정리된 문서의 형태로 저장하고 2. 사람의 개입 없이 자동으로 정리하는 것이 AI-DLC 의 핵심 가치다.
예측 가능성을 위해 유저의 의도를 깊이, 다양한 각도에서 해석하는 과정이 Inception 이다. 해석된 유저의 Intention 은 더 이상 숨겨지지 않은 상태로 유저에게 관측되며, 이는 문제의 모호성을 최소화 함으로써 예측 가능한 일정/품질을 만들어낼 수 있는 거름이 된다.
유지보수 용이성을 위해 모델의 최종 생성 형태를 제어하는 과정이 Construction 이다. 더 이상 결과물을 모델만 해석하고 이해할 수 있는 블랙박스로 두는 것이 아니라, 직접 유저가 참여하고 관여하여 유지보수가 용이하도록 한다. 물리적 반복성을 띠는 작업들만 모델이 하도록 하고, 유저가 의사결정으로 부터 멀어지지 않도록 Systematically 제한한다. 유저는 자신의 결정을 검열하고 메타인지에 신경을 쓰는 것이 아닌, 모델이 제공하는 질의응답에 집중하기만 하면 된다.
소요된 시간이 축적된 지식이 되고, 예측 가능성과 유지보수를 용이하기 위해 소요한 시간은 점점 단축된다. 명문화된 기준에 따라 분류된 Unit은 정량적인 비교가 가능한 과업이 되고, 조직의 경험이 녹아들면서 측정 가능한 수준이 된다. 이러한 선순환을 통해 관리 용이성이 확보된다.
주사위를 던지기 전에, 먼저 질문을 던져보자.
여기까지 AI-DLC 방법론이 제시하는 가치에 대해 이야기하고 기존 방식과 대조하며 언제, 어떻게 더 좋은지에 대해 다루었다. 미처 다루지 못한 부분, 가령 어떤 도구를 선택해야하는지나 협업은 어떻게 이루어져야 하는지 등이다. 혹시 관심이 생긴 엔터프라이즈가 있다면, 담당 아마존 SA 에게 문의해보길 권한다.