'몇 번의 클릭과 기다림마저 한마디로 끝낸 건에 대하여'

발단: 흐름을 끊는 수작업들

모바일 앱을 테스트하려면 네다섯 단계를 밟아야 했습니다.

1. GitHub Actions 대시보드 진입
2. iOS / Android 워크플로 각각 수동 실행
3. 빌드가 끝날 때까지 대기
4. 내부 빌드 어드민에서 해당 빌드 찾기
5. 디테일 화면에 들어가서 QR 코드 복사 후 슬랙에 공유

하루에도 몇 번씩 반복되는 일, 매번 귀찮았습니다. 빌드 자체의 시간보다 코딩을 하다가 브라우저를 열고 대시보드를 기다려야 하는 ‘흐름 끊김(Context Switching)’이 치명적이었습니다. "누가 대신 해줬으면 좋겠다"는 필요가 생겼고, 사내 LLM 에이전트 프로젝트를 시작하며 이 문제를 첫 번째 타깃으로 삼았습니다.

Q&A bot으로 시작했지만: 똑똑하지만 아무것도 할 수 없는

처음부터 빌드 같은 민감한 액션을 에이전트에게 맡기기엔 조심스러웠습니다. 
그래서 먼저 시도한 것은 프로젝트 코드를 학습시킨 Q&A 봇이었습니다. 
하지만 결과는? 봇은 코드를 기가 막히게 설명해 줬지만, 정작 팀원들의 손은 자주 가지 않았습니다.

가장 큰 문제는 봇이 ‘읽기 전용(Read-only)’이었다는 점입니다. 
질문을 하기 위해 상황을 구구절절 복사해 봇에게 '떠먹여 주는' 수고에도, 마지막 단추는 여전히 사용자가 브라우저를 열어 직접 끼워야 했습니다. 지식은 풍부하지만 정작 손발이 없는 에이전트는 바쁜 개발자들에게 또 다른 '일거리'일 뿐이었습니다. 대화가 실제 작업의 완결로 이어지지 않으니, 굳이 봇을 부를 이유가 사라진 것입니다.

빌드 기능을 붙이니 달라졌습니다: 검증 가능한 귀찮음 해결

실패를 겪고, 다시 ‘빌드’라는 액션에 집중하기로 했습니다. 빌드는 에이전트 도입에 적합한 도메인이었습니다.

첫째, 동작 여부를 검증하기 쉽습니다. 코드 설명은 '그럴싸함'의 영역이지만, 빌드는 성공 아니면 실패라는 기계적인 결과가 명확히 나옵니다. 

둘째, 누구나 할 수 있지만 지독하게 귀찮은 일이었기 때문입니다. 봇에게 지식을 뽐내라고 강요하는 대신, 개발자의 손발이 되어 이 '확실한 귀찮음'을 제거하는 데 집중했습니다.

결과는 성공적이었습니다. 에이전트 '코드몽(Codemon)*'을 도입한 지난 해 12월 말부터 최근까지 약 3개월간의 로그를 분석해 보니, 코드몽을 호출한 멘션은 총 254회, 이를 통해 실제 트리거된 빌드는 471건(iOS 236건, Android 235건)에 달했습니다. 슬랙에서 멘션을 한 번 날릴 때마다 평균 1.85개의 플랫폼 빌드가 실행된 셈입니다. (전체 요청의 88%가 iOS, Android 동시 빌드였습니다.)

예전 같았으면 브라우저를 열고 두 플랫폼의 대시보드를 각각 찾아가 따로 버튼을 눌러야 했을 일입니다. 에이전트가 이 과정을 한 번의 채팅으로 묶으면서, 개발자들이 낭비해야 했던 수백 번의 '5분'을 통째로 삭제했습니다.

왜 단순 커맨드 봇이 아니라 'AI 에이전트'여야 했나

단순히 빌드 트리거가 목적이라면 슬랙의 /build ios 같은 커맨드 봇으로도 충분하다고 생각할 수 있습니다. 
하지만 실제 업무 워크플로우에 녹여보니 차원이 달랐습니다.

• 명령어를 외울 필요가 없습니다: 에이전트는 스레드를 하나의 세션으로 이해합니다. 스레드에 버그 리포트를 올리고, 수정한 PR 링크를 던진 뒤 “이거 안드로이드만 테스트 앱 뽑아줘”라고 말해도, 알아서 앞선 맥락과 브랜치를 읽고 의도대로 빌드를 돌립니다.
• 실패했을 때 대처가 다릅니다: 단순 봇은 빨간 에러 로그를 뱉고 끝납니다. 하지만 에이전트는 로그를 읽고 "라이브러리 버전 충돌이네요. 수정하고 다시 돌릴까요?"라며 트러블슈팅의 실마리를 던져줍니다.

Slack을 첫 표면(Surface)으로 고른 진짜 이유: 맥락의 중심에 서기

에이전트 '코드몽'을 기획하며 집중한 것은 단순히 Slack이라는 UI가 아니라, 그곳에 흐르는 ‘맥락(Context)’이었습니다.

별도의 웹 대시보드를 만들지 않은 이유는 명확합니다. 에이전트를 쓰기 위해 브라우저의 새 탭을 여는 순간, 이미 작업의 흐름은 끊기기 때문입니다. 질문, 에러 로그, Figma 시안, PR 링크까지 모든 '일의 단서'는 이미 Slack 스레드에 쌓여 있었습니다.

또한, 모든 사내 구성원이 이미 익숙하게 사용 중인 도구라는 점도 크게 작용했습니다. 평소 대화하던 창에서 에이전트를 호출하는 것은 강력한 이점이었습니다. 여기에 Slack이 제공하는 풍부한 UI 블록(Block Kit)은 별도의 프론트엔드 개발 없이도 빌드 상태, QR 코드, 승인 버튼 등을 체계적으로 보여줄 수 있는 훌륭한 인터페이스가 되어주었습니다.

에이전트가 이 스레드 안으로 들어오자 멘션 한 번에 앞선 대화, 첨부된 로그 파일, 공유된 링크를 전부 읽고 대화를 시작하게 되었습니다. 상황을 길게 설명할 필요가 사라진 것입니다. Slack Thread가 자연스럽게 하나의 살아있는 작업 세션(Session)이 되었습니다.

질문이 아니라 "상황 전체"를 넘기고 싶어 합니다

"링크 주면 알아서 읽어옵니다"라는 마법 뒤에는, 철저하게 계산된 ‘도메인 전용 해석기(Handler) 파이프라인’이 돌아가고 있습니다. GitHub PR 링크나 Figma/Notion URL에서 키값을 파싱해 필요한 데이터만 정제해서 가져오는 식입니다.

이 파이프라인 설계가 빛을 발한 진짜 사례는 잘 정리된 문서를 줬을 때가 아니었습니다. 오히려 파편화된 정보가 널브러진 ‘난장판 스레드’를 통째로 던져줬을 때였습니다.

어느 날 빌드가 터졌고, 누군가 “@codemon 빌드 왜 터졌어?”라고 멘션했습니다. 스레드 안에는 실패한 Actions 링크, 에러 캡처 이미지, 압축된 로그 파일, 그리고 개발자들의 대화가 뒤섞여 있었습니다.

기존 챗봇이었다면 컨텍스트 윈도우에 맞게 텍스트만 복사해달라고 했겠지만, 에이전트는 질문자를 귀찮게 하는 대신 직접 링크를 타고 들어가 맥락을 파악했습니다. 에러 로그를 파싱하고 첨부 파일을 열어본 뒤, 앞선 대화까지 주워 담아 원인을 분석했습니다. 사람 입장에서는 스레드에 자료를 던져놨을 뿐인데, 에이전트가 알아서 흩어진 맥락을 조립해 디버깅으로 이어준 것입니다.

배운 것, 그리고 다음 과제

1. 에이전트 도입은 모델 성능보다 진입 비용에 걸립니다. 
   프롬프트를 고민해야 하는 에이전트는 외면받습니다. 귀찮은 일을 알아서 대신해 줘야 합니다.
2. 채팅 히스토리보다 작업 컨텍스트(Work Context)가 중요합니다. 
   이전 대화를 이어가는 것보다, 지금 발생한 상황을 즉시 던지는 경험이 핵심입니다.
3. 사내 에이전트의 핵심은 "기존 워크플로우를 얼마나 덜 끊는가"입니다. 
   Slack 스레드를 벗어나지 않게 하는 것이 성공의 열쇠였습니다.

"빌드 해줘"라는 한 마디를 실제 안전한 빌드로 연결하려면 생각보다 많은 장치가 필요했습니다. Thread를 Session으로 유지하고, 자유분방한 모델의 판단(Intent)을 통제 가능한 앱의 실제 실행(Side effect)으로 안전하게 분리해야 했고, 나아가 Prompt drift를 운영 문제로 풀어내야 했습니다.

다음 글에서는 이 에이전트를 지탱하는 실제 앱의 설계와 아키텍처에 대해 정리해 보겠습니다.