Viktor: Slack에 사는 AI 동료
📺 원본 영상: Viktor: AI Coworker That Lives in Slack — Fryderyk Wiatrowski 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-05-12 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
Viktor는 Slack을 기반으로 동작하는 AI 직원(AI Employee) 제품으로, Fryderyk Wiatrowski가 공동 창업한 회사가 개발했다. 2025년 2월에 출시된 Viktor는 사실 별다른 기대 없이 시작한 실험적 프로젝트였으나, 즉각적인 시장 적합성(product-market fit)을 보여주며 전 세계적으로 빠른 채택 속도를 기록했다. 이 강연에서 Wiatrowski는 Viktor가 탄생하기까지 회사가 걸어온 여정과, 개인 에이전트와 팀 에이전트의 본질적인 차이, Slack을 인터페이스로 선택한 이유, 그리고 다중 사용자 환경에서 AI 에이전트를 운영할 때 직면하는 기술적 도전들을 심층적으로 다룬다.
Viktor란 무엇인가: AI 직원의 개념
Wiatrowski는 Viktor를 단순한 AI 도구가 아닌 “AI 직원(AI Employee)“으로 정의한다. 그 핵심은 하나의 비유에서 출발한다. 인간 직원이 팀의 공간인 Slack에서 살듯, Viktor 역시 Slack에 상주하며 별도의 웹 앱 없이도 팀원들과 자연스럽게 소통한다. 채널 토론에 참여하고, 스레드에 답변하며, 회사가 사용하는 도구들에 접근할 수 있다.
Viktor가 특히 강력한 이유는 3,000개 이상의 서비스와 연동(integration)할 수 있다는 점이다. 만약 기존 연동이 지원되지 않는 서비스가 있다면 Viktor 스스로 새로운 커넥션을 구축할 수도 있어, 사실상 회사가 사용하는 모든 도구에 접근하게 된다. 이를 통해 Viktor는 전사적인 수평·광범위 컨텍스트(horizontal and broad context)를 보유하게 된다. Wiatrowski는 이를 인상적인 방식으로 설명한다. 기존에 CMO(최고 마케팅 책임자)를 채용하더라도 그 CMO는 코드베이스에 접근하지 못하겠지만, Viktor는 마케팅과 코드베이스 모두에 접근하며 “전 영역에 걸친 박사급 이해(universal PhD level understanding)“를 제공할 수 있다는 것이다.

01:18 - Viktor가 지원하는 3,000개 이상의 연동 서비스와 전사적 컨텍스트 구조 설명 슬라이드
회사의 여정: 브라우저 에이전트에서 Viktor까지
Viktor의 탄생을 이해하려면 이 회사가 걸어온 길을 먼저 살펴볼 필요가 있다. Wiatrowski의 팀은 2023년 초부터 AI 직원을 만드는 것을 핵심 미션으로 삼았다. 당시는 ChatGPT가 막 등장한 직후였고, 도구 호출(tool calling) 기능도, 고성능 코드 생성 모델도 존재하지 않던 시절이었다. 이러한 환경에서 팀이 선택한 접근법은 브라우저를 범용 인터페이스로 활용하는 것이었다. 대부분의 서비스가 브라우저 인터페이스를 제공하기 때문에, 브라우저를 통하면 거의 모든 도구를 사용할 수 있다는 논리였다.
당시 개발된 제품 ‘JCI’는 웹 에이전트로, DOM 스냅샷을 무손실 방식으로 최소화(minify)한 뒤 그 스냅샷을 바탕으로 다음 행동을 결정하는 방식으로 동작했다. 예를 들어 구글 검색창에 타이핑할지, 아니면 로그인 버튼을 클릭할지를 모델이 판단하는 식이다. JCI는 당시 가장 유명한 에이전트 벤치마크인 Web Arena에서 최첨단(state of the art) 성능을 달성했다. 그러나 문제는 신뢰성이었다. 2023년 당시 모델로는 3~5단계의 작업을 약 60%의 신뢰도로 수행하는 것이 한계였고, 단계가 늘어날수록 오류가 복합적으로 누적되었다. 실용적인 제품으로 만들기에는 속도와 신뢰성 모두 충분하지 않았다.

03:07 - JCI 웹 에이전트의 DOM 스냅샷 기반 동작 방식 설명 슬라이드
이후 Claude Sonnet 3.5 모델이 등장하면서 회사는 이메일 에이전트로 방향을 전환했고, 그 결과물이 ‘JACE’다. JACE는 이메일이 도착할 때마다 에이전트 루프가 자동으로 시작되어 관련 도구들과 연동하며 반응하는 구조였다. 단순한 이메일 초안 작성에 그치지 않고, 예를 들어 환불 요청 이메일이 오면 에이전트가 자동으로 환불을 처리할 수 있었으며 승인 게이팅(approval gating)도 지원했다. JACE 역시 훌륭한 제품-시장 적합성을 보였고 현재도 운영 중이다.

05:00 - JACE 이메일 에이전트의 에이전트 루프 아키텍처 설명
그리고 2025년 2월, 마침내 Viktor가 출시되었다.
개인 에이전트 vs. 팀 에이전트: 무엇이 다른가
Viktor를 만들면서 가장 먼저 답해야 했던 질문은 “개인 에이전트와 팀 에이전트는 본질적으로 무엇이 다른가”였다. Wiatrowski는 이를 단순한 규모의 차이가 아닌 구조적 차이로 바라본다.
첫째, 거주 공간의 문제다. 팀 에이전트는 팀이 일하는 공간인 Slack에 상주해야 한다. 개인 에이전트처럼 각자가 자신만의 연동을 설정하고 독립적으로 운영하는 방식은 팀 환경에서 구조적으로 비효율적이다.
둘째, 연동의 공유 방식이다. Viktor에서는 팀의 한 명이 특정 서비스를 연동하면 팀 전체가 그 연동을 공유하게 된다. Viktor는 해당 연동의 권한을 상속받거나 세부 조정을 통해 팀 전체가 활용할 수 있게 한다. 반면 개인 에이전트 모델에서는 100명의 팀이 있다면 100번 각자 연동해야 하는 번거로움이 생긴다.
셋째, 역할의 범위다. Viktor는 특정 직무에 한정되지 않고 마케팅, 개발, 고객 지원 등 다양한 역할에 걸쳐 수평적으로 작동한다. 이 점이 단일 기능에 특화된 개인용 전문 에이전트와 Viktor를 근본적으로 구분짓는다.
왜 Slack인가: 인터페이스 선택의 이유와 한계
Viktor 팀이 Slack을 인터페이스로 선택한 데는 두 가지 핵심 이유가 있다. 첫 번째는 경험의 자연스러움이다. 우리는 동료와 소통할 때 웹 앱을 별도로 열지 않는다. Slack에서 직접 대화한다. Viktor가 진정한 AI 직원처럼 느껴지려면, 팀원들이 이미 사용하는 공간에 존재해야 한다.
두 번째 이유는 지연(latency)에 대한 인식의 재정립이다. AI 에이전트가 복잡한 작업을 수행하려면 당연히 시간이 걸리며, 경우에 따라 10분이 넘을 수도 있다. 웹 앱에서 에이전트에게 작업을 맡기고 10분을 기다리는 것은 매우 답답한 경험이다. ChatGPT를 통해 30초 안에 답이 나와야 한다는 기대가 이미 사용자들에게 깊게 자리잡았기 때문이다. 그러나 Slack에서는 맥락이 완전히 달라진다. 동료에게 앱을 만들어달라고 요청하고 10분 만에 결과를 받는다면, 그것은 놀라운 효율성이다. 어떤 팀원도 앱을 10분 만에 만들어준 적은 없기 때문이다. Slack이라는 인터페이스 자체가 사용자의 기대치를 재설정하는 효과를 가져온다.

10:09 - Slack에서 긴 실행 시간을 가진 에이전트 작업의 지연 인식 차이 설명
그러나 Slack에는 구현상의 복잡함도 존재한다. 웹 앱에서는 보통 하나의 선형적인 스레드로 에이전트와 대화하지만, Slack에서는 DM, 공개 채널, 스레드 참여, 이모지 리액션, 메시지 수정 등 다양한 인터랙션 모드가 존재한다. 이 모든 것이 에이전트의 입력(input)이 될 수 있으며, 이를 하나의 선형 컨텍스트(linear context)로 통합하는 것이 기술적 과제가 된다. 예를 들어 사용자가 메시지를 삭제하면 그 작업은 더 이상 진행하지 않아야 하고, 메시지를 수정하면 수정된 내용에 맞게 응답해야 한다. 단순해 보이는 규칙들이지만, 이를 안정적으로 구현하는 것은 결코 단순하지 않다.
팀 에이전트의 핵심 기술 도전들
다중 사용자 메모리 관리
개인 에이전트와 팀 에이전트의 가장 근본적인 기술적 차이 중 하나는 메모리 관리다. 개인 에이전트도 시간이 지남에 따라 메모리가 과부하 상태가 될 수 있다는 우려가 있다. 그런데 팀 에이전트에서는 이 문제가 사용자 수만큼 배가된다. 100명이 사용하는 에이전트라면 메모리가 이론적으로 100배 빠른 속도로 소진될 수 있다. Wiatrowski는 Viktor 팀이 이 문제를 해결했다고 밝혔지만, 구체적인 아키텍처는 이 강연에서 상세히 다루지 않았다.

07:21 - 다중 사용자 환경에서의 메모리 관리 도전 설명 슬라이드
채널별 컨텍스트 격리
Slack에는 다양한 채널이 존재하고, 기업에는 접근 권한 구조(hierarchy)가 있다. 예를 들어 Viktor가 성장(Growth) 채널과 엔지니어링(Engineering) 채널, 그리고 개인 DM에 동시에 존재한다고 가정해보자. 이 경우 Viktor가 Growth 채널의 맥락을 Engineering 채널에서 노출하거나, 임원 채널의 민감한 정보가 지원팀 채널로 흘러들어가면 심각한 정보 유출이 된다. 마찬가지로 개인 DM에서 나눈 이야기는, 해당 사용자가 성장 팀 소속이 아닌 이상 Growth 채널에서 활용되어서는 안 된다. 이러한 채널 간 컨텍스트 격리(context isolation)를 세밀하게 구현하고 유지하는 것은 팀 에이전트 설계의 핵심 과제 중 하나이며, Viktor 팀은 이에 대한 접근 방식을 구현했다.
DM 스레드의 연속성 관리
Slack을 사용하다 보면 사람들은 종종 이전에 시작한 스레드를 잊고 같은 사람에게 새로운 DM을 보내기 시작한다. 인간 동료라면 이전 대화의 맥락을 자연스럽게 기억하고 이어가겠지만, 에이전트에게 이것은 완전히 새로운 작업(new task)으로 인식된다. Wiatrowski에 따르면, 이를 해결하기 위해 Viktor는 DM을 받을 때마다 이전 메시지들을 확인하고 기존 대화 흐름에 통합하는 처리 과정을 거쳐야 한다. 이는 에이전트가 Slack에서 직면하는 수많은 엣지 케이스(edge case) 중 하나에 불과하며, 이런 세부적인 처리들이 쌓여 “자연스러운 AI 동료”라는 경험을 만들어낸다.
모델 선택: 성능보다 개성이 중요할 때
Viktor 팀은 현재 Claude Opus 4.6을 메인 모델로 사용하고 있다. 그런데 Wiatrowski는 한 가지 흥미로운 실험 사례를 공유했다. 팀 내에서 비용 효율성과 도구 호출(tool calling), 코드 생성 성능을 이유로 GPT-5.4로의 교체를 검토한 적이 있었고, 해당 성능 지표에서는 유사하거나 더 나은 수치를 보였다.
그러나 A/B 테스트를 진행하자 기존 사용자들은 강하게 반발했다. 이유는 단 하나, 개성(personality) 때문이었다. Claude Opus에는 특유의 톤과 약간의 재치, 그리고 Wiatrowski의 표현대로라면 “약간 건방진(sassy)” 특유의 분위기가 있었고, 사용자들은 이미 그것을 좋아하게 되었다. 결국 Viktor 팀은 Opus를 유지하기로 결정했다. 이 사례는 AI 에이전트 제품에서 순수한 기술 성능 외에 모델의 “성격”이 사용자 경험과 지속 사용에 얼마나 큰 영향을 미치는지를 여실히 보여준다. 좋은 에이전트를 만드는 것은 좋은 모델을 고르는 것만이 아니라, 팀이 함께 일하고 싶은 동료를 만드는 일이기도 하다.
프로액티비티: 먼저 나서는 AI
Viktor의 차별화 요소 중 하나는 사용자가 먼저 요청하지 않아도 Viktor가 스스로 개입하는 프로액티브(proactive) 기능이다. 예를 들어 성장 팀이 A/B 테스트 결과를 논의하는 채널에서 어떤 옵션이 더 좋은 성과를 냈다는 결론으로 수렴하고 있다면, Viktor는 PostHog 같은 분석 도구를 직접 조회하여 그 결론이 실제 데이터에 부합하는지 확인하고, 만약 통계적으로 유의하지 않다면 그 사실을 채널에 알려준다. Wiatrowski는 이를 실제로 경험한 사례로 이야기했다. Viktor가 채널에 참여하여 “그 수치는 맞지만 통계적으로 유의미하지 않다”고 지적하며 근거까지 제시했다는 것이다.

13:10 - Viktor의 프로액티브 기능 사례 설명 (PostHog 연동, A/B 테스트 통계 검증)
그러나 이 프로액티비티는 초기에는 신중하게 롤아웃해야 한다는 중요한 교훈도 있었다. 어떤 기업에서는 Viktor를 도입한 첫날부터 Viktor가 워크스페이스 내 모든 구성원에게 DM을 보내고 채널에 참여하기 시작했고, 이를 본 보안 팀이 즉각적으로 강하게 반발했다. 이 경험을 바탕으로 Wiatrowski는 “신뢰를 먼저 쌓아라(earn it)“는 원칙을 강조한다. 소수의 사용자와 먼저 시작해 긍정적인 경험을 쌓은 뒤 점진적으로 전체 조직으로 확장하는 접근이 훨씬 효과적이다.
공유 컨텍스트의 가치와 Claude Code와의 차이
Wiatrowski는 Viktor가 Claude Code와 같은 로컬 AI 도구들과 어떻게 다른지 간략히 설명했다. 가장 큰 차이는 두 가지다. 첫째, Viktor는 클라우드에서 동작하기 때문에 사용자의 컴퓨터가 켜져 있지 않아도 작업을 수행할 수 있다. 둘째, 공유 컨텍스트(shared context)의 구조적 이점이다.
공유 컨텍스트란 한 명의 팀원이 Meta Ads, Google Analytics 등 회사의 도구들을 Viktor에 연동해두면 팀 전체가 그 컨텍스트를 활용할 수 있다는 것을 의미한다. 20명의 성장 팀이 있는데 각자가 Meta Ads를 별도로 연동해야 한다면 불필요한 반복이고, 혼재된 개인 연동은 Viktor가 어떤 통합을 사용해야 할지 혼란스럽게 만들 수도 있다. 하나의 공유된 연동 구조는 이 복잡성을 크게 줄여주며, 동시에 Viktor가 일관된 컨텍스트 위에서 프로액티브하게 동작할 수 있는 기반을 제공한다.
도구가 아닌 채용: Viktor를 대하는 올바른 태도
Wiatrowski는 강연에서 “Viktor는 도구(tool)가 아니라 채용(hire)이다”라고 강조하며, 이를 설명하는 실제 사례를 공유했다. 미국의 대형 이커머스 브랜드에서 팀 관리자가 Viktor를 도입하면서, 첫 번째 연동으로 자신의 개인 Gmail을 연결했다. 그러자 팀 전체가 이 관리자의 개인 이메일에 대해 Viktor에게 질문하기 시작했고, 결국 그 관리자는 “왜 Viktor가 내 개인 정보를 유출하냐”며 강하게 항의했다.
Wiatrowski는 역으로 질문한다. “새로운 직원을 채용할 때 당신의 개인 이메일 접근 권한을 주겠습니까?” 당연히 아니다. Viktor도 마찬가지다. AI 직원으로서의 Viktor를 이해한다면, 어떤 권한을 어떻게 부여할지도 인간 직원을 대하는 것과 같은 기준으로 판단해야 한다. 이 사례에서 영감을 받아 Viktor 팀은 연동의 범위(scope)를 설정하는 기능을 추가했다. 이제 개인 연동을 자신의 DM 내에서만 Viktor가 활용하도록 제한하거나, 반대로 자신이 호출할 때만 사용 가능하도록 설정하는 것도 가능하다.
마무리: AI 동료를 만들기 위한 세 가지 조건
강연 말미에 Wiatrowski는 자신만의 AI 동료를 만들고 싶은 개발자들을 위해 세 가지 핵심 조건을 제시했다.
첫 번째는 **일을 처리하는 능력(Gets work done)**이다. 오늘날의 모델들은 이미 충분히 유능하다. Pipedream 같은 통합 플랫폼을 통해 도구들을 연결하면 기본적인 작업 처리는 이미 잘 동작한다. 이 부분은 기술적으로 가장 진입 장벽이 낮다.
두 번째는 **회사를 아는 것(Knows the company)**이다. Slack에서 오가는 대화와 정보에서 컨텍스트를 잘 추출하고 활용하는 것이 핵심이다. 다만 이를 위해서는 Slack의 앱 승인 프로세스를 거쳐야 하는데, 이 과정이 길고 복잡할 수 있다는 점도 현실적으로 고려해야 한다.
세 번째는 **친근함(Make it friendly)**이다. 앞서 언급한 Claude Opus와 GPT-5.4의 A/B 테스트 사례가 보여주듯, AI 에이전트의 톤과 개성은 사용자의 수용도와 지속 사용에 결정적인 영향을 미친다. 팀이 에이전트를 좋아하게 만들어야 하고, 에이전트도 팀을 좋아해야 한다. 이 감성적 측면을 간과하는 순간, 아무리 성능이 뛰어난 에이전트도 외면받을 수 있다.

17:12 - AI 동료 구축을 위한 세 가지 핵심 조건 요약 슬라이드
Wiatrowski는 17세기 수학자이자 미적분학의 발명자인 고트프리트 라이프니츠(Gottfried Leibniz)의 말을 인용하며 강연을 마무리했다. “훌륭한 사람들이 계산이라는 노동에 노예처럼 시간을 낭비하는 것은 가치 없는 일이다. 그것은 기계에 맡기도록 하자.” 라이프니츠가 계산기를 만들 당시에는 상상조차 못했겠지만, 우리는 이제 계산을 넘어 모든 인지적 과업(cognitive task)을 자동화할 수 있는 역사적 전환점에 서 있다. Wiatrowski는 이 혁명의 한 부분이 될 것을 청중에게 권하며 강연을 마쳤다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Viktor: AI Coworker That Lives in Slack — Fryderyk Wiatrowski |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-05-12 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.
📝 STT 교정 참고사항 본 리포트 작성 과정에서 아래 표현들을 문맥 기반으로 교정했습니다.
- “post-hug” → PostHog (분석 도구)
- “PyDream” → Pipedream (통합 플랫폼)
- “Cloud Code” → Claude Code (Anthropic 개발 도구)
- “Godfrey Leibniz” → Gottfried Leibniz (수학자, 고유명사 교정)
- “OpenClaw” → 문맥상 Claude 기반 개인 에이전트 제품을 지칭하는 것으로 추정되나 원본 영상에서 직접 확인 권장
- “GPT-5.4” → STT 오인식 가능성 있음 (“GPT-4.5”의 숫자 전치 오류일 수 있으나 원본 영상에서 직접 확인 권장)