8가지 병목을 없앴더니, AI 비서가 능동적으로 움직이기 시작했다

범용 앱은 80%만 만족시키지만, 내가 직접 만든 앱은 100%를 채울 수 있다 — 요즘 SaaS 위기론의 본질이 이거잖아요. 이 글의 저자는 그걸 AI 비서에 적용했어요. 전편에서 서버에 AI 두뇌를 올리고 Slack, VS Code, CLI 등 다양한 환경에서 접속하는 청사진을 그렸는데, 막상 매일 쓰다 보니 불편한 점이 끊임없이 보였대요.

"Slack에서 AI 응답이 끝났는지 모르겠네." "VS Code에서 하던 걸 이동 중에 확인하려는데 답답하네." "여러 작업을 동시에 시켰는데 뭐가 끝났는지 한눈에 안 보이네." 보통이라면 참거나 다른 앱을 찾아 헤매는데, 이 사람은 불편한 점을 발견하면 AI에게 바로 고치게 시켰어요. 그 과정이 8개 병목을 하나씩 제거하는 여정으로 남았더라고요.

VS Code에서 시킨 작업을 이동 중 Slack에서 그대로 본다

첫 번째 병목. VS Code에서 AI에게 코드 리뷰를 시켜놓고 점심 먹으러 나가면, 스마트폰으로 진행 상황을 보기 불편했어요. 터미널 세션에 종속되니까 여러 클라이언트가 같은 세션을 동시에 볼 수 없고, 연결이 끊기면 그 사이 진행된 내용을 놓치고, 환경이 바뀌면 개입할 수 없었거든요. "이 부분은 다른 방향이었어야 하는데..." — 이미 AI는 잘못된 방향으로 한참 진행한 뒤.

해결책은 서버-클라이언트 분리.

Claude Agent SDK와 소통하는 서버 앱을 별도로 만들고, 각 접속 환경은 이 서버에 연결되는 클라이언트로 분리했어요. 서버 앱이 Claude와의 통신, 세션 관리, 이벤트 저장을 전담하고, 클라이언트는 순수하게 UI만 담당해요. 이 분리 덕분에 클라이언트를 꺼도 AI는 멈추지 않고, 끊겼다 다시 연결해도 서버가 모든 응답에 순번을 매겨 저장해뒀으니까 놓친 부분만 이어 받아요.

핵심은 VS Code에서 요청한 작업이 Slack에서도 실시간으로 스트리밍된다는 거예요. 같은 세션에 여러 클라이언트가 동시에 붙어 있으니까, 이동 중에 스마트폰으로 Slack을 열면 AI가 지금 뭘 하고 있는지 그대로 보여요.

스트리밍 도중에라도 VS Code든 Slack이든 어디서든 메시지를 추가할 수 있어요. 추가된 메시지는 대기열에 쌓였다가 AI에게 전달되고, AI는 그 내용을 반영해서 작업 방향을 수정해요. 끝날 때까지 기다렸다가 처음부터 다시 시킬 필요가 없어요.

완료 알림 + 세션 대시보드로 병렬 작업 관리

두 번째 병목은 단순했어요. AI에게 분석 시켜놓고 다른 일 하다 보면, 끝났는지 아직 하는 중인지 알 수가 없었던 것.

Mac 알림은 SSH를 통해 원격 서버 상태를 감지해서 macOS 알림을 띄우고, 클릭하면 VS Code의 해당 대화로 이동해요. Slack에서는 실시간 스트리밍 중에 알림이 안 울리니까 스트리밍이 끝나면 별도의 최종 메시지를 전송해서 Slack 알림을 트리거하고요. 다른 채널을 보고 있다가도 AI 작업이 끝나면 바로 알 수 있어요.

세 번째 병목은 여기서 한 단계 더 나아간 거예요. 세션 A에서 데이터 분석, 세션 B에서 코드 리뷰, 세션 C에서 Jira 정리 — 이렇게 병렬로 시켜놓으면 뭐가 끝났고 뭐가 진행 중인지 파악이 안 됐거든요.

서버가 모든 세션 상태를 관리하니까, 대시보드를 만들었어요.

응답 완료된 세션은 결과를 바로 확인할 수 있고, 진행 중인 세션은 실시간으로 뭘 하는지 보이고, 대기 중인 세션은 승인 버튼을 눌러 이어갈 수 있어요. 아래는 Slack과 VS Code의 세션 대시보드인데, 진행중, 대기, 완료 등을 한눈에 확인할 수 있어요.

Slack에서도 Plan 모드 — 이동 중에 복잡한 작업을 컨트롤한다

네 번째 병목. VS Code에서는 AI가 Plan 모드로 계획을 세우고 승인을 받는 흐름이 자연스럽잖아요. 근데 Slack에서는 이게 안 됐어요. 이동 중에 복잡한 작업을 시키면 AI가 중간에 확인이 필요한 순간에 막혀버렸다는 거예요.

Plan 모드에서 AI가 계획을 세우면 Slack에 승인/수정 요청 버튼이 표시돼요. AI가 판단이 필요할 때 Slack 버튼으로 선택지를 제시하고요. AI가 작업 중일 때 추가 메시지를 보내면 대기열에 쌓였다가 자연스럽게 반영됩니다. 이제 이동 중에도 복잡한 작업의 전체 흐름을 Slack 하나로 컨트롤할 수 있어요.

"복잡한 작업을 계획 세워줘"라고 요청하면 알아서 plan mode에 진입해서 계획을 세우고, 계획 문서를 Slack canvas로 변환해서 승인 여부를 물어와요. 다이어그램과 표가 포함된 구체적인 계획을 확인하고, 승인, 거절, 수정 요청이 가능해요.

다섯 번째 병목은 가독성이었어요. AI가 분석 결과를 장문의 텍스트로 쏟아내면 핵심 파악이 어렵잖아요. "A가 B를 호출하고, B는 C에 요청을 보내는데..." — 읽다 보면 머릿속에서 그림을 그리느라 정작 본질을 놓쳐요.

AI에게 "Markdown 표와 Mermaid 다이어그램을 적극 활용하라"는 지침을 넣고, 모든 클라이언트에서 렌더링 가능하게 만들었어요. VS Code에서는 대화 화면에서 바로 렌더링, Slack에서는 Block Kit 테이블 + PNG 이미지 변환, Web UI에서는 인터랙티브 다이어그램. 텍스트로 20줄 넘게 설명할 내용이 다이어그램 한 장으로 끝나요. (참고로 원문의 모든 다이어그램도 이 방식으로 생성한 거래요.)

시간 트리거 + 이벤트 트리거 — AI가 먼저 움직이는 비서가 된다

여섯 번째 병목이 가장 근본적인 문제였어요. 아무리 AI가 강력해도 내가 먼저 말을 걸어야 일을 시작한다는 것. 매일 반복되는 업무를 매번 직접 요청하는 것도, Slack에 올라온 장애 메시지를 직접 발견해서 분석을 시키는 것도 결국 사람 몫이었거든요.

두 가지 트리거를 만들었어요. 시간 트리거는 cron 기반 스케줄러로, 정해진 시간에 AI가 알아서 작업을 수행해요. 매일 아침 어제 업무 요약 + 오늘 일정 브리핑, 매주 자동 주간 리포트, 특정 시간에 배포 후 결과 알림. "오늘 밤 3시에 배포하고 결과 아침에 알려줘" 같은 일회성 예약도 되고요.

이벤트 트리거는 Slack 채널에서 특정 키워드나 패턴이 감지되면 미리 설정한 프롬프트에 따라 AI가 자동으로 작업을 수행해요. PR 링크가 올라오면 diff 분석 후 GitHub에 리뷰 코멘트 자동 추가, "Deploy Failed" 키워드가 뜨면 Airflow 로그를 확인하고 원인 분석해서 스레드에 게시, 모니터링 알림이면 Grafana 대시보드를 확인하고 이상 여부를 판단해서 보고. 핵심은 트리거마다 프롬프트를 함께 설정할 수 있다는 점이에요. 단순히 "반응한다"가 아니라 어떤 맥락으로 무엇을 할지까지 정의할 수 있어요.

설정도 별도 UI 없이 AI에게 자연어로 말하면 돼요. "매일 아침 9시에 브리핑 보내줘", "#pr-review에서 PR 링크가 올라오면 코드 리뷰해줘" — AI가 설정 파일을 직접 수정하고 즉시 반영.

자동 기록 + AI 메모리 — 회의가 없어졌다

일곱 번째 병목. 매일 스탠드업 미팅, 주간 리뷰, "지금 어디까지 했어?" 질문. 업무를 하는 시간보다 공유하는 시간이 적지 않잖아요. 그리고 AI와 작업하면 또 다른 문제가 생겨요. AI가 어제 뭘 했는지, 어떤 실수를 했는지 기억하지 못한다는 거.

4단계 파이프라인이에요. 1단계, 모든 AI 요청은 날짜별 작업 문서에 자동 기록, 결과 요약과 개선점(Lessons Learned)까지 정리, 파일 변경은 Auto-Commit으로 git에 실시간 커밋. 2단계, 매일 파이프라인이 각 팀원의 git diff, Slack 메시지, Jira 티켓, 캘린더를 수집해서 프로젝트별 구조화된 일일 요약을 생성. 3단계, 요약이 Slack 채널에 공유되고 Jira 티켓에도 진행상황이 자동 업데이트. 코드 변경에는 GitHub compare 링크, Slack 대화에는 permalink, Jira 티켓에는 상태 변경 내역이 포함돼요. 4단계, 궁금한 점은 GitHub에 정리된 내용을 확인하고 Slack 스레드에서 바로 질문.

결과적으로 저자의 ML 파트는 정기 회의를 하지 않는대요.

AI 메모리도 흥미로운 부분이에요. AI는 문제가 생겨도 스스로 우회해서 넘어가잖아요. 결과만 보면 잘 된 것 같은데, 비효율적인 방식으로 해결한 건 사람이 모를 수 있어요. 그래서 작업 완료할 때마다 겪은 문제와 개선 사항을 작업 문서에 기록하게 했어요.

매일 아침 데일리 브리핑으로 어제 작업의 개선 사항을 보고하고, 한 주간 쌓인 걸 위클리 브리핑으로 모아보면 반복되는 비효율 패턴이 보여요. 같은 문제가 3번 나왔다면 우회가 아니라 근본 수정이 필요한 거죠. 개선된 내용은 메모리 파일에 저장돼서 이후 세션에서 자동 참조. 같은 실수를 반복하지 않아요.

EFS + 원격 Jupyter — GPU 서버 띄울 때마다 끊기던 흐름이 사라졌다

여덟 번째 병목은 ML 업무 특유의 문제예요. 일상 분석은 CPU 서버로 충분한데 모델 학습에는 GPU가, 수억 건 데이터 처리에는 Spark 클러스터가 필요하잖아요. 문제는 GPU 서버를 띄울 때마다 벌어지는 일. 서버 생성, 소스코드 업로드, 환경 설정, Jupyter 세팅... 이 환경이 메인 서버와 달라서 코드 수정할 때마다 동기화해야 했어요.

EFS(공유 파일 시스템)로 모든 서버가 같은 소스코드를 공유하고, 원격 Jupyter 연결로 VS Code 창 하나만 열어놓고도 다양한 서버의 연산 자원을 사용할 수 있게 만들었어요. 코드 동기화 필요 없음(EFS 덕에 수정하면 GPU 서버에 즉시 반영), VS Code 창을 새로 열 필요 없음(원격 Jupyter 연결하면 같은 워크스페이스에서 GPU 사용), GPU 커널 하나로 피처부터 학습까지(Spark Connect로 수억 건 데이터를 처리해 피처를 만들고 바로 GPU로 모델 학습). AI의 연속성도 유지돼요. Claude가 메인 서버에서 분석하다가 "이건 GPU로 돌려야겠다"고 판단하면 GPU 서버의 Jupyter에서 바로 실행.

GPU 서버 띄우는 것도 AI에게 시키면 돼요. "GPU 서버 하나 띄워줘. p3.2xlarge로." — AI가 EC2 생성, EFS 마운트, Jupyter 시작, SSH 터널 연결까지 알아서 하고 VS Code에서 자동 연결.

특히 강력한 건 Claude와 사용자가 같은 Jupyter 노트북에서 협업할 수 있다는 점이에요. Claude가 .ipynb 파일을 생성하고 코드 셀을 작성하고 실행 결과까지 채워주면, 사용자가 중간에 셀을 수정하거나 새 셀을 추가하고, Claude가 변경을 인지해서 이후 작업 방향을 조정하는 자연스러운 핑퐁이 가능해요.

VS Code 사이드바에 AWS 리소스 모아 보여주는 커스텀 Extension도 만들었더라고요. S3 버킷 탐색, Glue 카탈로그 트리, EC2 서버별 CPU/MEM 사용률, Spark 클러스터 현황까지 한 화면에서 확인할 수 있어요. AWS 콘솔이 모든 사용자의 모든 리소스를 보여준다면, 이건 내 서버, 내 버킷, 내 테이블만 보여줘요.

21개 스킬이 조합되면 침대에서 장애 분석이 끝난다

구조와 기능만으로는 와닿지 않으니까 실전 사례를 보면요. "이 테이블에서 최근 7일 DAU 뽑아서 팀 채널에 공유해줘" — 이 한 마디로 AI가 Glue Catalog에서 테이블 스키마 확인, 데이터 규모에 따라 Athena($5/TB)와 Spark 자동 선택, 결과를 Slack 테이블로 변환해서 팀 채널에 공유까지.

근데 진짜 인상적인 건 장애 분석 사례예요. 늦은 저녁 모니터링 채널에 알림이 왔는데, 스마트폰을 열어보니 멘션 트리거가 이미 작동해서 AI가 1차 분석을 끝내놓은 상태였어요. 코드 역추적까지 해놓고 다이어그램과 함께 분석 결과가 Slack에 올라와 있었다는 거예요. "이 부분 더 깊게 파봐" — Slack 스레드에서 추가 지시. 노트북 안 켜고 스마트폰 하나로 복합 장애 분석을 끝냈대요. (솔직히 이건 좀 부러운 얘기예요.)

현재 21개 스킬이 실제 업무 도구와 연동돼 있어요.

Glue + Athena + Slack으로 테이블 찾고 쿼리 실행해서 결과 공유, Jenkins + Grafana + Slack으로 배포 실행 후 메트릭 확인해서 이상 여부 보고, Jira + Google Docs + Calendar로 완료 이슈 조회해서 회고 문서 작성하고 미팅 잡기. 단독보다 조합했을 때 훨씬 강력해지는 구조. 새로운 스킬이 필요하면 AI에게 "이런 기능 하는 스킬 만들어줘"라고 말하면 돼요. AI가 직접 만들고 테스트하고 등록.

불편함을 고치는 사이클이 멈추지 않는 한, 도구는 계속 나에게 맞춰진다

이 글에서 소개한 모든 기능은 같은 패턴으로 만들어졌어요. 쓰다가 불편한 점 발견, AI에게 고치게 시킴, 바로 반영, 다시 쓰면서 새로운 불편 발견. 범용 앱은 이 사이클을 돌릴 수 없잖아요. 기능 요청 올리고, 로드맵에 잡히길 기다리고, 업데이트 나오길 바라야 하니까요.

실제로 이 시스템의 대부분은 저자가 직접 코딩한 게 아니래요. AI에게 요청하고, AI가 만들고, 쓰면서 피드백하고, AI가 다시 고치는 반복.

하루 종일 같은 AI가 서버에서 유지되고, 상황에 맞는 환경을 골라 접속하기만 하면 돼요. 아침에는 데스크톱 VS Code, 이동 중에는 Slack, 밤에는 스마트폰. 환경이 바뀌어도 맥락은 끊기지 않아요.

범용 앱은 80%를 만족시키지만, 불편함을 바로 고칠 수 있는 환경은 100%에 수렴한다. 근데 궁금한 건, 여러분의 업무 환경에서 참고 있는 불편함이 뭔지예요.