Samsung SDS

말하지 않아도 통하는 팀의 비밀

얼마 전만 해도 AI는 사람이 시키는 것만 하고, 시키는 게 없으면 가만히 있는 수동적인 도구였어요. 지금의 AI는 목표와 맥락을 미리 공유받아 다음 단계를 준비하고, 상황 정보를 실시간으로 공유하며, 필요하면 주도권을 넘기기도 해요. 축구 경기에서 패스가 올 것을 예측하고 빈 공간으로 달려가는 선수처럼, "지금 내가 뭘 해야 하는지"를 스스로 파악하는 거예요.

AI를 도입하지 않은 회사를 찾기 어려운 시대예요. 그래서 이제 중요한 건 AI와 얼마나 자연스럽게 호흡을 맞추는지예요. 1호에서 사원증 없는 동료들이 팀에 합류하는 이야기를 했다면, 이번 호에서는 그 동료들과 같은 맥락을 공유하며 진짜 ‘One Team’이 되기 위해 필요한 것들을 이야기해요.

AI와 사람이 호흡을 맞추는 두 가지 방법

AI와 사람이 함께 일하려면 구체적으로 어떻게 해야 할까요? 글로벌 기업들은 이미 두 가지 접근을 운영 단계에 올려놓았어요.

혼자에서 팀으로: AI끼리도 협력한다

예전에는 하나의 AI가 모든 걸 다 했다면, 지금은 각 분야의 전문 AI 여럿이 팀을 이루어 함께 문제를 해결해요.

친구들과 여행 계획을 세우는 상황을 떠올려 보세요. 한 명이 항공권을 검색하고, 한 명이 숙소를 비교하고, 한 명이 맛집 리스트를 만들어요. 각자 잘하는 걸 맡으면 훨씬 빠르죠. AI도 마찬가지예요. AI가 많아지면서 ‘매니저 AI’와 ‘실무 AI’라는 역할 구분도 생겼어요. 매니저 AI가 목표를 설정하면, 실무 AI들이 각자 파트를 맡아 일하고, 중간 진행 상황을 공유하면서 결과물을 합쳐요.

서로 다른 회사의 AI를 연결하려는 시도도 제품 계획과 표준으로 구체화되고 있어요. Salesforce와 AWS는 2025년 10월 협력을 발표하며, 향후 MCP 지원을 통해 Amazon Q in Connect와 Agentforce 에이전트 간 상호운용을 제공할 계획이라고 밝혔어요. MCP(Model Context Protocol)는 AI가 도구·데이터에 접근하는 방식을 표준화하고, A2A(Agent2Agent)는 서로 다른 회사의 에이전트가 정보를 주고받도록 돕는 별도 표준이에요. 리눅스 재단에 따르면 A2A에는 공개 1년 만에 150개가 넘는 조직이 참여했어요.

다만 현실은 기대만큼 뜨겁지 않아요. 서로 다른 생태계가 각자의 통신 방식과 도구에 묶이면, 회사 경계를 넘는 협력에는 여전히 별도 연동과 검증이 필요해요. 개방형 표준은 출발점일 뿐, 실제 팀플레이를 만들려면 권한·보안·오류 처리 방식까지 함께 맞춰야 해요.

주도권 설계: AI에게 어디까지 맡길 수 있을까?

이쯤 되면 자연스럽게 고민이 생겨요. "다 맡겨도 되는 걸까? 어디서 선을 그어야 하지?"
답은 ‘상황에 따라 다르다’예요. 그리고 이 ‘상황에 따라’를 체계적으로 설계하는 것 자체가 핵심 역량이에요. 크게 세 가지 모델이 있어요.

첫째, 사람이 결정권을 쥔 모델 (Human in the Loop).

AI가 초안을 만들더라도 최종 판단을 사람이 맡도록 설계하는 모델이에요. 의료 진단이나 대출 심사처럼 오류의 영향이 큰 업무에 해당하죠. EU AI Act 제14조는 고위험 AI 시스템을 사람이 효과적으로 감독할 수 있도록 설계하라고 요구해요.

둘째, AI가 운전하되 사람이 지켜보는 모델 (Human on the Loop)

자율주행차를 생각하면 돼요. 평소에는 AI가 운전하지만, 위험 상황이 오면 사람이 핸들을 잡아요. 고객센터처럼 반복적이지만 가끔 복잡한 상황이 생기는 업무에 잘 맞아요.

셋째, AI가 처음부터 끝까지 처리하는 모델 (Human out of the Loop)

사람이 개입할 필요가 없는 일이에요. 택배 배송 조회처럼 오류의 영향이 적고 되돌리기 쉬운, 실시간 판단이 필요 없는 업무에 쓰여요.

하나의 프로젝트에서 반드시 하나만 선택할 필요는 없어요. 단계별로 모델이 바뀔 수 있거든요. "이 단계에서는 AI가 주도하고, 저 단계에서는 사람이 나선다"를 미리 설계해 두는 것이 팀의 핵심 역량이 될 거예요. 그리고 이 경계는 운영하면서 계속 다시 조정해야 하는 설계 문제이기도 하고요.

같은 맥락을 공유하는 순간, 팀이 된다

[삼성SDS CX팀] AX·DT : 디자인 씽킹에 AI가 합류하다

디자인 씽킹 다섯 단계마다 전담 에이전트. 내부 파일럿에서 공감·문제 정의가 약 60% 줄고, 검토한 아이디어는 3배 이상으로 늘었어요.

무엇을 바꿨나

우리 팀은 CX 분야에서 널리 쓰이는 문제 해결 방법론인 ‘디자인 씽킹’에 AI를 투입했어요. 공감 → 문제 정의 → 아이디어 도출 → 프로토타이핑 → 고객 검증의 다섯 단계는 단계마다 사람 손이 필요해요. 그래서 디자인 씽킹을 요청하는 서비스는 많은데, 담당자와 시간이 한정되어 모든 요청을 소화하기 어려웠어요. 이 프로세스 자체를 확장한 것이 AX·DT(Agent Experience Design Thinking)예요.

어떻게 작동하나

다섯 단계 각각에 전담 AI 에이전트를 배치했어요. 공감 단계 에이전트는 사용자 데이터와 인터뷰를 수집·정리해 불편 지점을 짚고, 문제 정의 에이전트는 그 인사이트로 다양한 관점의 문제 진술문을 제안해요. 아이디어 에이전트는 유사 사례와 해결책을 실시간으로 제시하고, 구현 에이전트는 목업과 서비스 흐름을, 검증 에이전트는 사용자 관점의 예상 피드백을 미리 내놓아요. 다섯 에이전트는 따로 일하지 않아요. 공감 에이전트가 발견한 패턴이 문제 정의의 재료가 되고, 정의된 문제가 아이디어의 출발점이 돼요. 각 단계에서 AI가 먼저 빠르게 탐색하고 정리하면, 사람이 그 위에서 판단하고 방향을 결정해요. 고객의 감정을 이해하고 해석하는 일은 여전히 사람의 역할이고요.

무슨 결과가 있었나

내부 파일럿에서는 공감·문제 정의 단계에 걸린 시간이 기존보다 약 60% 줄었고, 같은 시간에 검토한 아이디어 수는 3배 이상으로 늘었어요.

왜 중요한가

속도보다는 일을 나눈 방식이 이 사례의 핵심이에요. 다섯 단계마다 전담 에이전트를 두되, AI가 제안한 문제 정의 중 진짜 핵심을 고르는 것, 수십 개의 아이디어 중 고객에게 의미 있는 것을 선별하는 것은 사람의 영역으로 남겨두고요. 시작은 AI로 빠르게, 완성은 사람과 함께. 이것이 AX·DT가 제안하는 팀플레이예요.

도입 시 고민 지점

워크숍 횟수가 쌓이면서 검증해야 할 질문이 남아 있어요. 아이디어의 ‘수’가 3배 늘어난 것이 채택되는 아이디어의 ‘질’로도 이어지는가, 그리고 에이전트가 깔아준 빠른 출발이 참여자들의 깊은 몰입을 대체해 버리지는 않는가. 속도를 얻고 발산의 깊이를 잃는다면 본말이 뒤집히는 거니까요.

[글로벌 · 리테일] Wayfair: 상담사 옆에서 답을 먼저 써주는 AI

대화 맥락과 상품·정책 정보를 바탕으로 답변을 제안해 상담사의 응대를 도와요.

무엇을 바꿨나

미국의 홈 인테리어 쇼핑몰 Wayfair는 디지털 판매 상담사를 위한 생성형 AI 도구 Agent Co-pilot을 만들었어요. 상담사가 고객과 대화하면서 상품 정보와 회사 정책을 찾아 답변을 작성하던 과정을 줄이기 위해, 대화 옆에서 답변 초안을 제안하도록 했어요.

어떻게 작동하나

Agent Co-Pilot은 대화 기록과 현재 맥락, 상품 정보, 회사 정책을 바탕으로 상담사가 보낼 답변을 실시간으로 제안해요. 답변을 만드는 프롬프트에는 작업 지시, 내부 응대 가이드라인, 회사 정책, 상품 정보, 지금까지의 대화 이력 다섯 가지가 함께 들어가요. 상담사는 제안을 그대로 보내는 것이 아니라 내용을 확인하고 필요하면 고쳐 고객에게 전달해요. AI가 사람에게 상담을 넘기는 구조가 아니라, 사람이 상담을 이어가는 동안 AI가 옆에서 답변 작성을 돕는 구조예요.

무슨 결과가 있었나

Wayfair의 초기 테스트에서 Agent Co-Pilot을 사용한 상담의 평균 처리 시간은 10% 줄었어요. 회사는 전환율, 상담사 사용률, AI 제안을 얼마나 수정했는지 등을 함께 살피며 도구의 효과를 평가했어요.

왜 중요한가

상담사가 대화 중에 상품·정책 정보를 따로 찾고 답변을 처음부터 작성하는 시간을 줄인다는 점이 중요해요. AI가 현재 대화의 맥락을 반영해 초안을 제안하고, 사람이 최종 답변을 책임지는 역할 분담이 이 사례의 핵심이에요.

도입 시 고민 지점

답변 제안이 상품 정보나 회사 정책을 잘못 반영할 수 있어요. 그래서 상담사가 근거가 된 맥락을 확인하고 고칠 수 있는 동선이 함께 있어야 해요. Wayfair는 상담사가 제안을 얼마나 고쳤는지와 그 수정 이유를 모으고, 별도 LLM으로 답변 품질을 자동 평가했어요. 처리 시간만 보지 말고 답변의 정확성과 고객 반응까지 함께 측정해야 진짜 팀플레이가 돼요.

[삼성SDS CX팀] Design to Code : 디자인 배턴 터치를 바꾸다

룰 기반 디자인-코드 변환 플러그인이 정합성을 잡고 에이전트는 컴포넌트 치환만. 믿고 맡길 수 있는 크기로 일을 잘랐어요.

무엇을 바꿨나

디자인과 개발 사이에는 오랫동안 사람이 화면을 다시 그리는 단계가 있었어요. 디자이너가 Figma로 화면을 만들면 퍼블리셔나 프론트엔드 개발자가 그 화면을 보고 HTML/CSS로 다시 구현하고, 디자이너가 구현 결과를 원래 의도와 대조했죠. 우리 팀의 Design to Code는 이 반복을 걷어내요. 디자인 산출물이 그대로 코드로 이어지게 만들어서, ‘화면을 잘 그리도록 설명하는’ 핸드오프 단계가 ‘코드로 바로 연결되도록’ 바뀌는 거예요.

어떻게 작동하나

처음에는 AI 에이전트가 Figma를 직접 읽어 코드로 바꾸는 방식을 시도했는데, 정확도가 90% 중반까지 나왔지만 매번 다른 부분에서 틀렸어요. 이 오류를 보정하며 전환 일관성을 맞추는 과정에서 토큰 사용량도 늘었고요. Design to Code를 시도하는 팀이라면 누구나 겪게 될 시행착오예요.

지금은 자체 개발한 디자인-코드 변환 플러그인이 Figma 화면을 룰 기반으로 일정하게 코드로 바꿔 레이아웃과 디자인 토큰의 정합성을 잡아요. 에이전트는 그 위에서 미리 매핑해둔 React·Vue 개발 컴포넌트로 치환만 맡고, 검증 에이전트가 전환된 코드와 Figma 디자인의 정합성을 확인하고요. 결과물은 변환 결과 포털로 넘어가서, 개발자는 Figma에 들어가지 않아도 화면 프리뷰와 코드, 요소별 CSS, 에셋을 정리된 채로 받아요. 코드 전환에 별도 비용이 없고 사내망·외부망·폐쇄망을 가리지 않는 범용성도 강점이에요.

무슨 결과가 있었나

지금까지 두 건의 사례가 있어요. 하나는 리뉴얼을 앞둔 서비스의 디자인을 코드로 전환해 품질 평가까지 돌려본 검증 사례, 다른 하나는 퍼블리셔 없이 프론트엔드 개발자들이 화면을 만드는 Agent 프로젝트인데, 디자인이 나오는 대로 디자인-코드 변환 플러그인과 AI 스킬을 거쳐 화면 코드로 전달되며 잘 돌아가고 있어요. 지금은 기존 운영 중인 프로젝트보다는 새로 시작하는 프로젝트에 더 적합해요.

왜 중요한가

Design to Code가 잘 돌아가는 이유는 일을 나눈 방식에 있어요. AI에게 모든 걸 맡기는 대신 믿고 맡길 수 있는 크기로 잘랐죠. 디자인-코드 변환 플러그인은 Figma 구조를 표준 코드로 바꾸고, 변환 결과 포털은 그 맥락을 개발자에게 건네고, AI 스킬은 코드 산출물을 프로덕션 수준으로 다듬어요. 여기에 디자인 시스템과 가이드라인을 문서로 묶어 개발자가 Figma를 열지 않아도 되게 하는 ‘Design MD’까지 구상 중이고요. 이 분업이 자리 잡으면 디자이너와 개발자 사이의 ‘다시 그리기’와 ‘다시 대조하기’를 줄일 수 있어요.

도입 시 고민 지점

관건은 디자인 파일의 품질이에요. 여러 사람의 손을 거치며 복잡한 레이아웃과 임시 수정이 쌓인 기존 산출물은 AI가 이해하기 어려울 수 있어요. 사람 눈에는 이해되는 디자인이라도, 코드로 바꾸려면 레이어 구조와 토큰 적용, 상태 정의가 훨씬 명확해야 해요. 오래 운영된 서비스도 남은 숙제예요. 고객사마다 다른 컨벤션과 수정 이력이 얽힌 코드에는, 기존 규칙을 먼저 읽고 표준 코드를 그 프로젝트 방식에 맞게 바꾸는 워크플로가 더 필요할 수 있어요.

우리 팀은 AI와 ‘One Team’인가?

Q1. 우리 업무 중 사람이 반드시 결정해야 하는 단계는 어디인가?

Human in / on / out of the Loop 세 모델을 우리 프로세스에 단계별로 매핑해 본 적이 있나요? 이 지도가 없으면, 맡겨도 되는 일에 사람이 붙잡혀 있거나 맡기면 안 되는 일이 AI에게 넘어가 있어요.

Q2. 우리는 AI에게 목표를 공유하는가, 작업만 시키는가?

"이상 탐지해줘"와 "고객 이탈로 이어지는 패턴을 찾아줘"는 같은 요청처럼 보이지만 결과가 완전히 달라요. 우리가 AI에게 주는 지시에는 ‘왜’가 담겨 있나요?

Q3. AI가 제안한 답변을 사람이 확인하고 고칠 수 있는가?

AI가 만든 답변 초안에는 현재 대화와 상품·정책 정보가 제대로 반영되어 있나요? 상담사가 근거를 확인하고 필요하면 고쳐서 보낼 수 있는지 점검해 보세요. 한 걸음 더 나아가, 얼마나 자주 어떻게 고쳤는지까지 데이터로 남겨 AI 답변의 신뢰도를 꾸준히 살피고 있다면 더 좋고요.

좋은 도구만으로는 부족합니다

"같은 화면을 보는 건 시작일 뿐이다. 같은 ‘목표’를 보고 있어야 진짜 팀플레이가 된다."
기술을 갖추는 건 절반이에요. 나머지 절반은 사람과 AI가 같은 방향을 바라보게 만드는 원칙을 세우는 일이에요.

같은 설계도를 보고 있는가?

집을 짓는다고 상상해 보세요. 집주인은 작은 부지의 복층 집을 생각하고 있는데, 건축가가 드넓은 전원주택을 그려왔다면? 목표부터 다시 맞춰야 해요. 이 경험에서 뽑아낸 세 가지 원칙이 있어요.

첫째, AI에게 ‘배경지식’을 가르쳐야 해요. AI가 과거 데이터만 분석하는 데 그치면 안 돼요. ‘이 숫자가 떨어지면 고객이 떠날 확률이 높다’, ‘이런 패턴은 불만의 징후다’처럼, 우리 서비스에서 데이터가 어떤 의미를 갖는지 판단하는 기준까지 함께 넣어야 해요.

둘째, ‘좋은 결과’의 기준을 명확히 정해줘야 해요. 무언가를 해달라고만 하면, AI는 자기 나름의 기준으로 결과를 가져와요. 브랜드 톤 유지, 암묵적 요구사항처럼 숫자로 표현하기 어려운 기준까지 공유해야 결과물이 올바른 방향을 향해요.

셋째, 서로의 강점과 약점을 솔직하게 인정해야 해요. 어떤 상황에서는 사람의 직관이 낫고, 어떤 상황에서는 AI의 분석력이 뛰어나요. 이걸 조직 차원에서 인정하고 조합하는 방법을 계속 학습해야 해요.

호흡이 깨지는 두 가지 방식

원칙을 세워도, 팀플레이는 정반대의 두 방향으로 무너질 수 있어요.

첫째는 과신이에요. AI가 대체로 정확하면 사람의 검토는 점점 형식이 돼요. 결과를 읽지 않고 승인 버튼을 누르는 거죠. 연구자들이 ‘자동화 편향(automation bias)’이라 부르는 현상으로, 이 상태의 Human in the Loop은 문서에만 존재해요. 사람이 들어가 있다는 사실 자체가 오히려 안전하다는 착각을 만들고요.

둘째는 불신이에요. 사람은 동료의 실수에는 관대하면서, AI가 한 번 틀리면 훨씬 가혹하게 평가하고 다시 쓰지 않으려 해요. ‘알고리즘 회피(algorithm aversion)’라 불리는 패턴이에요(Dietvorst, Simmons & Massey, 「Algorithm Aversion」, Journal of Experimental Psychology: General, 2015). 같은 실수율이라도 AI에게 더 엄격한 잣대를 대는 거죠. 이렇게 되면 AI가 잘하는 영역의 이득까지 통째로 버리게 돼요.

좋은 팀플레이는 이 둘 사이의 보정된 신뢰예요. AI가 강한 영역에서는 빠르게 받아들이고, 약한 영역에서는 의심하는 것. 세 번째 원칙, 강점과 약점의 인정이 팀의 근육이 되어야 하는 이유가 여기에 있어요. 그리고 이 보정은 한 번으로 끝나지 않아요. AI의 실력이 달라질 때마다 신뢰의 눈금도 다시 맞춰야 해요.

※   본 리포트는 담당자가 작성한 초안을 바탕으로 생성형 AI를 활용하여 윤문, 팩트체크, 이미지 제작 등 후작업을 수행했습니다.