AI로 구현이 쉬워질 때, 제품은 무엇으로 선택받을까?

작은 스튜디오를 위한 예약 서비스를 만든다고 가정해 봅시다. 시간대 선택, 정보 입력, 알림 발송, 그리고 주인이 일정을 확인할 수 있는 관리 화면까지, 필요한 기능을 AI에 설명합니다. 이런 요구가 하나씩 조작 가능한 화면으로 바뀌면, 멀게만 느껴지던 제품이 윤곽을 드러내기 시작합니다.

그런데 화면을 본 주인은 이렇게 물을지도 모릅니다. “손님이 갑자기 시간을 바꾸면, 여전히 세 군데를 각각 수정해야 하나요?”

이 질문은 제품을 현장으로 되돌려 놓습니다. 화면은 작동하지만 일이 편해지지는 않았을 수 있습니다. 아래 스튜디오는 생각을 전개하기 위한 가상의 사례입니다. AI로 구현의 일부가 쉬워질 때, 제품은 자신의 존재 이유를 어떻게 다시 설명해야 할지 이 사례를 통해 이야기하려 합니다.

코드가 무대 뒤로 물러날 때, 누구의 관심이 달라질까?

대부분의 사용자에게 코드는 늘 무대 뒤에 있었습니다. 사용자는 원래부터 예약을 완료할 수 있는지, 정보를 찾을 수 있는지, 일을 끝낼 수 있는지에 관심이 있었습니다. 이런 필요는 생성형 AI 이전부터 존재했고, 도구가 바뀐다고 저절로 달라지지 않습니다.

새로운 변화는 만드는 사람 쪽에서 일어납니다. 일부 작업에서는 예전처럼 요구를 코드로 하나씩 옮기기 전에, 먼저 자연어로 설명한 뒤 실행 결과와 화면, 피드백을 보며 수정할 수 있게 되었습니다. 따라서 관심을 매 단계의 작성 방법에서 무엇을 만들지, 결과가 기대에 맞는지, 어디에 개입해야 하는지로 옮길 여지가 생깁니다.

저는 이 이동을 “AI가 코드를 가린다”라고 표현합니다. 가려지는 것은 구현 과정의 일부이며, 그 아래의 데이터 구조, 실행 조건, 오류는 그대로 존재합니다. 결과가 기대와 다르면, 만드는 사람은 문제가 어느 계층에 있는지 판단하고 그 추상화 계층을 열어 볼 수 있어야 합니다.

이 변화에는 놓치기 쉬운 전제가 있습니다. 무엇을 완료로 볼지 알아야 한다는 점입니다. “예약 시스템을 만들어 줘”라고 말하기는 쉽습니다. 하지만 마지막 한 자리를 두 사람이 동시에 예약할 때 어떤 일이 일어나야 하는지 설명하기 시작하면 제품의 경계에 닿게 됩니다. 요구사항의 빈칸은 결국 누군가의 판단이나 어떤 시스템 동작으로 채워집니다.

구현이 빨라지면 그 빈칸도 더 빨리 구체적인 동작이 됩니다. 화면이 완성되어 보일수록 팀은 기본 선택을 이미 논의한 결정으로 받아들이기 쉽습니다. 그래서 쓸 수 있는 결과가 나왔을 때도 돌아볼 필요가 있습니다. 어떤 규칙이 실제 필요에서 나왔고, 어떤 규칙은 생성 과정이 우리 대신 결정했을까요?

만들 수 있게 된 다음, 차이는 어디서 생길까?

어떤 종류의 기능을 더 쉽게 만들 수 있다면, 그 기능을 보유하는 것만으로 만들어지는 차이도 다시 살펴봐야 합니다. 예약 양식, 알림 템플릿, 관리 목록은 모두 유용합니다. 하지만 비슷한 조합이 쉽게 등장할수록 사용자는 더 많은 기준으로 비교합니다. 어느 것이 내 업무 흐름에 맞을까? 옮기려면 얼마나 수고해야 할까? 문제가 생기면 도움받을 사람이 있을까?

제 판단으로는 AI가 구현의 난도로 유지되던 일부 차별점에 더 큰 압력을 줄 것입니다. 다만 이 판단에는 범위가 있습니다. 설명과 검증이 쉽고 성숙한 패턴이 있는 기능은, 특수한 알고리즘이나 깊은 도메인 지식이 필요한 시스템과 조건이 다릅니다.

제품의 가치는 원래 사용자에게서 출발해야 했습니다. 달라지는 것은 자원을 투입하는 이유입니다. 기능 하나를 추가하는 비용이 낮아지면 팀은 “무엇을 더 넣을 수 있을까”를 따라 계속 확장하기 쉽습니다. 그러나 사용자가 기능을 이해하고, 규칙을 설정하고, 데이터를 옮기는 비용까지 낮아지는 것은 아닙니다. 주인에게 선택지가 하나 늘어나는 일은 결정을 하나 더 해야 한다는 뜻일 수도 있습니다.

따라서 구현 능력이 커진 뒤에는 선택과 포기도 구체화됩니다. 특정 유형의 스튜디오만을 대상으로 삼을 수 있을까요? 명료한 흐름을 위해 범용적으로 보이는 일부 기능을 포기할 수 있을까요? 만들기 쉬워질수록 새로 추가하는 것이 누구의 어떤 부담을 줄이는지 확인해야 합니다.

METR은 2026년 기술 종사자 조사에서 작업 속도와 산출물이 만드는 가치를 의도적으로 구분하고, 응답자가 보고한 향상이 객관적으로 검증된 성과와 같지는 않다고 주의를 줍니다. 이 조사가 어떤 제품의 성공을 설명하지는 않지만, 측정 대상을 구분하는 방식은 유용합니다. 아무도 필요로 하지 않는 관리 화면을 더 빨리 완성하는 것은 관심과 시간을 더 빨리 소비하는 일일 수도 있습니다.

이는 무엇을 자산으로 쌓을지에도 영향을 줍니다. 스튜디오에 대한 이해는 합리적인 기본값, 적절한 예외 처리, 도입하기 쉬운 흐름으로 발전할 수 있습니다. 경쟁자가 화면을 복제해도 각각의 선택이 나온 이유까지 알지는 못할 수 있습니다. 다만 이런 이해는 계속 현장과 대조해야 합니다. 팀 안의 상상만 남으면 그것 역시 짐이 될 수 있습니다.

예약 기능에서 예약 성립으로

그 스튜디오로 돌아가 봅시다. 운영자는 한 명이고, 낮에는 손님을 맞고 밤에는 메시지에 답한다고 가정합니다. 손님의 요청은 메신저, 달력, 종이 기록에 흩어져 있습니다. 운영자는 확인을 주고받는 일을 줄이면서도 단골이나 특별한 요청에 유연하게 대응하고 싶어 합니다.

양식을 제출할 수 있는 페이지는 정보 수집을 해결합니다. 그러나 예약이 성립하려면 더 많은 판단이 필요합니다. 서비스 전후에 준비 시간이 필요한가? 손님이 고른 시간이 아직 비어 있는가? 일정을 바꾸면 기존 시간은 언제 다시 열리는가? 알림이 전달되지 않았을 때, 아직 끝나지 않은 일임을 누가 알 수 있는가?

이런 세부 사항이 제품의 동작을 바꿉니다. 달력 동기화가 지연된다면 오래된 정보만으로 예약 성공을 선언해서는 안 됩니다. 운영자가 특별한 요청을 먼저 확인해야 한다면 화면은 “신청을 받았습니다”와 “예약이 확정되었습니다”를 명확히 구분해야 합니다. 두 문구 사이에는 사용자가 이제 출발해도 되는지에 관한 판단이 놓여 있습니다.

어느 부분의 일을 개선할지 알게 되면 제품의 방향도 분명해집니다. 기능은 여전히 중요하지만, 약속과 증거에 연결되어야 합니다.

이 표에는 보기 좋은 성과 수치를 미리 넣지 않았습니다. 실제 도입할 때는 원래 흐름을 먼저 관찰하고 사용 후의 차이를 살피되, 설정과 대조, 복구에 드는 시간도 함께 계산해야 합니다. 답장 몇 건을 줄였어도 AI가 틀리지 않았는지 매일 확인하는 부담이 늘었다면, 절약한 시간이 다른 형태로 돌아올 수 있습니다.

약속도 제품이 영향을 줄 수 있는 범위에 머물러야 합니다. 리마인더는 손님이 시간을 기억하도록 도울 수 있지만, 모든 사람이 제시간에 오는 것을 보장하지는 못합니다. 관찰 가능한 상태를 명확히 보여 주어 확인 대기 중인 예약을 주인이 일찍 알게 하고, 연락과 조정의 여지를 남기는 편이 책임 있는 접근입니다. 효과를 얼마나 정확히 설명하느냐는 사용자의 기대에 직접 영향을 줍니다.

현장을 이해하면 경쟁 상대를 보는 방식도 달라집니다. 이 서비스의 경쟁자는 주인이 익숙하게 쓰는 메신저와 종이 달력의 조합일 수 있습니다. 새로운 시스템은 기존 습관을 바꿀 만한 가치가 있을 정도로 좋아야 합니다. 기능이 같은지는 비교의 일부에 불과합니다.

일을 위임받은 뒤, 화면은 무엇을 보여 줘야 할까?

주인이 “금요일 오후 예약을 다음 주로 옮겨 줘”라고 직접 말할 수 있게 되면 제품은 위임을 받기 시작합니다. 이 한마디에는 많은 조작과 조건이 생략되어 있습니다. 전부 옮기는가? 손님은 동의했는가? 다음 주에 충분한 시간이 비어 있는가?

좋은 상호작용은 이 조건들을 판단할 수 있는 화면으로 되돌려 놓습니다. 시스템은 먼저 영향을 받는 예약과 가능한 시간을 제시하고, 주인이 검토한 뒤 손님에게 알릴 수 있습니다. 당장 조정할 수 없는 항목에는 명확한 상태와 사람이 이어받을 수 있는 진입점을 남깁니다. 어디까지 진행되었는지 알아야 안심하고 일을 맡길 수 있습니다.

이는 채팅창의 한계도 보여 줍니다. 자연어는 의도와 맥락을 전달하기에 적합하지만, 한 주의 빈 시간은 달력에서 비교하기 쉬운 경우가 많습니다. 여러 예약의 변경 전후도 표에 놓으면 검토하기 편합니다. 화면은 작업에 따라 표현 방식을 바꾸어 설명, 비교, 확인에 각각 알맞은 자리를 마련할 수 있습니다.

시스템이 판단에 사용한 근거도 확인할 수 있어야 합니다. 예를 들어 “오후에 시간이 비어 있다”는 정보는 최신 일정에서 나온 것일까요, 주인이 지난주에 한 말에서 나온 것일까요? 모든 추론 과정을 보여 줄 필요는 없지만, 일정에 영향을 주는 지점에는 대조할 수 있는 데이터와 제약을 제공해야 합니다. 그래야 사용자는 어떤 조건을 고쳐야 이후 처리가 제자리로 돌아올지 알 수 있습니다.

통제감에는 마음을 바꿀 수 있는 능력도 포함됩니다. 알림을 보내기 전에 취소할 수 있는가? 보낸 뒤 정정 안내를 할 수 있는가? 자동 처리의 범위는 명확한가? 이런 질문에는 흐름을 설계할 때 답해야 합니다. 사용자가 어느 정도까지 위임하려 할지를 결정하기 때문입니다.

매 단계마다 사용자가 다시 대조해야 한다면 위임의 가치가 줄어듭니다. 모든 단계가 말없이 완료되면 필요한 판단의 기회를 잃을 수 있습니다. 제품은 정말 멈춰서 확인할 가치가 있는 지점을 찾고, 나머지 단계의 상태도 보이게 해야 합니다. 이는 맥락에 따라 달라지는 설계 작업이며, “자동화는 많을수록 좋다”로 대체하기 어렵습니다.

보이지 않는 엔지니어링이 여전히 경험을 결정한다

간결한 화면은 아래의 시스템에 더 많은 책임을 맡깁니다. 두 사람이 동시에 예약해도 데이터의 일관성을 유지해야 합니다. 알림을 재시도할 때 손님에게 모순되는 메시지가 전달되어서는 안 됩니다. 시스템이 중단된 뒤 이어받는 사람은 어떤 동작까지 완료되었는지 알아야 합니다.

이런 일은 소개 영상에서 드러나기 어렵지만, 일상적인 사용에서 반복해서 신뢰를 결정합니다. 특히 제품이 사용자 대신 행동할 때 오류는 화면을 벗어나 다른 사람의 일정에 영향을 줍니다. 엔지니어링 품질은 곧 제품이 하는 약속의 일부가 됩니다.

Anthropic은 2026년 Managed Agents를 소개한 엔지니어링 글에서 영속적인 이벤트 기록과 실행 환경을 분리해, 실행 구성 요소가 실패해도 작업을 복구할 수 있는 설계를 설명합니다. 이 사례는 화면을 간단하게 만들기 위해서도 뒤에서는 상태 저장과 장애 복구를 준비해야 한다는 점을 구체적으로 보여 줍니다. 모든 예약 서비스에 같은 아키텍처가 필요하다는 뜻은 아닙니다.

엔지니어링 자체가 제품의 가장 중요한 차별점일 수도 있습니다. 매우 낮은 지연 시간, 특수한 데이터 처리, 오프라인 기능, 복제하기 어려운 통합은 어떤 필요를 충족할 수 있는지 직접 결정할 수 있습니다. 모든 코드가 값싼 부품이 될 것이라고 생각하면 이런 구체적인 제약을 놓치게 됩니다.

제가 더 중요하게 보는 것은 각 기술 투자가 결과를 어떻게 개선하는지 팀이 설명할 수 있는가입니다. 이 스튜디오에서는 생성 메시지의 말투를 하나 늘리는 것보다 중복 예약을 확실하게 막는 일을 먼저 해야 할 수 있습니다. 이미 알려진 흐름은 매번 모델에게 새로 판단하게 하기보다 고정된 규칙으로 처리하는 편이 적절할 수도 있습니다. 어디에 AI가 필요하고 어디에 확실성이 필요한지 아는 것 자체가 제품을 만드는 능력입니다.

제품의 약속을 다시 쓰기

이 가상의 제품을 한 문장으로 소개한다면 “AI 일정 관리, 자동 알림, 스마트 관리를 갖춘 예약 플랫폼”은 기능을 설명합니다. 하지만 자신의 현재 상황과 어떤 관계가 있는지는 여전히 주인이 추측해야 합니다.

저는 더 구체적으로 써 보겠습니다. “독립 스튜디오가 예약과 일정 변경을 한곳에서 처리하고, 반복 확인을 줄이며, 판단이 필요한 순간에는 운영자가 이어받도록 돕습니다.” 이 문장은 이미 입증된 성과가 아니라 설계와 사용을 통해 검증해야 하는 약속입니다. 서비스 대상을 선택하고, 팀이 무엇을 우선해야 하는지 알려 줍니다.

범위를 좁히면 첫 단계도 검증하기 쉬워집니다. 우선 1인 스튜디오에서 일정 변경 한 번을 끝까지 완성해 기존 시간의 재개방, 기록 갱신, 알림이 연결되는지 확인한 뒤 여러 사람의 근무 일정을 고려할 수 있습니다. 이런 순서는 실제 사용에서 배울 기회를 주며, 기능 수로 문제에 대한 이해를 대신하는 일을 막습니다.

이제 네 가지 질문에 답해야 합니다. 누구를 위한 서비스이고 그 사람은 원래 어떻게 일했는가? 어떤 관찰 가능한 결과를 개선하려는가? 실제로 개선되었다고 판단할 증거는 무엇인가? 시스템이 해내지 못하면 누가 이어받고 어떻게 복구하는가?

이 네 가지 질문으로 기능을 추가할 때마다 점검할 수 있습니다. 어떤 기능이 제품을 더 똑똑해 보이게만 하고 어느 답과도 연결되지 않는다면 미룰 만합니다. 절약한 구현 시간은 실제 흐름을 관찰하거나, 설정을 단순화하거나, 실패했을 때의 경험을 완성하는 데 쓸 수 있습니다.

디자이너와 개발자의 일도 더 긴밀하게 연결됩니다. 문제 정의에는 기술의 한계를 이해하는 일이 필요하고, 기술 선택에는 사용자가 중요하게 여기는 결과를 아는 일이 필요합니다. 디자인은 이 선택들을 사람이 이해하고 조작하며 신뢰할 수 있는 흐름으로 만듭니다. 이 연결을 책임지는 사람에게는 기능 목록으로 측정하기 어려운 가치를 만들 기회가 있습니다.

AI로 구현의 일부가 쉬워질 때 제가 얻고 싶은 것은 더 큰 여유입니다. 풀 가치가 있는 문제를 더 일찍 검증하고, 보여 주기는 어렵지만 매일 일어나는 예외를 더 끈기 있게 다룰 수 있는 여유입니다.

코드는 무대 뒤로 물러나도 됩니다. 그 주인이 다시 갑작스러운 일정 변경을 마주했을 때, 한 번만 처리하면 되고 실제로 완료되었음을 확인할 수 있다면, 제품은 계속 선택받을 이유를 갖게 됩니다.