AI 네이티브 제품 엔지니어링: 소프트웨어 제품의 변화

수십 년 동안 소프트웨어 제품은 명시적인 지침을 중심으로 구축되었습니다.

사용자가 버튼을 클릭했습니다. 애플리케이션은 미리 정의된 논리를 따랐습니다. 데이터베이스는 정보를 반환했습니다. 시스템은 예측 가능한 결과를 산출했습니다.

이 모델이 변화하고 있습니다.

현대 소프트웨어는 자연어를 이해하고, 문서를 해석하며, 콘텐츠를 생성하고, 대규모 지식 기반을 검색하며, 결정을 추천하고, 워크플로우를 자동화하며, 점점 더 다른 시스템 전반에 걸쳐 행동을 취할 수 있습니다.

AI는 더 이상 제품 외부의 실험적 기능으로 머물러 있지 않습니다.

그것은 제품 아키텍처 자체의 일부가 되고 있습니다.

이러한 변화는 소프트웨어를 구축하는 새로운 접근 방식을 만들어내고 있습니다: AI 네이티브 제품 엔지니어링(AI-native product engineering).

AI 네이티브 제품 엔지니어링이란 AI를 단순히 애플리케이션을 만든 후에 추가되는 부가 기능이 아니라, 핵심 제품이자 공학적 역량으로 간주하여 소프트웨어 제품을 설계하고 구축하는 과정입니다.

이는 기술 스택 이상의 것을 변화시킵니다.

팀들이 제품 경험, 데이터, 아키텍처, 테스트, 보안, 비용, 관찰 가능성(observability), 심지어 소프트웨어가 무엇을 할 수 있는지에 대한 사고방식을 바꿉니다.

스타트업에게 AI 네이티브 엔지니어링은 완전히 새로운 제품 카테고리를 구축할 기회를 만듭니다.

기업들에게는 단순히 또 다른 챗봇을 추가하는 것이 아니라, 지능(intelligence)을 중심으로 기존 제품과 워크플로우를 재구상할 기회를 제공합니다.

하지만 이러한 제품을 구축하려면 다른 엔지니어링 사고방식이 필요합니다.

AI 네이티브 제품 엔지니어링이란 무엇인가?

AI 네이티브 제품 엔지니어링은 전통적인 제품 엔지니어링에 신뢰할 수 있는 AI 기반 제품을 구축하는 데 필요한 추가 시스템들을 결합한 것입니다.

전통적인 제품 엔지니어링 역시 여전히 중요합니다.

애플리케이션에는 프론트엔드 인터페이스, 백엔드 서비스, API, 데이터베이스, 인증(authentication), 클라우드 인프라, 보안, 테스트 및 모니터링이 필요합니다.

AI는 이러한 기반 시설을 대체하지 않습니다.

그것은 또 다른 엔지니어링 계층을 추가할 뿐입니다.

AI 네이티브 제품은 모델(models), 검색 시스템(retrieval systems), 임베딩(embeddings), 벡터 검색(vector search), 프롬프트 관리(prompt management), 모델 라우팅(model routing), 평가(evaluation), 가드레일(guardrails), AI 관측 가능성(AI observability), 도구 통합(tool integrations), 그리고 에이전트 오케스트레이션(agent orchestration)을 필요로 할 수도 있습니다.

따라서 제품은 결정론적 소프트웨어와 확률적 AI 시스템의 조합이 됩니다.

이 구분이 중요합니다.

AI 네이티브라는 것이 제품의 모든 부분이 AI를 사용한다는 의미는 아닙니다.

이는 지능(intelligence)이 제품의 특정 부분에 의도적으로 설계되어 의미 있는 가치를 창출하는 것을 의미합니다.

AI 네이티브가 챗봇 추가만을 의미하지는 않는다

AI 네이티브 제품 엔지니어링을 오해하기 쉬운 가장 쉬운 방법 중 하나는 이를 대화형 인터페이스(conversational interfaces)와 동일시하는 것입니다.

어떤 회사는 기존 애플리케이션에 AI 챗봇을 추가할 때, 근본적인 제품 자체를 크게 변경하지 않을 수 있습니다.

이것 역시 여전히 유용할 수 있습니다.

하지만 반드시 그 제품을 AI 네이티브로 만들지는 않습니다.

프로젝트 관리 플랫폼을 고려해 봅시다.

플랫폼 사용 방법에 대한 질문에 답하는 챗봇을 추가하는 것은 AI 기능입니다.

시스템이 프로젝트 활동을 이해하고, 위험을 식별하며, 진행 상황을 요약하고, 우선순위를 추천하며, 작업을 생성하고, 기록을 업데이트하고, 워크플로우를 조정할 수 있도록 허용하는 것이 제품을 훨씬 더 깊게 변화시킵니다.

AI는 더 이상 소프트웨어 옆에 놓인 인터페이스가 아닙니다.

소프트웨어가 작동하는 방식의 일부가 됩니다.

이것이 바로 AI 네이티브 제품 엔지니어링 뒤에 숨겨진 더 큰 기회입니다.

소프트웨어는 인터페이스에서 의도(Intent)로 이동하고 있다

전통적인 애플리케이션은 사용자가 제품이 어떻게 작동하는지 배워야 합니다.

사용자는 메뉴를 탐색하고, 필터를 적용하며, 양식을 작성하고, 규칙을 구성하고, 화면 사이를 이동합니다.

AI는 또 다른 상호작용 모델을 도입합니다.

사용자들은 원하는 바를 수동으로 필요한 모든 단계를 제어하는 대신 점점 더 표현할 수 있게 됩니다.

분석 플랫폼에서 여러 필터를 설정하는 대신, 사용자는 다음과 같이 질문할 수 있습니다:

제품은 요청을 해석하고, 관련 정보를 검색하며, 분석하고, 답변을 제시할 수 있습니다.

이러한 인터페이스 중심 소프트웨어에서 의도 중심 소프트웨어로의 전환은 디지털 제품 디자인에서 가장 중요한 변화 중 하나가 될 수 있습니다.

인터페이스가 사라지지는 않을 것입니다.

하지만 AI는 사용자가 가치를 받기 전에 이해해야 하는 제품 복잡도를 줄여줄 수 있습니다.

AI는 기능이 될 수 있는 것을 바꾼다

전통적인 기능은 보통 명시적으로 프로그래밍된 동작을 중심으로 구축됩니다.

제품에 새로운 워크플로우가 필요하다면, 엔지니어들은 조건, 인터페이스, 비즈니스 로직 및 출력을 정의합니다.

AI는 소프트웨어가 처리할 수 있는 범위를 확장합니다.

이제 기능은 미리 정의된 필드에 깔끔하게 들어맞지 않는 정보와도 함께 작동할 수 있습니다.

문서, 대화, 이미지, 이메일, 지식 기반 및 기타 비정형 정보가 제품 경험의 일부가 될 수 있습니다.

상업 보험 플랫폼을 고려해 봅시다.

전통적인 소프트웨어는 직원이 제출된 문서에서 정보를 수동으로 추출하여 구조화된 필드에 입력하도록 요구할 수 있습니다.

AI 네이티브 워크플로우는 문서를 해석하고, 관련 정보를 식별하며, 기존 기록과 비교하고, 누락된 세부 사항을 강조 표시하며, 인간의 검토를 위해 케이스를 준비할 수 있습니다.

근본적인 비즈니스 문제는 변하지 않았습니다.

그것을 해결하는 소프트웨어 방식이 바뀐 것입니다.

제품 팀은 모델이 아닌 문제에서 시작해야 한다

강력한 AI 모델의 가용성은 기술로 제품 개발을 시작하려는 유혹을 만듭니다.

"LLM으로 무언가를 만들어야 합니다."

"AI 에이전트가 필요합니다."

"생성형 AI를 추가해야 합니다."

이것들은 제품 전략이 아닙니다.

AI 네이티브 제품 엔지니어링은 좋은 제품 엔지니어링과 동일한 근본적인 질문, 즉:

우리가 해결하려는 문제는 무엇인가?

고객 지원 팀이 복잡한 요청에 답변하기 전에 계정 기록을 읽는 데 상당한 시간을 소비한다고 가정해 봅시다.

문제는 AI 챗봇의 부재가 아닙니다.

문제는 고객의 맥락(context)을 이해하는 데 필요한 시간입니다.

AI는 계정 정보를 검색하고, 이전 상호작용을 요약하며, 관련 문서를 찾고, 다음 조치를 제안함으로써 도움을 줄 수 있습니다.

문제를 정의하는 것부터 시작하는 것이 모델을 먼저 만들고 어디에 사용할지 찾는 것보다 더 나은 제품을 만듭니다.

아키텍처는 두 가지 유형의 논리를 갖게 됨

전통적인 소프트웨어는 주로 결정론적 논리(deterministic logic)에 의존합니다.

만약 고객이 특정 조건을 충족하면, 정의된 작업을 수행한다.

이러한 유형의 논리는 여전히 필수적입니다.

결제, 인증, 권한, 계산, 계정 업데이트 등 많은 다른 작업들이 예측 가능한 동작을 필요로 합니다.

AI는 확률론적 논리(probabilistic logic)를 도입합니다.

모델은 언어를 해석하거나, 정보를 분류하거나, 콘텐츠를 요약하거나, 추천을 생성하거나, 가능한 다음 단계에 대해 추론할 수 있습니다.

이러한 기능들은 모든 가능한 입력과 출력이 수동으로 프로그래밍될 필요가 없기 때문에 강력합니다.

하지만 이들이 모든 곳에서 결정론적 논리를 대체해서는 안 됩니다.

강력한 AI 네이티브 아키텍처는 이 두 가지를 결합합니다.

해석, 추론, 생성 또는 유연성이 가치를 창출하는 곳에 AI를 사용하고,
정확성과 예측 가능성이 더 중요한 곳에는 결정론적 소프트웨어를 사용해야 합니다.

이 두 시스템 사이의 경계를 설계할 수 있는 능력이 점점 중요해지는 제품 엔지니어링 역량이 되고 있습니다.

데이터가 제품 경험의 일부가 됨

AI 네이티브 제품은 맥락에 크게 의존합니다.

일반적인 모델은 언어를 잘 이해할 수 있지만, 고객, 제품 카탈로그, 정책, 문서, 워크플로우 또는 비즈니스 이력 등 사용자의 상황을 자동으로 이해하지는 못합니다.

그 정보는 데이터에서 나옵니다.

이로 인해 데이터 기반이 제품 아키텍처의 일부가 됩니다.

제품 팀은 중요한 정보가 어디에 있는지, 얼마나 신뢰할 수 있는지, 누가 접근할 수 있는지, 그리고 얼마나 빨리 변경되는지 이해해야 합니다.

강력한 데이터 엔지니어링 서비스는 데이터베이스, 애플리케이션, 문서, 분석 플랫폼 및 AI 시스템 전반에 걸쳐 정보를 접근 가능하게 만드는 데 도움을 줄 수 있습니다.

많은 회사들에게 있어 AI 네이티브 제품의 가장 큰 장벽은 모델 역량이 아닐 것입니다.

그것은 파편화된 데이터일 것입니다.

RAG가 AI와 비즈니스 지식을 연결하다

검색 증강 생성(Retrieval-augmented generation), 즉 RAG는 AI 네이티브 제품을 위한 중요한 아키텍처 패턴이 되었습니다.

모델이 학습하는 내용에 전적으로 의존하기보다는, RAG 시스템은 승인된 지식 출처에서 관련 정보를 검색하여 이를 모델의 컨텍스트로 제공합니다.

이를 통해 AI가 회사별 정보와 함께 작업할 수 있도록 도움을 줄 수 있습니다.

예를 들어, 기업 비서가 질문에 답하기 전에 제품 문서, 정책, 계약 또는 고객 기록을 검색할 수 있습니다.

하지만 프로덕션 RAG는 단순히 벡터 데이터베이스를 LLM에 연결하는 것만은 아닙니다.

엔지니어링 팀은 인제스천(ingestion), 청킹(chunking), 메타데이터, 검색 품질, 권한, 문서 최신성(document freshness), 재순위 지정(reranking), 출처 표기(citations), 그리고 평가를 고려해야 합니다.

만약 검색에 실패하면 모델은 잘못된 컨텍스트를 받을 수 있습니다.

따라서 AI 제품의 품질은 모델 주변의 전체 정보 시스템에 달려 있습니다.

AI 에이전트가 제품을 답변에서 행동으로 이동시키다

생성형 AI는 처음에 소프트웨어가 어떻게 질문에 답하고 정보를 생성할 수 있는지 변화시켰습니다.

AI 에이전트는 또 다른 변화를 가져옵니다.

그것들은 잠재적으로 행동을 취할 수 있습니다.

에이전트는 정보를 검색하고, API를 호출하며, 기록을 업데이트하고, 문서를 생성하거나, 작업을 예약하거나, 여러 시스템에 걸쳐 여러 단계를 조정할 수 있습니다.

고객이 여행 플랫폼에 다가오는 여행 일정 변경을 요청한다고 상상해 보세요.

기존 비서는 재예약 정책을 설명할 것입니다.

에이전트 기반 제품은 예약을 식별하고, 사용 가능한 대안을 검색하며, 변경 사항을 계산하고, 확인을 요청하고, 연결된 시스템을 통해 승인된 단계를 실행할 수 있습니다.

이는 AI가 단순히 정보를 제공하는 수준을 넘어 워크플로우에 참여하게 만듭니다.

이러한 역량을 구축하려는 기업들은 AI 에이전트 개발 서비스를 통해 도구, 권한(permissions), 검증(validation), 인간의 승인(human approval), 그리고 감사 가능성(auditability)에 대해 신중하게 생각해야 합니다.

에이전트가 할 수 있는 일이 많아질수록 통제(control)의 중요성은 더욱 커집니다.

소프트웨어가 불확실할 때 사용자 경험의 변화

기존 소프트웨어는 보통 확실성을 전달합니다.

버튼은 작동하거나, 아니면 작동하지 않습니다.

데이터베이스에는 값이 있거나, 그렇지 않습니다.

AI 시스템은 다르게 행동합니다.

요청을 오해하거나, 불완전한 정보를 제공하거나, 신뢰도(confidence) 수준이 다른 답변을 생성할 수 있습니다.

이는 제품 디자인을 변화시킵니다.

AI 네이티브 UX는 사용자에게 시스템이 무엇을 알고 있는지, 정보가 어디에서 왔는지, 어떤 행동을 계획하고 있는지, 그리고 언제 인간의 검토가 적절한지 이해하도록 도와야 합니다.

예를 들어, 기업 지식 비서(knowledge assistant)는 답변과 함께 출처(citation)를 제공할 수 있습니다.

문서 처리 시스템은 검토를 위해 추출된 필드를 강조 표시할 수 있습니다.

에이전트는 금융 변경을 가하기 전에 확인을 요청할 수 있습니다.

좋은 AI UX는 불확실성이 존재하지 않는 척하지 않습니다.
사용자가 이해하고 신뢰할 수 있는 방식으로 불확실성을 관리합니다.

평가가 소프트웨어 테스트의 일부가 되다

전통적인 QA(Quality Assurance)는 애플리케이션이 예상된 요구사항에 따라 작동하는지 여부를 묻습니다.

AI는 또 다른 질문을 추가합니다:

결과가 얼마나 좋았는가?

AI 기능은 기술적으로 유효한 응답을 반환하면서도 사용자에게 실패할 수 있습니다.

고객 지원 비서는 유창하지만 부정확한 안내를 생성할 수 있습니다.

RAG(Retrieval-Augmented Generation) 시스템은 쿼리와 관련이 있지만 실제로는 유용하지 않은 정보를 검색할 수 있습니다.

에이전트는 요청된 작업을 완료했지만, 비효율적인 일련의 행동을 선택할 수 있습니다.

따라서 AI 네이티브 제품 엔지니어링은 전통적인 테스트와 함께 평가(evaluation)가 필요합니다.

팀은 답변 품질(answer quality), 검색 관련성(retrieval relevance), 작업 완료율(task completion), 도구 선택(tool selection), 지연 시간(latency), 비용(cost), 안전성(safety) 및 기타 제품별 기준을 측정할 수 있습니다.

평가는 출시 전에만 이루어져서는 안 됩니다.

모델의 동작, 프롬프트, 검색 시스템, 데이터, 사용자 행동 모두 시간이 지남에 따라 변합니다.

따라서 평가는 프로덕션 환경에서도 계속되어야 합니다.

AI 제품은 더 나은 관측 가능성(Observability)이 필요하다

전통적인 소프트웨어 모니터링은 인프라와 애플리케이션 동작에 초점을 맞춥니다.

팀들은 가동 시간(uptime), 지연 시간(latency), 오류(errors), 데이터베이스 성능, API 실패 및 리소스 사용량을 모니터링합니다.

AI 네이티브 제품은 또 다른 계층에 대한 가시성이 필요합니다.

어떤 모델들이 사용되고 있습니까?

모델 호출에 얼마나 시간이 걸립니까?

얼마나 비용이 발생합니까?

어떤 컨텍스트가 검색되었습니까?

에이전트는 어떤 도구를 호출했습니까?

사용자들이 AI 생성 결과를 어디서 수정하고 있습니까?

어떤 프롬프트나 워크플로우가 가장 자주 실패합니까?