AI 제품 개발 프레임워크: 불확실성 해결

소프트웨어를 개발하고 배포할 때 기업들이 채택하는 효과적이고 잘 정립된 프레임워크가 있습니다. 초기 단계 스타트업이든, 확장 중인 스타트업이든, 대기업이든 상관없이 조직에는 일관성과 효율성을 보장하기 위한 프로세스가 존재합니다(또는 존재하지 않을 수도 있습니다!). 이러한 프로세스는 회사의 상황에 따라 다르겠지만, 근본적인 목표는 동일해야 합니다: 제품과 고객에게 영향을 미치는 고품질 소프트웨어를 제공하는 것입니다.

대부분의 제품 팀은 일반적으로 다음과 같은 높은 수준의 흐름을 따르는 개발 프레임워크를 채택합니다:

• 기회 평가: 이 아이디어가 우리 제품과 고객에게 긍정적인 영향을 미칠 것이라고 느끼는가?
• 탐색: 문제를 깊이 탐구합니다. 솔루션을 설계하고 명세합니다. 이 단계에서는 PRD(제품 요구 사항 문서)가 완성되고, 제품 설계와 기술 사양/디자인도 진행되는 경우가 많습니다.
• 전달: 팀의 스프린트 또는 사이클에 작업 계획을 맞춥니다. CI/CD 파이프라인을 통해 구현하고 배포합니다. 이 과정을 반복합니다.
• 측정 및 반복: 고객 사용 지표를 기반으로 지속적으로 점진적인 개선을 제공합니다.

이러한 전통적인 제품 개발 사이클에서 팀은 잘 정립된 파이프라인과 프로세스를 활용합니다. 코드는 작성, 유닛 및 통합 테스트를 거쳐 비-프로덕션 및 프로덕션 환경에 배포됩니다. 이는 업계 표준이 된 CI/CD 파이프라인을 통해 이루어집니다. 여기서 중요한 점은 팀이 컨텍스트를 상당히 제어할 수 있다는 것입니다. 이는 입력 및 비즈니스 로직을 정의할 수 있으며, 높은 확률로 출력도 제어하거나 예측할 수 있다는 자신감을 제공합니다. 디자인 측면에서도 디자이너는 자신들이 설계하는 공간과 콘텐츠에 대한 확신을 가집니다. 버그가 발생하면(대부분의 경우) 신뢰성 있게 재현할 수 있으며, 긴급 수정이 적용되고 배포됩니다. 이러한 수준의 예측 가능성은 이제 표준이 되었으며, 동시에 팀이 자신 있게 제품을 제공할 수 있는 근본적인 기반이 되었습니다.

LLM은 단순한 기능이 아닙니다

제품이 이제 LLM(대규모 언어 모델)을 핵심으로 활용하면서, 기업은 개발 사이클에 LLM을 통합하는 방법을 조정해야 합니다. 제품을 구축하는 팀은 위에서 설명한 더 통제된 요소와 일치하지 않는 일련의 과제에 직면하고 있습니다. 전통적인 제품 개발 사이클을 적응시켜 LLM이라는 큰 블랙박스를 포함해야 합니다. 또한 특정 작업에 어떤 LLM을 사용할지 결정하는 문제도 있습니다.

팀이 익숙했던 통제 가능하고 예측 가능한 환경은 더 불확실한 환경으로 대체되었습니다. 입력과 출력 간의 관계가 항상 결정론적이지는 않습니다. LLM을 호출하는 단순한 기능조차도 이 변화를 감안해야 합니다. 동일한 프롬프트가 다른 응답을 생성할 수 있고, 사용자 입력은 더 다양하고 예측하기 어려우며, 팀이 처리해야 하는 컨텍스트도 크게 증가했습니다. LLM은 매우 강력하며 혁신의 속도는 놀랍지만, 팀은 LLM 기반 제품을 구축하고 테스트하고 측정하는 방식을 재고해야 합니다.

"느낌" 이상의 테스트

제품의 핵심 모델에 구성 변경을 도입하는 팀은 개발 라이프사이클의 어느 시점에서 다음과 같은 혼합 검증 방식을 도입합니다:

• 핵심 테스트 사례(또는 소수)를 수동으로 검토하고 결과를 확인
• 출력물을 스프레드시트에 붙여넣고 예제를 수동으로 조정
• 종종 해당 작업과 관련이 없는 업계 벤치마크와 결과 및 성능 비교

이러한 접근 방식은 결코 확장 가능하지 않습니다. 규모에 상관없이 작업하는 팀에게 위험하며, 개발 사이클에 상당한 불확실성을 도입합니다.

이전 게시물에서 우리는 백테스팅 인프라에 대해 이야기한 적이 있습니다. 이는 우리가 소프트웨어를 제공하는 방식에 큰 영향을 미쳤고 팀들이 이를 통해 제품 개발 라이프사이클을 개선하도록 이끌었습니다.

불확실성 제거

팀이 전통적인 소프트웨어 개발을 위해 CI/CD 파이프라인을 사용하는 것처럼, 실 데이터와 과거 데이터를 사용한 LLM 출력의 체계적인 테스트를 통합하는 것이 개발 프로세스의 핵심이 되어야 합니다. 백테스팅은 구성 변경이 제품에 미치는 영향을 팀이 자신 있게 평가할 수 있도록 합니다. 이는 프롬프트 변경, 모델 변경, 매개변수 조정의 형태로 이루어질 수 있습니다. 이러한 결과는 팀 전체, 더 나아가 잠재적인 비즈니스 결과에 영향을 미칩니다. ML 팀뿐만 아니라 제품 개발 팀의 모든 구성원이 백테스팅 결과를 검토하면서 혜택을 볼 수 있다는 사실을 확인했습니다.

개발 흐름

엔지니어가 구성 변경을 수행할 때, 과거와 실제 데이터의 하위 집합에 대해 로컬에서 백테스트를 실행할 수 있어야 합니다. 이 빠른 피드백 루프는 변화를 유도하고, 초기 사이클에서 잠재적인 문제를 잡아냄으로써 추측을 제거합니다.

CI/CD 통합

CI/CD 흐름의 일부로 팀은 과거 변경 사항의 하위 집합에 대해 광범위한 변경 사항을 테스트할 수 있습니다. 이는 변화가 결과에 미치는 영향을 더 넓은 비즈니스 관점에서 평가할 수 있도록 합니다. "지난달 데이터를 사용해 이 변경 사항을 테스트했더니 X만큼 증가했습니다."

프로덕션으로 가는 "느낌 없는" 경로

프로덕션에 배포하기 전에 ML 및 제품 리드는 비즈니스 결과에 대한 변경 사항의 영향을 자신 있게 평가할 수 있습니다. 프로덕션 트래픽 패턴에 대한 백테스팅은 팀에 완전한 확신과 자신감을 제공합니다. 또한 팀은 각 백테스트 후에 고품질 데이터셋을 확보하여 모델을 훈련하는 데 사용할 수 있습니다.

지속적인 모니터링

변경 사항이 프로덕션에 배포된 후 지속적인 백테스팅은 팀이 다음을 보장할 수 있도록 합니다:

• 모델 성능과 출력의 저하에 대한 가시성
• 테스트 중 확인되지 않은 엣지 케이스에 대한 가시성
• 시간 경과에 따른 성능 추적 능력

자신감을 갖고 제공하기

LLM이 단순한 기능이 아니라 제품의 핵심으로 자리잡으면서 팀은 테스트와 측정 방식을 조정해야 합니다. LLM이 계속 발전하고 새로운 모델이 등장함에 따라 체계적인 백테스팅 인프라를 갖추는 것은 단순히 선택 사항이 아니라 개발 라이프사이클의 필수 요소가 되었습니다:

• 엔지니어는 자신감을 가지고 더 빠르게 반복할 수 있습니다.
• 제품 팀은 단순한 느낌을 넘어 데이터 기반으로 변경 사항을 결정합니다.
• ML 엔지니어는 스프레드시트를 검토하는 대신 개선 작업에 집중할 수 있습니다.
• 비즈니스 리더는 변경 사항의 영향을 명확히 파악하여 실제 ROI를 확인할 수 있습니다.

우리는 팀이 "이게 효과가 있을 것 같다"라는 사고방식에서 "이게 효과가 있을 것이라는 것을 알고 있다!"라는 사고방식으로 전환하는 것을 직접 목격했습니다.