대부분의 코드 작업은 여전히 단체 채팅방의 한 문장에서 시작됩니다. "CSV 내보내기에서 마지막 행이 빠져요." "데모 전에 SSO 좀 추가해줄 수 있나요?" "프로덕션 체크아웃에서 또 500 떠요." 누군가 엄지척을 누르고, 코딩 에이전트가 그걸 향할 수도 있습니다. 그리고 사흘 뒤에는 아무도 그게 실제로 배포됐는지, 누가 리뷰했는지, 어느 커밋이 고쳤는지 말할 수 없습니다. 메시지는 스크롤과 함께 사라집니다. 작업은 구전(口傳)이 됩니다.
이 간극은 규율의 문제가 아니라 구조의 문제입니다. 채팅 메시지에는 소유자도, 상태도, 인수 테스트도, 그리고 그것을 해결한 diff로 이어지는 링크도 없습니다. 그 메시지에 코딩 에이전트를 붙이면 추적 불가능한 작업이 만들어집니다. 에이전트를 하나 이상 돌리기 시작하면 더 나빠집니다. 이제는 어느 에이전트가 손댔는지조차 말할 수 없기 때문입니다.
이 글에서는 채팅 메시지를 추적 가능한 코드 작업으로 바꾸는 과정을 짚어봅니다. 직접 만든 순수 DIY 구성으로 무엇을 얻을 수 있는지, 어디서부터 확장이 멈추는지, 그리고 공유 작업 계층을 더하면 무엇이 달라지는지를 다룹니다. Sharkly는 추적 가능한 버전을 위한 워크스페이스입니다. 코딩 에이전트 위에 자리하면서 목표, 실행, 블로커, diff, 사람의 리뷰를 하나의 기록 안에 유지하기 때문입니다. 여러분에게는 이미 코딩 에이전트가 있습니다. 과제는 그들의 작업을 팀이 따라갈 수 있는 무언가로 바꾸는 것입니다.
채팅이 코드 작업이 죽어가는 곳인 이유
단체 채팅은 대화의 속도에 최적화되어 있는데, 이는 코드 작업이 필요로 하는 것과 정반대입니다. 진짜 작업에는 명시된 목표, 소유자, 인수 기준, 조회 가능한 상태, 그리고 그것을 종결시킨 변경으로 되돌아가는 링크가 따라붙습니다. 채팅 메시지에는 그중 아무것도 없습니다. 타임스탬프와 리액션만 있을 뿐입니다.
실패 양상은 구체적입니다. 요청이 들어오고, 스레드 안에서 비공식적으로 합의되고, 스레드는 계속 굴러갑니다. 이틀 뒤 누군가 "그 export 버그 우리 고쳤던가?"라고 묻고, 답을 얻으려면 Slack 검색과 추측, 그리고 같은 문구가 아홉 번 등장하는 채널을 끝까지 스크롤하는 일이 필요합니다. 메시지를 찾아냈다 해도, 그 수정이 머지됐는지는 알려주지 않습니다. 대화와 코드는 서로의 이름을 배운 적 없는 별개의 시스템에 살고 있습니다.
그 메시지에 자율 코딩 에이전트를 붙이면 추적은 더 짧아집니다. 에이전트는 Slack 한 줄을 읽고, 누군가의 노트북 터미널에서 실행되고, 파일을 편집하고, 요청을 삼켜버린 그 빠르게 흐르는 스레드로 다시 보고합니다. 이제는 아무도 저장하지 않은 실행 로그, 아무도 연결하지 않은 변경, 아무도 기록하지 않은 결정이 남습니다.
DIY 파이프라인, 그리고 확장이 멈추는 지점
시작하는 데 제품이 필요하지는 않습니다. 쓸 만한 DIY 파이프라인은 이렇습니다. 채팅 메시지를 복사해 코딩 에이전트에 프롬프트로 붙여넣고, 메인 체크아웃과 충돌하지 않도록 격리된 Git 워크트리에서 작업하게 하고, Closes #123 줄로 추적 이슈로 되돌아가는 링크가 달린 풀 리퀘스트를 엽니다. 이것은 진짜 추적성이고, 한 번에 하나의 요청을 처리하는 1인 개발자에게는 대개 충분합니다.
여기 솔직한 의사결정 쌍이 있습니다. 혼자이고, 에이전트 하나를 돌리고, 다음 작업 전에 하나의 작업을 끝낸다면, 워크트리로 복사-붙여넣기하는 루프는 잘 작동하며 여기에 도구를 추가할 필요가 없습니다. 공유 시스템의 오버헤드가 그 수익보다 더 큰 비용이 될 테니까요.
이 구성은 두 가지가 동시에 참이 되는 순간 확장을 멈춥니다. 에이전트 둘이 돌거나, 사람 둘이 작업을 배분하거나, 저장소 둘이 얽혀 있을 때입니다. 그때 수동 파이프라인에 구멍이 생깁니다.
| 무엇이 깨지는가 | DIY 루프가 감당할 수 없는 이유 |
|---|---|
| "export 버그는 어느 에이전트가 맡고 있지?" | 배정이 머릿속에만 있었지, 기록에 없었다 |
| "이거 끝난 거야, 아직 돌고 있는 거야?" | 상태는 닫아버린 터미널일 뿐, 조회 가능한 필드가 아니다 |
| "인증 변경은 누가 승인했어?" | 승인은 엄지척이었고, 이제는 스크롤과 함께 사라졌다 |
| "그 Slack 요청의 diff는 어디 있어?" | PR은 이슈로 연결되지만, 그 이슈는 요청으로 연결되지 않는다 |
| "에이전트가 실제로 뭘 바꿨지?" | 실행 로그는 끝나버린 세션에 있었다 |
각 구멍은 작업이 다시 추적 불가능해지는 지점입니다. 이슈를 더 만들고, 명명 규칙을 정하고, 규율을 세워 손으로 메울 수는 있습니다. 안 될 때까지는 작동하고, 그리고 조용히 실패합니다. 프로세스가 실패하는 방식 중 최악이죠.
작업이 공유된 뒤 "추적 가능"의 의미
추적 가능은 느낌이 아닙니다. 어떤 작업에 관한 모든 질문에는 한 곳에 존재하며, 그것이 시작될 당시 접속해 있던 사람들이 떠나도 살아남는 답이 있습니다. 추적 가능한 작업은 요청부터 릴리스까지 컨텍스트, 배정, 진행 상황, 블로커, 결과, 사람의 리뷰를 계속 보이게 유지합니다.
Sharkly는 이를 시스템의 주요 작업 단위인 Task로 모델링합니다. Task는 채팅 메시지도, 터미널 세션도 아닙니다. 채팅 메시지에 대해 행동하기로 결정한 순간 그것이 변하는 공유 기록입니다. 목표는 설명에 들어갑니다. Agent 또는 사람이 Assignee가 됩니다. Agent의 실행, 블로커, 결과, 그리고 후속 논의는 모두 사설 터미널로 사라지는 대신 Task 타임라인으로 돌아옵니다. 변경이 반영되면 풀 리퀘스트가 ID로 연결되어, 요청과 diff가 마침내 서로의 이름을 알게 됩니다.
경계 하나가 중요합니다. 독자가 잘못 가정할 수 있기 때문입니다. Sharkly는 Claude Code, Codex, 또는 여러분의 다른 코딩 에이전트를 대체하는 것이 아닙니다. 그 도구들이 실행을 수행합니다. Sharkly는 그 주위에 공유 작업, 컨텍스트, 리뷰 계층을 더합니다. 코드는 여전히 Agent가 씁니다. Sharkly는 그 작업을 배정 가능하고 추적 가능하게 만듭니다.
Sharkly로 채팅 메시지를 추적 가능한 작업으로 바꾸기
워크플로우는 머릿속에 담아둘 만큼 짧습니다. CSV export 버그 같은 실제 메시지 하나로 시작해, 그것을 채널 밖으로 꺼내세요.
- 메시지를 Task로 포착합니다. 요청을 목표로 하는 Task를 만듭니다. 채팅이 Slack에 있다면, 코딩 에이전트용 Slack 봇이 스레드를 벗어나지 않고도 멘션을 Task로 바꿔줍니다.
- Agent가 실행할 수 있도록 형태를 잡습니다. 한 줄짜리 버그 리포트는 실행 가능한 스펙이 아닙니다. 재현 방법, 기대 동작, 인수 테스트를 추가하세요. AI 에이전트 작업 관리와 같은 규율입니다. Agent가 종결지을 수 있는 Task에는 Agent가 행동할 수 있는 설명이 필요합니다.
- 배정하고 Agent를 실행시킵니다. Agent가 Task를 맡고, 병렬 작업이 충돌하지 않도록 격리된 워크트리에서 작업하며, 진행 상황을 Task로 실시간 전송합니다. 여러분은 터미널이 아니라 기록을 보고 있습니다.
- 리뷰하고 수락합니다. Agent는 변경 요약, 테스트 결과, 알려진 한계를 첨부합니다. 사람이 수락하거나, 변경을 요청하거나, 머지 결정을 내립니다.
마지막 단계가 바로 분명히 짚고 넘어갈 만한 계약입니다. Agent는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 수락합니다. 자동화는 팀의 판단이 필요한 지점에서 멈춥니다. 추적 가능한 작업이 그 인계를 가능하게 합니다. 변경을 리뷰하는 사람이 요청에서 diff까지의 전체 경로를 보기 때문입니다. 작업이 끝나면 기억으로 재구성할 필요 없이 에이전트가 완료한 작업을 추적할 수 있습니다. 이는 형식적인 티켓 대신 채팅 조각에서 시작한다는 점만 다를 뿐, 전체 요구사항에서 코드까지의 워크플로우와 같은 척추입니다.
이것의 한 버전을 이슈와 워크트리로 직접 만들 수도 있고, Sharkly로 워크플로우를 관리해 물량이 늘어나도 추적이 유지되게 할 수도 있습니다.
오늘 바로 돌려볼 수 있는 체크리스트
현재 구성에 대해 이걸 한번 돌려보세요. 체크되지 않은 각 항목은 채팅에서 태어난 작업이 추적 불가능해질 수 있는 지점입니다.
- [ ] 실행에 옮긴 모든 채팅 요청이 리액션 이모지가 아니라 소유자가 있는 Task가 된다.
- [ ] 각 Task에는 Agent가 실행할 수 있는 설명이 있다. 재현, 기대 동작, 인수 테스트.
- [ ] 실행 중인 각 Agent는 격리된 워크트리에서 작업해, 두 작업이 같은 파일을 절대 건드리지 않는다.
- [ ] Agent의 실행 로그, 블로커, 결과는 닫히는 터미널이 아니라 Task로 돌아온다.
- [ ] 풀 리퀘스트가 ID로 Task에 연결되어, 요청과 diff가 한 번의 클릭 거리에 있다.
- [ ] 사람이 결과를 수락하거나 거부하고, 그 결정이 Task에 기록된다.
- [ ] "이거 끝났어, 누가 했어, diff는 어디 있어?"를 채팅을 검색하지 않고 답할 수 있다.
한 번에 하나의 요청을 처리한다면 수동 루프만으로도 이 항목 대부분을 통과합니다. 팀 전반에 걸쳐 여러 에이전트를 돌린다면, Sharkly는 그들의 작업과 결과를 관리할 한 곳을 제공합니다. Sharkly 다운로드하고, 채널 전체를 맡기기 전에 실제 채팅 요청 하나를 Task로 옮겨보세요.
FAQ
채팅에서 태어난 작업을 추적 가능하게 만들려면 Sharkly가 필요한가요? 아닙니다. 에이전트 하나를 돌리는 1인 개발자는 워크트리와 이슈로 연결되는 풀 리퀘스트만으로 진짜 추적성을 얻습니다. AI 에이전트 인박스 패턴은 에이전트나 사람이 여러 명이 되어 수동 링크가 슬슬 빠지기 시작할 때 제값을 합니다.
채팅 메시지가 코딩 에이전트에게 실행하기 어려운 이유는 무엇인가요? 보통 재현, 기대 결과, 인수 테스트가 빠져 있기 때문입니다. "export가 깨졌어"를 "CSV export에서 마지막 행이 빠짐, 기대 N행, 실제 N-1행, 카운트가 맞을 때 수정됨"으로 바꾸세요. 그러면 Agent가 종결지을 대상이 생깁니다.
일반적인 티켓팅 시스템과는 어떻게 다른가요? 티켓은 사람이 할 일을 추적합니다. 추적 가능한 코드 작업은 여기에 더해 Agent의 실행 로그, 격리된 실행, 연결된 diff까지 담기 때문에, 기록이 결정과 변경을 모두 아우릅니다. 사람이 어디서 루프에 남는지는 휴먼 인 더 루프 코딩 에이전트를 참고하세요.
Sharkly가 제 Slack 채널을 직접 읽을 수 있나요? Sharkly Agent를 Slack에 연결하면 멘션이 Task가 됩니다. 대화는 Slack에 남고, 추적 가능한 작업 기록은 Sharkly에 존재합니다.
