--- title: "문제는 풀렸는데 왜 제품이 아닌가" description: "로그 모니터링 SaaS가 하던 일을 에이전트와 함께 직접 만들었다. 로그 수집과 분석, 로그를 근거로 한 개선까지 AI로 됐고 원하는 인터페이스도 얻었다. 그래도 제품은 아니었다. 문제 해결의 최소 조건과 제품의 최소 조건을 4계층 스택에 나란히 놓으면, 둘은 쓰는 사람과 운영하는 사람과 책임지는 사람이 갈라지는 지점에서 갈린다. 그래서 직접 만들지 살지는 대체의 문제가 아니라, 단계마다 어디까지 책임질지 고르는 문제다." canonical: "https://architecture.reopt.ai/ko/articles/problem-solved-not-a-product" language: "ko" last-updated: "2026-10-22" alternate-markdown: "https://architecture.reopt.ai/articles/problem-solved-not-a-product.md" site-index: "https://architecture.reopt.ai/llms.txt" source: "reopt architecture" --- # 문제는 풀렸는데 왜 제품이 아닌가 > 로그 모니터링 SaaS가 하던 일을 에이전트와 함께 직접 만들었다. 로그 수집과 분석, 로그를 근거로 한 개선까지 AI로 됐고 원하는 인터페이스도 얻었다. 그래도 제품은 아니었다. 문제 해결의 최소 조건과 제품의 최소 조건을 4계층 스택에 나란히 놓으면, 둘은 쓰는 사람과 운영하는 사람과 책임지는 사람이 갈라지는 지점에서 갈린다. 그래서 직접 만들지 살지는 대체의 문제가 아니라, 단계마다 어디까지 책임질지 고르는 문제다. - **저자:** Eric Han - **작성일:** 2026-10-22 - **Category:** analysis - **태그:** saas, product, ownership, observability, OCLS ## 로그 모니터링을 직접 만들었다 이전 회사에서는 로그 모니터링 SaaS를 엔터프라이즈 플랜으로 썼다. 올해 그 도구가 하던 일을 에이전트와 함께 직접 만들었다. 구조는 단순하다. 서비스의 로그를 모아 MCP로 열어 둔다. 그러면 AI가 로그를 직접 읽는다. 오류가 왜 났는지 분석하고 그 분석을 근거로 코드를 고친다. 화면에서 그래프를 찾아다닐 필요가 없다. 궁금한 걸 AI에게 물으면 된다. 필요한 건 로그를 분석할 수 있는 최소한의 엔드포인트였고 인터페이스는 내가 원하는 모양으로 만들었다. 문제는 풀렸다. 그런데 이걸 팔 수 있느냐고 물으면 답이 바로 나온다. 팔 수 없다. 문제 해결의 최소 조건과 제품의 최소 조건은 무엇이 다른가. 이 글은 그 질문 하나를 다룬다. ## 문제 해결은 아래 두 층에서 끝난다 reopt architecture의 [4계층 모델](/ko/architecture)로 보면 이 도구가 채운 건 아래 두 층이다. 모듈 층에는 로그를 모으고 꺼내 주는 엔드포인트가, 에이전트 층에는 그 로그를 읽고 판단해서 고치는 AI가 있다. 문제 해결에 필요한 건 여기까지였다. 이 두 층을 만드는 비용은 AI가 크게 낮췄다. SaaS를 직접 만들어 대체할 수 있다는 말은 여기까지는 맞다. ## 제품은 위 두 층이 채워져야 시작된다 | | 문제 해결의 최소 조건 (직접 만든 로그 도구) | 제품의 최소 조건 (쓰는 사람, 운영하는 사람, 책임지는 사람이 다를 때) | |---|---|---| | L4 거버넌스 | _비어 있음_ | 가용성 보증, 보관 정책 · 권한과 감사, 비용 통제 | | L3 협업 | _비어 있음_ | 여러 팀과 직군이 함께 본다 · 알림에서 대응까지 넘기는 흐름 | | ↑ 제품이 되는 구간 / ↓ AI로 대체되는 구간 | | | | L2 에이전트 | AI가 MCP로 로그를 읽고 고친다 · 책임지는 사람은 나 | 결과마다 책임자가 정해져 있다 · AI 분석이 틀리면 누가 답하는가 | | L1 모듈 | 로그를 모으고 꺼내는 엔드포인트 · 내가 원하는 인터페이스 | 처음 보는 사용자와의 계약 · 거절 조건, 버전, 호환성 | _문제 해결은 아래 두 층에서 끝나고 제품은 위 두 층이 채워져야 시작된다_ 오른쪽 위 두 칸이 내 도구에는 없다. 협업 층부터 보면, 제품으로 쓰는 로그 모니터링에서는 여러 팀과 여러 직군이 같은 로그를 본다. 알림이 울리면 대응할 사람에게 넘어가고 대응한 기록이 남는다. 내 도구에 이 층이 없는 건 게을러서가 아니다. 쓰는 사람이 나 하나라 넘겨줄 상대가 없다. 거버넌스 층은 질문이 더 많다. 감시 도구는 감시하는 서비스보다 먼저 살아 있어야 하는데, 그 가용성은 누가 보증하는가. 로그는 얼마나 보관하고 언제 지우는가. 누가 어떤 로그를 볼 수 있고 본 기록은 남는가. 수집량이 열 배로 늘면 비용은 누가 통제하는가. 아래 두 층도 제품이 되면 성격이 바뀐다. 모듈의 계약은 처음 보는 사용자에게도 지켜져야 하니, 무엇을 거절하는지와 버전이 바뀌면 무엇이 깨지는지를 적어 둬야 한다. 에이전트 층에서는 AI가 분석을 틀렸을 때 누가 답하는지가 정해져 있어야 한다. 위 두 층에 들어가는 것은 기능이 아니다. 로그를 더 잘 분석하는 능력과는 상관이 없다. 남이 이 도구를 믿고 맡길 수 있게 하는 조건이다. ## 세 역할이 갈라질 때 제품이 된다 "내가 원하는 인터페이스"라는 말에서 중요한 단어는 "내가"다. 내 도구에서는 쓰는 사람, 운영하는 사람, 책임지는 사람이 모두 나다. 셋이 한 사람이면 계약을 적을 필요가 없다. 내가 원하는 것이 곧 계약이다. 넘겨줄 상대가 없으니 협업 구조도 필요 없다. 장애가 나면 내가 고치면 되니 가용성을 약속할 상대도 없다. OCLS의 네 질문에 대어 보면 차이가 더 분명하다. | | 문제 해결 | 제품 | |---|---|---| | **OWN** | 쓰는 사람, 운영하는 사람, 책임지는 사람이 한 사람이다 | 셋이 다른 사람이어도 책임이 끊기지 않는다 | | **CONTRACT** | 내가 원하는 엔드포인트. 적혀 있지 않아도 된다 | 처음 보는 사용자에게도 지켜지는 계약이 적혀 있다 | | **LAYER** | 모듈과 에이전트, 두 층 | 네 층 전부 | | **SHARPEN** | 내가 불편할 때 고친다 | 여러 사용자의 운영 신호로 정기적으로 보정한다 | 제품은 이 셋이 다른 사람이어도 돌아가야 한다. 고객이 쓰고 운영팀이 돌리고 회사가 책임진다. 위 두 층은 세 역할이 갈라지는 순간 생기는 틈을 메운다. 역할이 갈라지기 전에는 필요 없지만 갈라진 뒤에는 그것 없이 버틸 수 없다. 같은 결론에 다른 길로 도착한 분석도 있다. 사티아 나델라는 2024년 12월 BG2 팟캐스트에서 [에이전트 시대에 비즈니스 애플리케이션이라는 개념 자체가 무너질 수 있다](https://cloudwars.com/ai/apps-apocalypse-bill-mcdermott-joins-satya-nadella-in-saying-ai-agents-will-crush-applications/)고 말했다. SiliconANGLE의 데이브 벨란테와 조지 길버트는 이 예측이 Office처럼 혼자 쓰는 앱에만 맞는다고 봤다. 여럿이 함께 쓰는 소프트웨어에서는 [로직 층이 사라지지 않고 모양만 바뀐다](https://siliconangle.com/2026/02/28/satyas-sacrifice-agents-threaten-office-microsoft-responds/). 여러 시스템에 걸친 일을 하려면 일관성과 거버넌스가 필요하기 때문이다. ## SaaS 대체의 한계 SaaS를 직접 만들어 대체할 수 있느냐는 질문에는 반만 답할 수 있다. 기능은 대체된다. 대체되지 않는 건 남이 믿고 맡기게 하는 구조다. 벤처캐피털 Forgepoint의 글은 이걸 더 직설적으로 적는다. 벤더가 실패하면 책임을 물을 바깥 상대가 있지만 직접 만든 도구가 실패하면 책임은 고스란히 내부 팀에 남는다. 그래서 [책임을 넘길 수 있다는 것](https://forgepointcap.com/perspectives/margin-of-safety-43-saaspocalypse-vibe-coding-and-the-new-scarcity/) 자체가 어떤 AI 에이전트도 줄 수 없는 기능이라고 했다. 바이브 코딩은 만드는 비용을 낮추지만 틀렸을 때 치르는 비용은 바꾸지 못한다고 봤다. 직접 만든 도구를 볼 때는 이렇게 묻는다. > 이 도구를 쓰는 사람, 운영하는 사람, 책임지는 사람이 서로 달라져도 돌아가는가? 답이 "아니다"라면 그건 문제 해결이다. 나쁜 일은 아니다. 혼자 쓰는 도구라면 아래 두 층으로 충분하고 AI 덕분에 그 두 층은 어느 때보다 싸다. 다만 그걸 제품이라고 부르려면 위 두 층을 채워야 한다. 위 두 층은 한 번에 채워지지도 않는다. 예브게니 브릭만은 [성숙에는 지름길이 없다](https://www.ybrikman.com/blog/2026/08/01/what-you-cant-vibe-code/)고 썼다. 소프트웨어 비용의 대부분은 만든 뒤의 유지보수에서 나온다. 장애와 보안 문제를 하나씩 겪으며 쌓인 것은 코드를 빨리 쓴다고 따라잡히지 않는다. 앞의 그림은 한 시점의 단면이고 오른쪽 위 두 칸은 시간이 지나야 채워진다. SaaS를 만드는 쪽에서 보면 같은 질문이 반대 방향을 가리킨다. 아래 두 층은 이제 고객이 직접 만들 수 있다. 제품이 설 자리는 고객이 직접 만들 수 없는 위 두 층에 있다. ## 책임 범위를 설계한다 다시 문제 해결 쪽으로 돌아가 보자. 직접 만든 도구는 어느 정도 완성도로 문제를 풀어야 할까. 기준은 기능 목록이 아니다. 그 도구가 멈췄을 때 비용을 누가 치르는가다. 내가 치르고 내가 감당할 수 있다면 아래 두 층의 완성도로 충분하다. 다른 사람이 치르게 되는 순간 필요한 완성도가 한 층씩 올라간다. "문제가 풀렸다"에서 멈추지 않고 운영의 범위까지 넓혀 보면, 직접 만들지 SaaS를 쓸지는 대체의 문제가 아니라 단계마다 고르는 문제가 된다. | 단계 | 세 역할 | 필요한 층 | 고를 것 | |---|---|---|---| | 혼자 쓴다 | 셋 다 나 | 모듈, 에이전트 | 대개 직접 만든다. AI 덕분에 가장 싸게 끝나는 구간이다 | | 팀이 함께 쓴다 | 쓰는 사람이 여럿이 된다 | 협업 층 추가 | 공유와 알림 흐름을 직접 채울지, SaaS를 쓸지 | | 남이 기대어 쓴다 | 운영과 책임도 갈라진다 | 거버넌스 층 추가 | 가용성, 보관, 권한의 책임을 직접 질지, 맡길지 | 내 로그 도구는 지금 첫 단계에 있다. 서비스에 장애가 나서 로그 도구까지 멈추면 한동안 눈을 감고 일해야 하지만 그 비용은 내가 치르고 감당할 수 있다. 팀이 같은 로그를 보기 시작하면 두 번째 단계로 넘어가고 장애 대응을 이 도구에 맡기는 순간 세 번째 단계가 된다. 그때가 위 두 층을 직접 채울지 다시 고를 시점이다. 선택은 층 단위로도 할 수 있다. 모듈 층의 수집과 보관, 거버넌스 층의 가용성과 권한은 SaaS에 맡기고 에이전트 층의 분석과 개선 루프는 내가 원하는 모양으로 그 위에 직접 얹는 식이다. 대체하지 않고 나눠 맡는다. 그래서 질문을 바꾼다. SaaS를 대체할 수 있는가가 아니라, 지금 단계에서 어느 층까지 내가 책임질 것인가. 역할이 갈라질 때마다 이 답을 다시 고르면 된다. AI가 위 두 층까지 싸게 만들기 시작하면 이 경계도 함께 움직일 것이다. 어디까지 움직일지는 아직 답하지 못한 질문이다. ## 관련 패턴 - [Responsibility Partitioning — 책임 분할](https://architecture.reopt.ai/ko/patterns/responsibility-partitioning.md) - [Module Contract — 모듈 계약](https://architecture.reopt.ai/ko/patterns/module-contract.md) --- _이 문서는 https://architecture.reopt.ai/ko/articles/problem-solved-not-a-product 의 마크다운 표현이다. 전체 색인: https://architecture.reopt.ai/llms.txt HTML 원본: https://architecture.reopt.ai/ko/articles/problem-solved-not-a-product · English: https://architecture.reopt.ai/articles/problem-solved-not-a-product.md_