Professional case · Generalized실무 사례 · 일반화Professional case · Generalized
Turning AI capability into bounded, reviewable product behavior in a permission-sensitive B2B SaaS environment.권한이 중요한 B2B SaaS에서 AI를 어디까지 맡기고 어디서 사람이 검토할지 제품 흐름으로 설계한 사례입니다.Turning AI capability into bounded, reviewable product behavior in a permission-sensitive B2B SaaS environment.
Customer identities, private roadmap details, production screens, internal system identifiers, and confidential metrics are intentionally omitted.고객명과 비공개 로드맵, 실제 운영 화면, 내부 시스템 식별자, 기밀 지표는 공개하지 않습니다.Customer identities, private roadmap details, production screens, internal system identifiers, and confidential metrics are intentionally omitted.
Enterprise procurement work is not a single conversation. Users move across requests, sourcing events, contracts, orders, suppliers, documents, approvals, and role-based permissions. As AI became more useful, the harder product question became: how should AI participate without hiding context, bypassing permissions, or removing human product judgment?엔터프라이즈 구매 업무는 한 번의 대화로 끝나지 않습니다. 요청, 소싱, 계약, 발주, 공급사, 문서, 승인, 역할별 권한을 계속 오갑니다. AI가 더 많은 일을 할 수 있게 될수록 중요한 질문은 “맥락과 권한을 지키면서 어디까지 AI에게 맡길 것인가”가 됐습니다.Enterprise procurement work is not a single conversation. Users move across requests, sourcing events, contracts, orders, suppliers, documents, approvals, and role-based permissions. As AI became more useful, the harder product question became: how should AI participate without hiding context, bypassing permissions, or removing human product judgment?
A generic chat interface can demonstrate model capability, but enterprise use requires visible working context, permission-aware results, inspectable outputs, and a clear separation between AI recommendation and consequential business action.범용 Chat UI만으로는 실제 업무에 쓰기 어렵습니다. 사용자는 어떤 맥락에서 나온 결과인지 확인할 수 있어야 하고, 권한에 맞는 정보만 보여야 하며, AI의 추천과 실제 업무 실행 사이에는 분명한 검토 지점이 필요합니다.A generic chat interface can demonstrate model capability, but enterprise use requires visible working context, permission-aware results, inspectable outputs, and a clear separation between AI recommendation and consequential business action.
I translated AI capabilities and product needs into bounded user flows, requirements, review points, and cross-functional decisions. My responsibility was not to build the underlying model; it was to define how model capability should become usable product behavior.저는 모델 자체를 만드는 역할이 아니라, AI가 할 수 있는 일을 실제 제품에서 어떻게 써야 하는지 정의했습니다. 사용자 흐름과 요구사항, 검토 지점, 부서 간 의사결정 기준으로 구체화했습니다.I translated AI capabilities and product needs into bounded user flows, requirements, review points, and cross-functional decisions. My responsibility was not to build the underlying model; it was to define how model capability should become usable product behavior.
Key product decisions핵심 제품 판단Key product decisions
Frame interactions around procurement objects, user intent, and workflow state rather than treating every request as an isolated prompt.각 요청을 별개의 prompt로 보지 않고 구매 객체와 사용자 의도, 현재 업무 상태를 기준으로 AI interaction을 설계합니다.Frame interactions around procurement objects, user intent, and workflow state rather than treating every request as an isolated prompt.
Recommendations and drafts can be AI-assisted; consequential workflow actions require an explicit review or confirmation point.추천과 초안은 AI가 도울 수 있지만, 실제 업무에 영향을 주는 행동은 사람이 확인한 뒤 실행되도록 구분합니다.Recommendations and drafts can be AI-assisted; consequential workflow actions require an explicit review or confirmation point.
Role, organization scope, document access, and result visibility are product-design constraints, not only backend implementation details.역할과 조직 범위, 문서 접근 권한, 결과 공개 범위는 backend 구현만의 문제가 아니라 제품 경험을 결정하는 조건으로 봅니다.Role, organization scope, document access, and result visibility are product-design constraints, not only backend implementation details.
Show what the result is based on, what still requires judgment, and what the user can safely do next.결과가 무엇을 근거로 만들어졌는지, 사용자가 무엇을 더 판단해야 하는지, 다음에 안전하게 할 수 있는 일이 무엇인지 드러냅니다.Show what the result is based on, what still requires judgment, and what the user can safely do next.
Look for repeatable patterns across retrieval, drafting, recommendation, review, and next-action flows instead of solving every feature as a one-off.검색, 초안, 추천, 검토, 다음 행동에서 반복되는 패턴을 찾아 기능마다 처음부터 다시 설계하지 않습니다.Look for repeatable patterns across retrieval, drafting, recommendation, review, and next-action flows instead of solving every feature as a one-off.
Reusable reasoning pattern재사용 가능한 판단 흐름Reusable reasoning pattern
Synthetic workflow view · no production screen or customer data.재구성한 업무 흐름이며 실제 운영 화면이나 고객 데이터는 포함하지 않습니다.Synthetic workflow view · no production screen or customer data.
The work established a reusable reasoning pattern: domain context → bounded AI capability → permission-aware result → human review → safe next action. It also reinforced that model capability is only one input; product work is designing the context, boundaries, review logic, and workflow that make the capability trustworthy enough to use.이 작업에서 반복해서 사용한 판단 순서는 domain context → bounded AI capability → permission-aware result → human review → safe next action입니다. 모델의 성능만 높다고 제품이 되는 것은 아니며, 실제로 쓸 수 있으려면 맥락과 경계, 검토 방식, 업무 흐름까지 함께 설계해야 한다는 원칙을 정리했습니다.The work established a reusable reasoning pattern: domain context → bounded AI capability → permission-aware result → human review → safe next action. It also reinforced that model capability is only one input; product work is designing the context, boundaries, review logic, and workflow that make the capability trustworthy enough to use.
What this demonstrates이 사례가 보여주는 것What this demonstrates
Knowing where model capability ends and product design begins.모델이 할 수 있는 일과 제품이 책임져야 하는 일을 구분합니다.Knowing where model capability ends and product design begins.
Designing for roles, permissions, workflow state, and consequential actions.역할과 권한, 업무 상태, 실제 실행까지 한 흐름으로 봅니다.Designing for roles, permissions, workflow state, and consequential actions.
Turning ambiguous capability into shared requirements, flows, and review criteria.모호한 가능성을 여러 조직이 함께 이해할 수 있는 요구사항과 flow, 검토 기준으로 바꿉니다.Turning ambiguous capability into shared requirements, flows, and review criteria.
Looking for repeatable patterns instead of solving each AI interaction as a one-off.매번 새로 해결하기보다 반복해서 쓸 수 있는 패턴과 운영 방식을 찾습니다.Looking for repeatable patterns instead of solving each AI interaction as a one-off.
Public evidence공개 근거Public evidence
The public proof is the product reasoning and operating model, not confidential screens or customer data.이 사례에서 공개하는 것은 기밀 화면이나 고객 데이터가 아니라, 제품을 설계할 때 사용한 판단 기준과 운영 방식입니다.The public proof is the product reasoning and operating model, not confidential screens or customer data.