"업무의 흐름이 끊기지 않는, 나만을 위해 성장하는 똑똑한 AI 에이전트 만들기"
서론: 왜 AI 비서가 필요한가?
업무를 하다 보면 하루 종일 컴퓨터 앞에만 앉아 있기는 어렵습니다. 식사, 화장실, 출퇴근 등 물리적으로 자리를 비워야 하는 순간은 필연적으로 발생하죠. 문제는 그때마다 업무의 흐름(Context)이 끊긴다는 점입니다. 스마트폰으로 슬랙(Slack) 메시지를 확인할 수는 있지만, 방금 전까지 몰입하던 복잡한 코딩이나 데이터 분석 작업을 이어서 하기는 불가능에 가깝습니다.
이런 상상을 해보신 적 있나요? "내가 컴퓨터 앞에 없어도 나를 따라다니며, 내가 해온 일을 모두 기억하고, 지시한 일을 잊지 않고 척척 해내는 AI가 있다면?"
단순한 챗봇이 아닙니다. 슬랙에서 나눈 대화를 복사해서 AI에게 붙여넣고, 결과를 다시 복사해오는 번거로운 '전달자' 역할은 이제 그만하고 싶었습니다. AI가 슬랙, IDE, 서버 어디에나 존재하며, 내가 하는 일을 직접 수행하는 진정한 의미의 'AI 개인 비서(Agent)'를 구현한 경험을 공유합니다.
AI 개인 비서의 필수 조건
진정한 '개인 비서'라면 갖춰야 할 핵심 능력 7가지를 정의하고, 이를 어떻게 기술적으로 달성했는지 정리했습니다.
1. 시공간을 초월한 업무의 연속성 (Ubiquity & Continuity)
"도구의 장벽을 허물고, 언제 어디서나 맥락을 잇다"
우리는 업무 시간 내내 컴퓨터 앞에만 앉아 있을 수 없습니다. 식사, 이동, 급한 미팅 등 물리적으로 자리를 비워야 하는 순간은 필연적입니다. 하지만 진정한 문제는 물리적 이동보다 '맥락의 단절(Context Switching)'에 있습니다.
개발은 VS Code에서, 분석은 Jupyter에서, 소통은 Slack에서 이루어지는 현재의 파편화된 환경에서는 도구를 바꿀 때마다 업무의 흐름이 끊깁니다. 밖에서 급한 이슈를 처리하려 해도, 회사 컴퓨터에 있는 환경과 달라 맥락을 이어가기 어렵죠. 진정한 AI 비서라면 "내가 어디에 있든, 어떤 기기를 쓰든 내 업무의 흐름을 꿰뚫고 있어야" 합니다.
해결책: 단일 작업 공간(Single Server Workspace)을 통한 통합
이 필수 조건을 달성하기 위해 저는 '단일 서버 작업 공간' 모델을 채택했습니다. 모든 업무 환경과 AI의 두뇌를 로컬 PC가 아닌, 안전한 중앙 서버 한곳에 통합하는 것입니다. 우리가 사용하는 다양한 단말기는 이 서버에 접속하는 '창구' 역할만 수행합니다.
스마트폰 (Slack): 슬랙 봇을 통해 서버에 명령을 내립니다. 이동 중인 지하철 안에서도 사무실 컴퓨터에서 하던 복잡한 코드를 실행하고 결과를 확인할 수 있습니다.
개발자 (VS Code): 'Remote - SSH' 기능으로 서버에 직접 접속하여 개발합니다. 로컬 자원을 쓰지 않고 서버 환경을 그대로 사용합니다.
분석가 (Jupyter): 서버에서 구동되는 Jupyter에 웹으로 접속하여 분석을 수행합니다.
얻게 되는 가치: 끊김 없는 맥락과 효율
이러한 통합 구조는 단순한 원격 접속을 넘어, 업무 방식 자체를 혁신합니다.
맥락의 영속성 (Continuous Context): 모든 AI와의 대화와 작업 상태(State)가 서버 한곳에 저장됩니다. 사무실에서 진행하던 심도 있는 코드 리뷰나 디버깅 세션을, 퇴근길 슬랙에서 아무런 위화감 없이 이어서 진행할 수 있습니다. 도구가 바뀌어도 AI의 기억은 사라지지 않습니다.
비동기 작업의 완벽한 연결: 시간이 오래 걸리는 데이터 분석 모델 학습을 Jupyter에 걸어두고 퇴근한다고 가정해 봅시다. 분석이 완료되면 AI가 슬랙으로 알림을 보내고, 저는 "결과 나왔네? 이걸로 시각화 보고서 만들어줘"라고 한마디만 던지면 됩니다. AI는 주피터에서 수행했던 앞단의 모든 맥락을 기억하고 있기에 즉시 다음 업무를 수행할 수 있습니다.
보안과 관리의 단순화: 슬랙용, IDE용 AI를 따로 만들 필요가 없습니다. 서버에 한 번만 세팅하면 모든 곳에서 똑똑한 AI를 사용할 수 있습니다. 또한, 중요한 접근 키나 소스 코드를 분실 위험이 있는 로컬 장비에 둘 필요 없이, 서버 내에서 안전하게 중앙 집중 관리할 수 있습니다.
결국, 단말기나 장소를 바꾸더라도 "하나의 작업 공간"을 바라보게 함으로써, 업무의 맥락을 잃지 않고 물 흐르듯 일을 처리할 수 있게 됩니다. 이것이 AI 개인 비서의 가장 중요한 토대입니다.
2. 대화를 넘어 '실행'으로: 실질적인 권한 이양 (Actionable Capability)
"비서의 본질은 말동무가 아니라, 내 손발이 되어주는 것"
우리가 비서에게 기대하는 것은 단순히 대화하거나 조언을 듣는 것이 아닙니다. 내가 물리적으로 모든 일을 다 처리할 수 없을 때, 내 옆에서 나를 대신해 사내망에 접속하고, 클라우드 리소스를 제어하며, 코드를 수정하는 '실질적인 업무(Execution)'를 수행하는 것입니다. "저는 권한이 없어서 그건 못해요"라고 말하는 비서는 반쪽짜리에 불과합니다.
문제점: 로컬 환경의 보안 제약
하지만 현실적인 장벽이 있습니다. 바로 '보안(Security)'입니다. 대부분의 기업 환경에서는 보안상 로컬 PC에 강력한 권한을 부여하지 않습니다. 예를 들어, 저희 회사에서는 AWS 접근 키(Access Key)나 민감한 프로덕션 DB 접근 권한을 로컬 노트북에 저장하는 것을 엄격히 금지합니다. 이 때문에 로컬에서 구동되는 AI는 아무리 똑똑해도 할 수 있는 일이 극히 제한적일 수밖에 없습니다.
해결책: 안전한 서버 환경에서의 권한 위임
저는 이 문제를 VPN 내부의 보안 서버를 통해 해결했습니다. 로컬 PC와 달리, VPN으로 보호받는 서버는 비교적 다양한 권한과 접근성을 가집니다.
핵심 아이디어는 "AI를 내 로컬이 아닌, 권한이 부여된 서버 위에서 살게 하는 것"입니다. 서버 위에서 구동되는 AI는 그 서버가 가진 권한을 그대로 상속받습니다. 즉, AI가 서버에서 실행된다는 사실 하나만으로, AI는 나의 권한(Identity)을 가지고 내가 할 수 있는 모든 일을 대신 수행할 수 있는 대리인(Proxy)이 됩니다.
나의 역할: 도구와 지식의 제공
이제 제가 할 일은 AI에게 일일이 명령어를 타이핑해 주는 것이 아닙니다. AI라는 대리인이 마음껏 뛰어놀 수 있는 작업 공간(Workspace)을 마련해 주는 것입니다.
도구(Tools): MCP(Model Context Protocol) Tool이나 Agent Skill 형태로 사내 시스템 연동 도구를 쥐여줍니다.
지식(Knowledge): 업무 처리에 필요한 규정이나 가이드를 문서로 제공합니다.
권한이 있는 서버 위에서 적절한 도구를 쥔 AI는, 단순한 챗봇을 넘어 실질적인 업무를 완결하는 진정한 에이전트로 거듭납니다.
3. 스스로 성장하는 에이전트: 도구의 자가 발전 (Self-Evolving Tooling)
"도구가 없으면 만들어서 쓴다. 코딩 없이도 확장되는 능력"
앞서 AI에게 시스템 접근 권한(Permission)을 부여했지만, 권한만 있다고 해서 모든 일을 처리할 수 있는 것은 아닙니다. 권한은 '자격'일 뿐, 실제 업무를 수행할 '수단(Tool)'이 필요하기 때문입니다.
과거에는 AI에게 새로운 업무를 시키려면 개발자가 일일이 API 연동 코드를 짜거나, 전용 스크립트를 작성해서 손에 쥐여줘야 했습니다. 이는 배보다 배꼽이 더 큰 상황을 만들고, AI 활용의 가장 큰 병목이 되곤 했습니다.
해결책: AI 주도의 도구 개발 및 재사용
최신 AI Agent(특히 Claude Code 등)의 가장 놀라운 점은 "필요한 도구를 스스로 만들어 쓴다"는 것입니다. 이제 저는 복잡한 코딩을 직접 하지 않습니다. 그저 "이 API를 사용해서 이런 기능을 하는 도구(Skill)를 만들어줘"라고 자연어로 요청하면 끝입니다.
AI는 다음과 같은 자가 발전 사이클을 통해 성장합니다:
제작 (Creation): 사용자의 요구사항을 분석하여 필요한 스크립트나 도구를 즉석에서 코딩합니다.
검증 및 수정 (Self-Correction): 만든 도구를 바로 실행해 봅니다. 에러가 발생하면 스스로 로그를 분석하고 디버깅하여 코드를 고칩니다.
자산화 (Registration): 테스트를 통과해 안정화된 도구는 자신의 스킬셋(Skillset)에 등록합니다. 이제 이 도구는 일회성으로 끝나지 않고, 다음번에 동일한 요청이 왔을 때 즉시 꺼내 쓸 수 있는 '나만의 무기'가 됩니다.
효과: 코딩 없는 업무 자동화 (Zero-Code Automation)
결과적으로, AI에게 일을 시키기 위해 제가 직접 코딩을 할 필요가 사라집니다. 저는 그저 무엇(What)이 필요한지 정의만 하면 됩니다. 도구를 만들고, 고치고, 최적화하는 어떻게(How)의 영역은 AI가 스스로 해결합니다. 이것이 바로 시간이 지날수록 주인의 개입은 줄어들고, 비서의 능력은 기하급수적으로 늘어나는 '성장형 AI 비서'의 핵심입니다.
4. 지식의 구조화와 다중 프로젝트 완결성 (Structured Knowledge & Multi-Project)
"똑똑한 신입사원에게 필요한 것은 산더미 같은 자료가 아니라, 잘 정리된 업무 인수인계서입니다."
아무리 뛰어난 도구와 권한을 쥐여줘도, 일하는 방법(How)이 담긴 '매뉴얼'이 없다면 복잡한 업무를 수행할 수 없습니다. AI 에이전트를 우리 회사에 막 입사한 '능력 있는 신입사원'이라고 생각해 봅시다. 이 신입사원은 코딩도 잘하고 분석도 잘하지만, 우리 회사의 히스토리나 업무 규칙은 전혀 모르는 상태(Blank Slate)입니다. 이때 수백 장의 문서 더미를 던져주며 "이거 읽고 알아서 일해"라고 한다면, 사람도 AI도 길을 잃고 맙니다.
따라서 AI 비서를 제대로 활용하기 위해서는 사내 지식의 구조화(Knowledge Structuring)가 선행되어야 합니다.
1) 프로젝트 단위의 지식 관리 (Git Repo as a Knowledge Unit)
지식은 흩어져 있으면 안 됩니다. 위키(Wiki), 노션(Notion), 구글 드라이브 등에 파편화된 문서는 AI가 접근하기도, 문맥을 파악하기도 어렵습니다. 저는 Git Repository 하나를 하나의 프로젝트 단위로 정의하고, 그 안에 소스 코드와 함께 업무 매뉴얼을 포함시킵니다.
구조화된 문서: 각 프로젝트 폴더 내부는 전략, 디자인, 설계, 개발, 테스트, 배포, 모니터링 등 업무 영역별로 폴더링하여 문서를 관리합니다.
접근성: 모든 문서는 AI가 활동하는 작업 공간(Workspace) 내에 위치하여, 별도의 검색 과정 없이 즉시 참고할 수 있게 합니다.
2) 단일 공간에서의 다중 프로젝트 수행 (Multi-Project Execution)
기존 개발 환경에서는 프로젝트 A를 하다가 B로 넘어가려면 IDE 창을 새로 열거나, 번거로운 컨텍스트 스위칭이 필요했습니다.
하지만 AI의 작업 공간(Server)에는 내가 관여하는 모든 프로젝트의 Git Repo를 한곳에 모아둡니다(Clone). 이 방식은 강력한 시너지를 냅니다.
경계 없는 업무 처리: 여러 프로젝트가 얽힌 복합적인 업무(예: "백엔드 프로젝트 A의 API 변경 사항을 프론트엔드 프로젝트 B에 반영하고, 공통 모듈 C를 업데이트해줘")를 수행할 때, AI는 창을 오갈 필요 없이 한 공간에서 즉시 파일을 수정하고 연동 테스트를 진행합니다.
문맥 기반 자동화: 사용자가 "A 프로젝트 배포해줘"라고 요청하면, AI는 A 프로젝트 폴더로 이동하여 그곳에 정의된 배포 매뉴얼을 찾아 읽고 실행합니다.
결국, "모든 프로젝트가 모인 하나의 작업 공간"과 "잘 정리된 프로젝트별 매뉴얼"이 결합될 때, AI는 단순 보조를 넘어 복잡한 프로젝트를 넘나드는 멀티 플레이어로 거듭납니다.
5. 단일 속도의 한계를 넘는 '병렬 동시 수행' (Massive Parallelism)
"실무자에서 감독관(Director)으로: 나만의 AI 군단을 지휘하는 법"
솔직히 말해, AI가 하나의 단일 업무를 수행하는 속도를 보면 답답할 때가 있습니다. 숙련된 개발자가 직접 코딩하는 것이 AI가 문맥을 파악하고 코드를 생성하는 것을 기다리는 것보다 빠를 때가 많죠. 하지만 AI 활용의 핵심은 '속도(Latency)'가 아니라 '처리량(Throughput)'에 있습니다. AI의 작업이 완료될 때까지 멍하니 로딩 바만 바라보고 있다면, 그것은 병목(Bottleneck)이 되고 맙니다.
우리는 일하는 방식을 바꿔야 합니다. 사용자의 역할은 직접 코딩하는 '작업자'에서, 여러 AI에게 업무를 할당하고 관리하는 '감독관(Director)'으로 변해야 합니다. 한 명의 AI에게 일을 시키고 기다리는 것이 아니라, 10명의 AI에게 동시에 서로 다른 업무를 지시하고 병렬로 돌려야 합니다.
기술적 해법: 작업 공간의 격리와 병렬 복제
그렇다면 하나의 프로젝트에서 여러 AI가 동시에 코드를 수정할 때 발생하는 충돌(Conflict)은 어떻게 해결할까요? 방법은 의외로 간단합니다. 물리적인 작업 공간을 분리하는 것입니다.
다중 클론(Multiple Clones): 동일한 Git Repository라도 병렬 수행 개수만큼 폴더를 복제하여 받아옵니다(예: Project-A-Task1, Project-A-Task2).
브랜치 전략: 각 AI는 서로 다른 복제본 폴더에서 서로 다른 브랜치를 따서 독립적으로 작업합니다. 이렇게 하면 파일 잠금이나 충돌 걱정 없이 여러 AI가 동시에 같은 프로젝트의 다른 기능들을 개발할 수 있습니다.
업무 프로세스: 지시하고, 리뷰하고, 승인하라
이 환경에서 사람은 더 이상 코드를 짜는 데 시간을 쓰지 않습니다. 대신 '결정'하는 데 시간을 씁니다.
지시 (Dispatch): AI들에게 각각의 이슈(Jira Ticket 등)를 할당하고 "PR 올려줘"라고 지시합니다.
비동기 업무 (Async Work): AI들이 각자의 브랜치에서 끙끙대며 코딩하는 동안, 저는 다른 기획을 하거나 커피를 마십니다.
검토 및 병합 (Review & Merge): "PR 생성 완료" 알림이 오면 코드를 리뷰합니다. 수정이 필요하면 다시 반려(Request Changes)하고, 문제가 없다면 머지(Merge)를 승인합니다.
배포 자동화: 머지 후 테스트, 배포, 모니터링까지 AI에게 일괄 위임합니다.
이것이 바로 AI 시대를 살아가는 1인 개발자, 혹은 소규모 조직이 '군단'처럼 움직일 수 있는 비결입니다.
6. 모든 업무의 투명한 기록과 추적 (Automated Logging & Traceability)
"기억하지 못하는 비서는 반쪽짜리입니다. 블랙박스 없는 투명한 업무 환경을 만듭니다."
우리는 종종 과거의 행적에서 답을 찾곤 합니다. "어제 갔던 그 식당 이름이 뭐였지?"라고 물었을 때, 친구가 답해줄 수 있는 건 함께 갔던 기억이 있기 때문입니다. 반면, AI가 이런 질문에 답하지 못하는 이유는 능력이 부족해서가 아니라, 단지 내 생활 패턴(위치 정보, 결제 내역 등)에 접근할 수 없기 때문입니다.
업무도 마찬가지입니다. AI와 협업할 때 가장 답답한 순간은 어제 했던 논의나 작업을 AI가 잊어버렸을 때입니다. 이를 해결하기 위해 저는 '모든 작업 과정의 자동 기록'을 원칙으로 삼았습니다.
1) 지침(Instruction)을 통한 강제적 로깅 AI가 작업한 내용이 휘발되지 않도록 CLAUDE.md 지침 문서에 명확한 룰을 심었습니다. "모든 작업 수행 후, 수행 내역과 결과를 날짜별 Task 문서에 시간순으로 기록하라." 이 한 줄의 지침 덕분에, 별도의 노력을 들이지 않아도 AI의 모든 활동은 로그(Log)로 남게 됩니다.
2) 과거 맥락의 소환과 재현 (Context Recall & Replay) 이렇게 축적된 기록은 강력한 자산이 됩니다.
업무 요약: "어제 내가 무슨 일을 했지? 요약해줘"라는 질문에 AI는 로그를 바탕으로 정확한 브리핑을 제공합니다.
작업의 재생산: "지난주에 했던 A 프로젝트 배포 작업, 오늘 다시 똑같이 수행해줘"라고 요청하면, AI는 과거의 성공 기록을 참고하여 실수를 반복하지 않고 작업을 완수합니다.
AI로만 업무를 처리하는 사용자라면, 사실상 모든 업무 이력이 100% 투명하게 텍스트로 남는 셈입니다. 이는 추후 업무 인수인계나 회고를 할 때도 엄청난 효율을 가져다줍니다.
3) 분석의 재현성 확보 (Jupyter Automation) 특히 데이터 분석 업무에서는 '결과'보다 '과정'이 중요할 때가 많습니다. 분석 결과가 의심스러울 때, 어떤 코드를 돌려서 나온 값인지 검증해야 하기 때문입니다. 이를 위해 분석 작업 시에는 단순 텍스트 로그뿐만 아니라, 실행된 코드와 결과값이 포함된 Jupyter Notebook 파일(.ipynb)이 자동으로 저장되도록 구성했습니다. 덕분에 언제든 과거의 분석 로직을 열어보고 검증할 수 있는 '재현 가능한(Reproducible)' 분석 환경을 구축했습니다.
7. 능동적인 비서의 완성: 일정 관리와 자동화 (Proactive Scheduling)
"시키는 일만 하는 비서는 하수입니다. 때가 되면 알아서 보고하고 움직이는 것이 진짜 비서입니다."
지금까지의 기능들이 사용자의 명령을 기다리는 '수동적(Reactive)'인 능력이었다면, 일정 관리는 AI가 먼저 사용자에게 말을 걸고 행동하는 '능동적(Proactive)'인 단계로의 진화를 의미합니다. 훌륭한 비서는 주인이 "오늘 일정 알려줘"라고 묻기 전에, 출근길에 오늘의 브리핑 자료를 내밉니다.
저는 AI 에이전트에게 '시간 감각(Sense of Time)'을 부여하여 이 기능을 구현했습니다. 방법은 간단합니다. AI에게 일회성(One-off) 또는 반복성(Recurring) 작업을 예약할 수 있는 스케줄링 도구를 쥐여주는 것입니다.
1) 데일리 브리핑 (Daily Briefing): 하루의 시작을 정리하다
매일 아침 9시, AI는 저에게 먼저 슬랙 메시지를 보냅니다. 단순한 알람이 아닙니다.
어제의 요약: 어제 수행했던 업무 로그(Task Document)를 분석하여 핵심 내용을 요약합니다. ("어제 A 프로젝트 배포까지 완료하셨습니다.")
오늘의 할 일: 오늘 마감인 티켓이나 예정된 캘린더 일정을 확인하여 우선순위를 정리해 줍니다. ("오늘 오후 2시에 미팅이 있고, B 이슈 수정이 시급합니다.")
이 브리핑 하나만으로도 하루의 업무 시작점이 달라집니다. 전날의 기억을 되살리고, 오늘 집중해야 할 곳을 명확히 할 수 있기 때문입니다.
2) 특정 시점의 자동 실행 (Scheduled Execution)
단순히 알려주는 것을 넘어, 특정 시간에 행동하도록 예약할 수도 있습니다.
"오늘 밤 3시에 트래픽이 적을 때 이 코드를 배포하고, 결과만 아침에 알려줘."
"매주 금요일 오후 5시마다 주간 업무 리포트를 작성해서 초안을 보여줘."
이처럼 스케줄링 도구를 통해 사용자는 시간에 구애받지 않고 업무를 예약(Defer)할 수 있으며, AI는 24시간 깨어있는 비서로서 그 약속을 충실히 이행합니다.
구현 전략: 철학을 기술로 구체화하다
앞서 언급한 AI 비서의 필수 조건들을 달성하기 위해, 저는 아래 두 가지 핵심 철학을 바탕으로 시스템을 설계했습니다.
Single Workspace & Ubiquity: 단 하나의 작업 공간에서 모든 것을 수행하며, 어디서든 이 공간을 호출할 수 있어야 한다.
Structured Context: 프로젝트 문서와 태스크 문서를 구조화하여 AI의 지식과 기억을 체계적으로 관리한다.
이 철학을 어떻게 실제 아키텍처로 구현했고, 이를 전사적으로 확장하기 위해 어떤 구상을 하고 있는지 상세히 공유합니다.
1. The Engine: AI Agent 선정 (Claude Code)
수많은 AI 모델 중 Claude Code를 핵심 엔진으로 선택한 이유는 명확합니다.
강력한 도구 확장성: 업무 자동화에 필수적인 MCP(Model Context Protocol)와 Agent Skills를 가장 강력하게 지원합니다.
비용 및 환경의 자유로움: 대부분의 AI 서비스가 서버에서 호출하려면, 호출시 API 호출당 과금되는 반면, Claude Code는 구독형 모델을 통해 서버 및 다양한 환경에서 비교적 자유롭게 사용할 수 있습니다. 서버에 상주하며 지속적으로 맥락을 유지해야 하는 개인 비서 모델에 최적화되어 있습니다.
2. The Workspace: 지식과 기억의 구조화
물리적인 서버 공간 안에 논리적인 작업 공간을 어떻게 구성했는지가 핵심입니다.
프로젝트 문서 (Knowledge Base):
사용자가 작업하는 모든 Git Repository 폴더를 하나의 작업 공간에 모아둡니다.
최상위에 CLAUDE.md 지침 문서를 두어, 각 폴더의 용도와 참고 시점을 명시합니다. AI는 이 지도를 보고 "지금 A 프로젝트를 참고해야겠군"이라고 판단합니다.
Task 문서 (Memory Log):
AI와의 모든 상호작용은 휘발되지 않고 기록됩니다. CLAUDE.md에 "모든 요청과 수행 내용을 날짜별 Task 문서에 남겨라"는 지침을 심어두었습니다.
이곳에는 대화 내용뿐만 아니라, 수행 결과, 생성된 Jupyter Notebook 파일 등이 함께 저장됩니다. 이는 추후 업무 히스토리를 추적하거나 동료에게 공유할 때 핵심 자산이 됩니다.
도구 (Dynamic Tools):
Claude Agent Skill의 높은 자유도를 활용합니다. 코딩 없이 자연어로 "이런 기능을 하는 스킬을 만들어줘"라고 요청하여 도구를 즉석에서 추가하고 사용합니다.
3. Server Architecture: 확장 가능한 컨테이너 전략
현재는 단일 EC2 인스턴스에서 사용하고 있지만, 전사 확장을 위해 '1 User = 1 Docker Container' 구조를 구상하고 있습니다.
1) 사용자별 독립 컨테이너 (Personalized Isolation)
사용자마다 필요한 지식(Context), 업무 방식, 권한(Permission)이 천차만별입니다. 따라서 공용 봇을 사용하는 대신, 각 사용자에게 독립된 AI Agent 서버(Docker Container)를 할당하는 방식을 택했습니다.
Slack Redirection: 슬랙 봇이 요청을 받으면, 해당 요청을 보낸 유저(User ID)를 식별하여 그 유저의 개인 작업 공간(Container)으로 라우팅(Redirect)합니다. 이를 통해 모두가 자신만의 맞춤형 비서를 안전하게 소유할 수 있습니다.
각 사용자마다, 각 기능마다 슬랙 봇을 만들 수도 있지만, 이렇게 하면, 슬랙에 너무 많은 봇이 넘쳐나고 관리가 어렵고, 사용자도 매번 어떤 봇을 태깅해야 할지 헷갈립니다. 봇은 하나로 단일화 했을 때, 사용이 쉽습니다.
권한별 작업공간: 꼭 사용자만 나눌 필요 없습니다. 별도의 업무 콘솔내에 위치하며, 업무 콘솔의 권한으로 돌아가게 할 수도 있고, 여러 사용자가 하나의 작업공간 및 권한으로 같은 업무를 수행할 수도 있습니다. 핵심은, 어떤 작업공간을 원하든, 하나의 docker image를 배포하는 것만으로 바로 작업공간을 제공할 수 있다는 것입니다.
2) Docker Image 구성
AI Agent 서버는 표준화된 Docker Image로 관리되어 배포와 확장이 용이합니다. 컨테이너 내부 구성 요소는 다음과 같습니다.
API Server: Slack 및 외부 요청을 수신하는 Gateway
Claude Code: AI 핵심 엔진
Jupyter Kernel: 데이터 분석 및 코드 실행 환경
이 컨테이너를 띄우고 사용자의 개인 작업 공간(Git Repo 등)만 볼륨으로 연결하면, 즉시 '나만의 AI 비서'가 생성됩니다.
4. Client Environments: 어디서든 접속 가능한 인터페이스
서버(Docker Container)는 하나지만, 사용자는 상황에 따라 다양한 단말(Interface)을 통해 접속합니다.
Remote IDE (VS Code)
개발자는 VS Code Remote - SSH 기능을 통해 서버 컨테이너에 직접 접속합니다.
로컬 자원을 쓰지 않고 서버 환경에서 작업하므로, 로컬 설정의 번거로움 없이 권한이 부여된 환경에서 쾌적하게 개발할 수 있습니다.
Jupyter extension으로 쥬피터도 사용 가능합니다.
Openvscode-server 등 web IDE도 있는데, 스마트폰에서 사용할 수 있는 큰 장점이 있지만, 여러가지 불편한점이 많아 연구가 필요합니다.
Jupyter (Web)
분석가는 웹 브라우저를 통해 서버 내 Jupyter에 접속합니다.
파일 탐색기로 문서를 관리하고, 터미널이나 매직 함수(Magic Function), Panel Plugin 등을 통해 AI에게 직접 명령을 내릴 수 있습니다.
VS code를 쓰지 않는 비개발자들이 분석할 때 사용합니다.
Slack
가장 접근성이 높은 인터페이스입니다. Slack Bolt SDK를 통해 사용자의 요청이 API 서버로 전달되고, Claude가 이를 처리하여 응답합니다.
이동 중이거나 간단한 업무 처리에 최적화되어 있어, 대부분의 간단한 분석, 이슈 대응, 유지보수는 슬랙에서 가능합니다.
슬랙의 가장 큰 장점은 대부분의 이슈 알림, 동료의 요청이 슬랙으로 오기 때문에, 요청사항을 복사해서 AI한테 전달할 필요 없이, 바로 요청 및 결과를 공유 할 수 있다는 것입니다.
업무 Console
사내 고객 관리, 대출 관리 등 레거시 웹 콘솔 시스템에서도 API 호출만으로 AI 기능을 간단하게 연동하여 사용할 수 있습니다.
업무 콘솔에 container를 올렸을 때의 장점은, 업무 콘솔만이 가지고 있는 권한과 접근 가능한 리소스를 AI가 동일하게 사용 가능하다는 것입니다. 그래서, 사용자 컨테이너에서는 접근 하기 민감한 데이터의 경우, 업무 콘솔에서 접근하되 AI를 통해 효율적으로 활용할 수 있게 합니다.
(참고) 왜 Local IDE 방식은 지양했는가?
초기에는 로컬 PC에 작업 공간을 두고 Claude를 호출하는 방식도 고려했습니다. 하지만 다음과 같은 한계로 인해 서버 중심 아키텍처로 완전히 전환했습니다.
동기화의 어려움: 로컬 작업 내용이 다른 환경(Slack 등)과 실시간으로 공유되지 않음.
보안 및 권한: 로컬 PC에 민감한 AWS Key나 사내망 접근 권한을 부여하기 어려움.
연결의 번거로움: 리소스 접근시마다 SSH 터널링 등 복잡한 과정을 거쳐야 함.
결국, "모든 것은 서버에 있고, 나는 그곳을 바라볼 뿐"이라는 구조가 AI 비서의 효용을 극대화하는 정답이었습니다.
다만, 아래 케이스에서는 로컬에서 필요하긴 합니다.
유튜브 대본 가져오기처럼 서버에서 안되거나,
서버에 두기 민감한 개인 정보와 로그인된 계정으로 브라우저 접근이 필요한 경우
맺음말
여기까지가 “AI를 쓰는 법”이 아니라, AI 비서를 ‘고용’하기 위한 설계의 최소 조건입니다.
핵심은 단순합니다. 모든 것이 서버에 있고, 나는 어디서든 그 작업공간을 호출한다는 전제 위에, AI가 실제로 움직일 수 있도록 권한과 도구를 위임하고, 잊지 않도록 지식과 기록을 구조화하는 것입니다. 이 구조가 잡히면, 모델이 바뀌어도 자산은 남습니다. 도구와 문서, 그리고 작업 로그가 쌓일수록 비서는 더 안정적으로 “내 방식대로” 일하게 됩니다.
다음 2부에서는 이 철학이 실제 업무에서 어떻게 작동하는지, 제가 어떤 도구를 붙였고(Slack/IDE/Jupyter/스케줄링/전문 Skills), 어떤 기능으로 UX를 다듬었는지, 그리고 배포·장애 분석·Text2SQL·업무 리포트 자동화 같은 실전 사례로 “정말 편해졌는가”를 보여드리겠습니다. 이제 설계도를 들고, 실제로 굴려볼 차례입니다.
