Slack에서 길을 잃다: 검색 가능≠찾을 수 있음
팀의 Slack 채널이 너무 많아 아무것도 못 찾겠다면, 검색만으로 해결되지 않는 이유와 실제로 효과 있는 방법을 알아보세요.
By Ellis Keane · 2026-03-17
지금 팀에 Slack 채널이 몇 개나 있나요? 사이드바에 표시된 숫자 말고요 (대부분 음소거했을 테니까요). 6개월 전에 끝난 프로젝트를 위해 만든 채널, 이름이 너무 비슷해서 어느 것이 맞는지 모르는 채널, 당시엔 알 방법이 없어서 다시는 찾지 못할 중요한 일이 일어났던 채널까지 포함한 실제 숫자 말입니다.
그 숫자를 모를 거라고 생각합니다. 솔직히 우리도 모릅니다. 그게 바로 핵심입니다.
Slack 채널 과부하에 대한 표준 조언은 재정리하고, 명명 규칙을 만들고, 불필요한 것은 아카이브하고, 분기별 대청소(오후 내내 생산적인 기분이 들다가 이후 6주에 걸쳐 서서히 원상복구되는 그런 의식)를 하라는 것입니다. 그 조언이 틀린 건 아닙니다. 다만 메커니즘이 아닌 증상을 치료할 뿐입니다. 팀의 Slack 채널이 너무 많고 아무것도 못 찾는 이유는 정리를 못 해서가 아니라 (물론 그럴 수도 있지만), Slack이 지식이 아닌 대화를 위해 만들어졌기 때문입니다. 그리고 그 둘 사이의 간극이 바로 중요한 컨텍스트가 모두 사라지는 곳입니다.
검색 가능하다는 것과 찾을 수 있다는 것은 다르다
대부분의 팀이 걸려 넘어지는 지점이 바로 이겁니다. Slack 검색은 자신이 잘하는 일에 있어서는 실제로 꽤 훌륭합니다. 단어를 입력하면 그 단어가 포함된 메시지를 찾아주고, 관련성 순으로 정렬하고, 채널·사람·날짜 범위로 필터링도 됩니다. 무엇을 찾는지, 언제쯤인지 알고 있다면 Slack 검색은 거기까지 데려다줍니다.
문제는 '찾을 수 있음'과 '검색 가능함'이 근본적으로 다른 능력을 나타내는데, Slack은 그중 하나만 제공한다는 점입니다.
"검색 가능하다는 것과 찾을 수 있다는 것은 근본적으로 다른 능력이며, Slack은 그중 하나만 제공합니다." – Ellis Keane
검색 가능하다는 것: 특정 키워드가 있고 그것을 포함한 모든 메시지를 보고 싶다는 뜻. 찾을 수 있다는 것: 대화가 있었다는 건 기억하지만 누가 어떤 단어를 썼는지, 어느 채널이었는지, 정확히 언제였는지 기억하지 못한다는 뜻. 실제로 Slack에서 정보를 찾으려 할 때 두 번째 경우가 약 80%를 차지합니다.
마지막으로 Slack에서 뭔가를 찾으려 했을 때를 생각해 보세요. 정확한 키워드를 입력했나요? 아니면 여러 변형을 시도하고, 채널을 스크롤하고, DM을 확인하고, 결국 "저기, 그 얘기 어디서 했는지 기억해?"라고 누군가에게 물었나요? 후자라면 (거의 틀림없이 그럴 거라고 확신하지만) Slack 검색이 고장난 게 아닙니다. 단지 여러분이 실제로 가진 문제와 다른 문제를 풀고 있을 뿐입니다.
채널이 증식하고 컨텍스트가 파편화되는 방식
우리가 관찰해온 대부분의 팀에서 실제로 일어나는 일입니다. 처음엔 무해하게 시작합니다. 팀 채널(#engineering, #design, #product), 프로젝트 채널(#project-atlas, #project-beacon), 기능 채널(#standup, #deployments, #incidents), 그리고 소셜 채널(#random, #watercooler)을 만듭니다. 15~20개 채널이고, 처음 3개월은 완벽하게 작동합니다.
그러다 경계가 흐릿해지기 시작합니다. 누군가 #incidents에서 다뤄야 할 배포 문제를 #engineering에서 얘기하기 시작합니다. 디자인 리뷰 대화가 #design, #project-atlas, 그리고 DM 스레드에 걸쳐 펼쳐집니다. 누군가 그 프로젝트의 디자인 피드백만을 위한 공간으로 #project-atlas-design을 만들고, 이제 Atlas 디자인 결정이 두 곳에 존재할 수 있게 됩니다. 전체 그림을 파악하려면 둘 다 확인해야 합니다.
채널 수가 진짜 문제는 아닙니다. 그렇게 느껴지더라도요 (모든 팀에 대해 증명할 순 없지만, 얘기를 나눠본 모든 팀에서 사실이었습니다). 문제는 각 채널이 다른 포켓과의 연결 없이 고립된 컨텍스트 포켓이 된다는 겁니다. #project-atlas의 대화가 Notion 문서를 참조하고, 그 문서가 Linear 이슈를 참조하고, 그 이슈가 #engineering에서 논의됐는데, 그 어떤 참조도 기계가 읽을 수 있는 링크가 아닙니다. "앞서 논의한 대로", "문서에 따르면", "그 스레드 후속으로"라는 인간의 축약 표현들입니다. 그 대화 모두에 참여했던 사람은 흐름을 따라갈 수 있습니다. 참여하지 않은 사람(또는 6개월 후의 참여자)은 그럴 수 없습니다.
명명 규칙이 실제로 해결하는 것(과 그렇지 않은 것)
명명 규칙을 완전히 무시하고 싶지는 않습니다. 한 가지 특정한 면에서는 실제로 도움이 되니까요. 어느 채널을 봐야 하는지 찾는 데 도움이 됩니다. team-engineering, proj-atlas, func-deploys 같은 일관된 패턴은 사이드바를 탐색하기 쉽게 만듭니다. 그건 진짜 가치입니다. 비록 그 규칙이 위키를 읽지 않은 세 번째 사람이 proj-atlas-design 대신 atlas-design-feedback을 만드는 순간부터 무너지기 시작할지라도.
하지만 명명 규칙은 찾기 어려움 문제를 해결하지 못합니다. 왜냐하면 찾을 수 있음이란 어느 채널을 검색해야 할지 아는 것이 아니기 때문입니다. 필요한 대화가 3개 채널과 DM에 분산돼 있는 것이 문제고, 어떤 명명 규칙도 그것을 알려주지 않습니다. Slack의 정보 아키텍처는 설계상 평평하고, 그 평평함은 실시간 대화에서 실제로 강점 중 하나입니다 (배포에 대해 누군가에게 빠르게 알릴 때 계층 구조는 방해가 됩니다). 하지만 정보 검색 측면에서는 재앙입니다.
"채널이 너무 많다"는 문제는 사실 "컨텍스트가 채널 안에 갇혀 있다"는 문제입니다. 채널 수를 줄이면 탐색은 개선되지만 근본적인 파편화는 해결되지 않습니다.
Slack 채널이 너무 많으면 왜 아무것도 못 찾는가
팀이 내부 API를 REST에서 GraphQL로 전환하기로 결정한 대화를 찾고 있다고 가정해 봅시다. 실제로는 이렇게 됩니다:
- Slack에서 "GraphQL"을 검색합니다. 십여 개 채널에 걸쳐 약 250개 결과가 나옵니다. 대부분은 #engineering에서, 일부는 #random에서(누군가 블로그 포스트를 공유했습니다), #project-beacon에서도 몇 개가 전환이 자신들에게 영향을 미칠지 묻는 내용입니다.
- #engineering으로 좁힙니다. 여전히 수십 개 결과가 있습니다. 결정 자체는 어디에도 없습니다. 리드 엔지니어가 "하죠"라고 했을 때, 이틀 전 메시지에 "좋아요, 그걸로 가죠"라고 답글을 달았을 뿐이니까요.
- 비교 논의를 찾으려고 "REST API"로 검색합니다. 다른 결과 집합이고, 겹치는 부분은 일부뿐입니다. 결정 스레드의 가장 중요한 메시지 일부에는 "REST"도 "GraphQL"도 없습니다. 개발자 경험과 타입 안전성에 대해 일반적인 언어로 논의했기 때문입니다.
- 포기하고 #engineering에 올립니다: "GraphQL로 전환하기로 언제 결정했는지 기억하는 분 있나요?" 누군가 Linear 이슈 링크를 답글로 보냅니다. 그 Linear 이슈가 Notion RFC에 링크됩니다. 그 Notion RFC가 Slack 스레드를 참조합니다 (채널이 아카이브됐기 때문에 링크가 죽어 있습니다). 그리고 실제 결정의 순간은 서면 기록이 없는 허들에서 있었습니다.
이건 검색 문제가 아닙니다. 지식 그래프 문제입니다. 그리고 이것이 Slack 검색이 아무리 좋아져도 채널이 너무 많은 팀이 아무것도 찾지 못하는 진짜 이유입니다.
실제로 효과 있는 것
자체 팀에서 이 패턴을 직접 경험하고 (다른 엔지니어링 매니저들에게서 놀랍도록 비슷한 이야기를 들으면서), 진짜 도움이 되는 몇 가지를 알게 됐습니다.
Slack은 아카이브가 아닌 받은 편지함이라는 것을 받아들이세요. 가장 유용한 사고방식 전환입니다. Slack은 대화가 실시간으로 일어나는 곳이지, 결정이 저장되는 곳이 아닙니다. Slack에서 중요한 것이 결정됐다면, 어딘가 지속적인 곳에 기록해야 합니다. Linear 이슈, Notion 문서, ADR, 심지어 커밋 메시지도 괜찮습니다. Slack은 대화이고, 그 다른 도구들이 기록입니다.
스레드를 철저히 사용하세요. 스레드는 찾기 편의성을 위한 Slack 최고의 기능입니다. 완전한 대화를 하나의 주소 지정 가능한 단위로 묶어두기 때문입니다. 스레드에는 퍼머링크가 있습니다. 채널의 메인 타임라인에 흩어진 대화에는 없습니다. 팀 문화가 메인 채널에 답글을 다는 쪽으로 기본 설정돼 있다면 (많은 팀이 그렇습니다. 더 즉각적으로 느껴지니까요), 정보 검색을 극적으로 어렵게 만들고 있는 겁니다.
프로젝트 채널이 아닌 결정 채널을 만드세요. 직관에 반하지만, 들어보세요. #project-atlas 대신(혹은 추가로) #decisions나 #decisions-engineering을 시도해 보세요. 결정을 간략한 컨텍스트와 함께 기록하는 것만을 목적으로 하는 단일 채널. 전체 논의는 포함하지 않지만 (그건 자연스럽게 일어난 곳에 있으면 됩니다), 무엇이 결정됐는지와 논의가 어디서 일어났는지에 대한 링크의 검색 가능한 시간 순서 로그가 됩니다. 팀의 사고에 대한 커밋 로그라고 생각하세요. 실제로 작동하는 강제 메커니즘(우리 경험상): PR 템플릿에 포함하기. 머지 전에 관련 결정 포스트를 링크하게 합니다. 가볍고, 리뷰에서 확인 가능하며, 누군가의 기억이나 규율에 의존하지 않는 흔적을 만듭니다.
자동으로 점들을 연결하세요. 직접 관련이 있기 때문에 우리가 만들고 있는 것을 언급하겠습니다. Sugarbug는 Slack 메시지를 Linear 이슈, GitHub PR, Notion 문서, Figma 댓글과 함께 수집해 서로 어떻게 관련되는지에 대한 지식 그래프를 구축합니다. 그 연결이 존재하면 대화가 어느 채널에서 일어났는지 기억할 필요가 없습니다. 작업이나 문서에서 시작해 어디에 있었든 모든 관련 대화로 흐름을 따라갈 수 있으니까요. 이것을 어떻게 표면화할지는 아직 파악 중입니다 (솔직히 크로스 툴 검색의 UX가 수집보다 훨씬 어렵습니다). 하지만 핵심 접근법 – 컨텍스트를 재정리하는 게 아니라 연결하는 것 – 이 실제로 변화를 만들어낸다고 우리는 생각합니다.
다섯 채널을 검색하다 아무것도 못 찾는 일을 멈추세요. Sugarbug는 Slack을 나머지 도구들과 연결해 결정 사항을 계속 찾을 수 있게 유지합니다.
Q: Slack 채널이 몇 개부터 너무 많은 건가요? A: 정해진 숫자는 없지만, 팀이 대화가 어디서 일어났는지 자주 찾지 못하거나 채널이 너무 복잡해서 DM으로 도망치는 사람이 늘었다면 이미 한계를 넘은 겁니다. 10~20명 규모의 팀이 80~100개 이상의 활성 채널을 보유하면 이 벽에 부딪히는 경우가 많지만, 팀이 채널 목적과 아카이빙에 대해 얼마나 규율을 지키느냐에 따라 크게 달라집니다.
Q: Sugarbug가 Slack 채널 과부하 관리에 도움이 되나요? A: Sugarbug는 채널을 직접 관리하지 않지만, 채널 과부하가 만들어내는 찾기 어려움 문제를 해결합니다. Slack 메시지를 Linear 이슈, GitHub PR, Notion 문서, Figma 댓글과 함께 지식 그래프에 수집해, 어떤 채널(또는 어떤 도구)에서 일어났든 한 번의 검색으로 결정 사항이나 대화를 찾을 수 있습니다.
Q: 검색해도 Slack에서 아무것도 못 찾는 이유가 뭔가요? A: Slack 검색은 입력한 키워드가 포함된 메시지를 찾아주지만, 직장의 의사결정은 단계마다 다른 단어를 씁니다. 누군가 한 스레드에서 "Redis 옵션"이라고 하고 다른 스레드에서 "BullMQ"라고 해도 같은 결정을 이야기하는 것인데, 두 스레드는 서로를 참조하지 않습니다. 검색은 텍스트 일치를 찾습니다. 결정의 흔적을 찾으려면 대화 간의 연결을 이해해야 하는데, 그건 근본적으로 다른 능력입니다.
Q: Sugarbug가 Slack 채널을 더 나은 것으로 대체할 수 있나요? A: 아니요, 그럴 필요도 없습니다. Slack은 실시간 대화에 탁월하며, 그것은 진정한 가치입니다. 문제는 Slack 자체가 아니라 중요한 컨텍스트가 대화 안에 갇혀서 관련 작업·문서·코드와 연결할 방법이 없다는 점입니다. Sugarbug가 그 연결을 자동으로 구축해서, 어디서 논의됐는지 기억할 필요가 없습니다.