AI는 서비스 레이어가 돼요 — 사용자와 BE 사이의 새 층
AI는 새 도구가 아니라 새 계층이에요. 사용자 의도를 도메인 액션으로 바꾸는 서비스 레이어로서의 AI, 그게 모든 서비스 회사의 다음 책무라는 관점을 정리합니다.
지난 글에서 Aster.duck Skillset 0.4를 공개했어요. 외부 AI가 우리 서비스를 사용자처럼 쓰는 길을 열어둔 작업이었어요.
발표하고 나서 한 줄이 머리에 남았어요.
이건 새 기능이 아니라, 새 계층이에요.
지금까지 서비스 회사는 두 개의 면을 만들어왔어요. BE(도메인)와 FE(GUI). 사용자는 GUI를 통해 의도를 입력하고, FE가 그걸 API 호출로 번역해서 BE에 던지면, BE가 응답을 돌려주면, FE가 그걸 다시 사람이 읽을 수 있는 모양으로 정리해요.
이 구조에서 AI는 한동안 “FE 안에 들어가는 똑똑한 컴포넌트”였어요. 자동완성, 추천, 챗봇. 도구 한 종.
그런데 스킬셋을 만들고 운영해보니 — AI는 도구가 아니에요. GUI와 같은 층에 서는, 사용자와 BE 사이의 또 다른 인터페이스 계층이에요.
이 글은 그 관점을 정리해요. AI는 서비스 레이어가 돼요(AI as Service Layer, AaSL).
1) 무엇이 바뀌나 — 의도 진입 면이 둘이 돼요
기존 서비스의 진입 면은 하나였어요.
[사용자] → GUI(FE) → API(BE) → 도메인스킬셋이 깔린 뒤의 진입 면은 둘이에요.
[사용자] → GUI(FE) ────┐
├─→ API(BE) → 도메인
[사용자] → AI(스킬셋) ─┘GUI는 사라지지 않아요. 손가락으로 빠르게 골라야 하는 일, 시각적 비교가 필요한 일, 클릭 한 번이 자연어 다섯 문장보다 빠른 일은 여전히 화면이 맞아요.
다만 GUI가 더이상 의도의 유일한 진입 면이 아니게 돼요. “이번 달 안에 마셔야 할 와인 뭐 있어?”, “라벨 사진 한 장 보낼게, 셀러에 넣어줘” — 이런 의도는 화면을 7번 누르는 것보다 한 줄로 말하는 게 빨라요. 그 한 줄을 받아 도메인 액션으로 바꾸는 층이 새로 생긴 거예요.
이 새 층은 FE의 연장이 아니에요. FE는 “사람이 읽고 조작할 수 있는 표현”을 만드는 일이고, AI 레이어는 “사람의 자연어 의도를 도메인 액션으로 변환·실행·정리”하는 일이에요. 결이 달라요.
2) AI 서비스 레이어의 책임 — 변환, 권한, 검증, 정리
레이어라고 부를 수 있으려면 책임이 분명해야 해요. AI 레이어가 짊어지는 일을 네 가지로 정리할 수 있어요.
변환(Translation)
자연어 의도 → 어떤 스킬 → 어떤 엔드포인트 → 어떤 파라미터. 이걸 일관되게 해주는 것이 변환이에요. 사람마다 같은 의도를 다른 말로 표현하니까, 변환은 “표현의 다양성을 도메인 액션의 단일성으로” 좁히는 일이에요.
권한(Authorization)
쓰기 액션, 개인 데이터 접근에는 누구의 자격으로 호출하는지가 명확해야 해요. AI 레이어는 사용자의 토큰을 들고 호출해요. 사용자가 안 시킨 일은 안 해야 하고, 시킨 일도 권한 범위 안에서만 해야 해요.
검증(Validation)
자연어는 모호해요. 빈티지가 빠졌거나, 와인 이름이 두 가지로 해석되거나, 사용자가 말한 점수가 5점 만점인지 100점 만점인지 모호한 순간이 있어요. AI 레이어는 BE를 호출하기 전에 모호함을 사용자에게 되묻는 일까지 자기 책임으로 가져가야 해요.
정리(Presentation)
BE의 응답은 JSON이에요. 사용자는 JSON을 읽지 않아요. AI 레이어는 응답을 받은 뒤 읽을 만한 자연어로 정리해서 돌려줘야 해요. 어떤 필드를 보여줄지, 몇 개까지 보여줄지, 어떤 어조로 말할지 — 모두 이 층이 책임져요.
이 네 가지 책임이 분명해지면, AI 레이어는 단순한 챗 인터페이스가 아니라 사용자 의도를 도메인 액션으로 변환하는 서비스 계층이 돼요.
3) 그래서 모든 서비스 회사의 다음 책무
이 관점을 받아들이면 회사 단위로 한 줄짜리 책무가 생겨요.
우리 서비스를 AI에게 무엇을, 어떻게 시킬 수 있게 할 것인가.
이걸 ‘추가 기능’으로 보면 안 돼요. 추가 기능이면 챗봇 UI 하나 붙이고 끝나요. 그건 도구 추가지 레이어 추가가 아니에요.
레이어를 추가한다는 건 — BE/API 설계 시점부터 두 종류의 클라이언트(사람의 FE, AI의 스킬셋) 를 동등하게 가정한다는 뜻이에요. 그 결과로 따라오는 것:
- API는 사람 전용 UI에 종속된 응답이 아니라, 의미가 명시된 도메인 응답이 돼요.
- 인증은 단명 토큰 + 명시적 권한 스코프 패턴이 표준이 돼요.
- 도메인 모델은 모호함을 줄이는 방향으로 다듬어져요. (점수 단위, 시점 의미, 상태 다중값 등)
- 변경 로그는 사람뿐 아니라 AI 클라이언트도 따라올 수 있게 버전과 안내가 명확해져요.
서비스의 핵심 자산이 화면 디자인에서 도메인 의미의 정밀도로 무게중심이 이동해요.
4) 설계의 최소 단위 — 스킬 매니페스트
레이어를 깐다는 말은 추상적이에요. 실제 설계 단위가 있어야 해요.
스킬셋 작업에서 얻은 답은 — 스킬 매니페스트예요. 한 스킬 = “이런 의도가 들어오면 / 이런 사전 조건에서 / 이 엔드포인트들을 / 이 순서로 호출하고 / 이런 모양으로 정리해서 돌려준다”의 묶음이에요.
매니페스트는 모델보다 오래 살아요. 모델은 6개월마다 바뀌어요. 더 똑똑해지고, 더 싸지고, 호출 방식이 미묘하게 달라져요. 그때마다 우리 서비스의 사용법을 다시 가르치는 비용이 크면 안 돼요.
매니페스트가 잘 정리돼 있으면, 모델만 갈아끼우면 돼요. 매니페스트 자체는 도메인의 사용법을 의미 단위로 문서화한 자산이 돼요. 코드도 아니고 단순 문서도 아닌, 그 사이의 무언가예요.
이게 PaSelf 글에서 말한 “공급망”의 한 칸으로도 보여요. 개인화 소프트웨어 시대에 서비스는 사람이 직접 쓰기도 하고, 그 사람의 AI가 대신 쓰기도 해요. 그 둘 모두에게 같은 도메인 단어가 통해야 해요. 그 합의의 단위가 매니페스트예요.
5) 차별화의 축이 이동해요
모델 자체의 능력은 빠르게 commoditize되고 있어요. GPT, Claude, Gemini가 서로 따라잡고, 오픈 모델이 거리를 좁혀요. 모델만으로 만들 수 있는 차별화는 줄어요.
대신 다음 세 가지가 그 자리에 들어와요.
- 도메인 의미의 정밀도 — 와인의 빈티지/생산자/팔레트가 어떻게 모델링됐는지, 시음 적기가 어떻게 계산되는지, 상태가 어떻게 표현되는지. 매니페스트가 가리키는 BE의 의미가 얼마나 정확한가.
- 권한 경계 — 어떤 액션이 인증 필요인지, 토큰 수명은 얼마인지, 만료 후 흐름은 어떻게 끊기지 않는지. AI가 “사용자 자격으로 일하는 안전한 대리인”이 될 수 있는가.
- 검증 루프 — 사용자에게 되묻는 타이밍, 에러 발생 시 다음 행동 안내, 잘못된 트리거 회수 절차. AI 레이어가 사고를 일으켰을 때 빠르게 학습되는가.
이 셋은 모델이 아니라 회사의 도메인 자산이에요. 모델이 commoditize될수록 이 자산의 가치는 커져요.
6) 잘못 가는 길 — 챗봇을 붙이면 끝났다고 생각하는 것
이 관점이 새로 안 보이는 회사는 보통 같은 길로 가요.
- 기존 GUI 옆에 챗봇 위젯을 띄워요.
- “AI가 도와드려요”라는 문구가 붙어요.
- 안에서 도는 건 RAG로 FAQ를 검색해 보여주는 정도예요.
이건 도구 추가예요. 사용자의 의도를 도메인 액션으로 바꾸지 않아요. 정보를 보여줄 뿐 일을 시키지 못해요.
진짜 레이어 추가는 — 사용자가 “내 셀러에 라벨 사진 한 장으로 와인을 추가”하고, AI가 권한을 갖고 실제 BE에 데이터를 기록하고, 결과를 정리해서 돌려주는 흐름이에요. 그 흐름이 GUI 흐름과 같은 도메인 결과를 만들어야 해요.
기준은 단순해요. AI 경로로 들어온 변경과 손가락으로 들어온 변경이 같은 데이터가 되는가. 안 되면 도구만 붙인 거예요. 되면 레이어가 깔린 거예요.
7) 우리가 어디까지 와있나
Aster.duck Skillset 0.4는 한 회사가 한 도메인(와인·커피 취향 기록)에 대해 AI 서비스 레이어를 깐 작은 실증이에요. 38개 엔드포인트, 13개 스킬, 단명 Bearer 토큰, 매니페스트 한 장 — 이게 지금 시점에서 한 회사가 깔 수 있는 최소 구성이에요.
다음 단계는 정밀도예요.
- AI 경로로 들어온 셀러 등록의 메타 품질이 손 등록과 같아지는 것
- 모호한 의도를 되묻는 타이밍이 일관되는 것
- 잘못 트리거된 스킬의 회수 흐름이 매니페스트 안에 명문화되는 것
이게 검증되면 다음 도메인에 같은 패턴을 복제할 수 있어요. 그 시점부터는 “AI 서비스 레이어”가 한 회사의 특수한 시도가 아니라, 모든 도메인 서비스가 가져가는 표준 면이 돼요.
정리
지난 글에서 했던 한 줄을 다시 가져올게요.
AI를 “사람의 도구”가 아니라 “새로운 종류의 사용자”로 본다.
이번 글의 한 줄은 이거예요.
AI는 새로운 종류의 사용자이기 전에, 사용자와 우리 서비스 사이의 새로운 계층이다.
서비스 회사는 더이상 BE와 FE 두 개의 면만 만드는 회사가 아니에요. BE / FE / AI 레이어 세 개의 면을 가진 회사로 옮겨가요. 화면은 가벼워지고, 의도가 무거워져요.
이 변화는 모델 회사의 일이 아니라 서비스 회사의 일이에요. 도메인을 가진 쪽이 자기 도메인의 사용법을 매니페스트로 정리하지 않으면, 모델이 아무리 좋아져도 그 도메인은 AI를 통해 쓰일 수가 없어요.
다음 글에서는 — AI 레이어가 굴러가기 시작했을 때 BE 설계가 어떻게 달라져야 하는지, 우리가 실제로 마주한 API/도메인 모델의 재설계 포인트를 정리할 예정이에요.
링크