🚨 우리가 해결하고 싶었던 문제점들

업무 프로세스를 개선하기 전, 저희 팀은 몇 가지 고질적인 문제들로 인해 불필요한 시간과 에너지를 소모하고 있었습니다.

1. 모든 대화가 뒤섞여 히스토리 파악이 불가능했습니다.

• 원인: 모든 소통을 Discord의 단일 채널에서, 쓰레드(Thread) 구분 없이 진행했습니다.

• 문제점:
  a. 특정 기능이나 작업에 대한 논의를 다시 찾아보려면 끝없이 스크롤을 올려야 했습니다.
  b. 과거에 어떤 논의를 통해 현재의 결론에 도달했는지 그 맥락을 파악하기가 거의 불가능했습니다.

2. 정보가 여러 곳에 흩어져 있어 '단일 진실 공급원(SSOT)'이 없었습니다.

• 원인: 논의는 Discord, 이슈 기록은 Notion, 프로젝트 일정(WBS)은 Google Sheets 등 정보가 제각각의 툴에 흩어져 있었습니다.

• 문제점:
  a. 하나의 작업을 이해하기 위해 여러 툴을 넘나들며 정보를 조각모음 해야 했습니다.
  b. 이 작업의 최종 결정 사항이 뭐였죠?"와 같이 상태를 파악하기 위한 불필요한 질문과 커뮤니케이션 비용이 계속해서 발생했습니다.

3. 팀원들 간에 지금 무슨 일을 하는지 업무 공유가 제대로 되지 않았습니다.

• 원인: 각자 어떤 작업을 진행하고 있는지 파악할 수 있는 중앙화된 공간이 없었고, 구두로 공유하거나 아예 공유되지 않는 경우가 많았습니다.

• 문제점:
  a. 누가 어떤 일에 집중하고 있고, 어떤 부분에서 어려움을 겪는지 알기 어려워 적시에 도움을 주거나 받기 힘들었습니다.
  b. 업무가 중복되거나 누락되는 경우가 발생하여 전체적인 프로젝트 진행 상황 파악이 어려웠습니다.

---

💡 그래서, 우리는 이렇게 해결했습니다.

앞서 정의한 고질적인 문제들을 해결하기 위해, 저희는 단순히 새로운 툴을 도입하는 것을 넘어 '소통의 규칙'을 세우고, '반복적인 과정을 자동화'하며, '정보를 한곳으로 모으는' 세 가지 핵심 전략을 실행에 옮겼습니다.

📌 Step 1 - 소통의 질서를 잡다: '모든 논의는 쓰레드에서'

가장 먼저 도입한 규칙은 간단하지만 강력했습니다. 바로 '모든 작업 관련 논의는 반드시 Discord 쓰레드(Thread)를 만들어 시작한다'는 것이었습니다.

이 간단한 규칙 하나가 뒤죽박죽 섞여 있던 대화의 물꼬를 터주었습니다. 더 이상 특정 주제를 찾기 위해 무한 스크롤을 할 필요가 없어졌고, 각 논의의 맥락이 명확하게 보존되기 시작했습니다. 이제 누구든 특정 기능이나 버그에 대한 쓰레드만 찾아 들어가면, 그 논의의 시작부터 끝까지 모든 흐름을 쉽게 파악할 수 있게 되었습니다.
그리고 대화가 주제별로 분리되어 더 이상 히스토리 파악을 위해 시간을 낭비하지 않게 되었습니다.

📌 Step 2 - 논의를 행동으로: 'Discord 이슈 생성 봇' 개발

쓰레드로 소통이 정리되었지만, Discord에서 나눈 대화가 실제 '일감'으로 이어지기까지의 과정은 여전히 번거로웠습니다. 이 허들을 넘기 위해, 저희는 Discord 이슈 생성 봇을 직접 개발했습니다.

이제 팀원들은 Discord 채널에서 간단한 명령어(!이슈생성)만으로 Linear에는 새로운 이슈를, Notion 데이터베이스에는 기록을 동시에 생성할 수 있게 되었습니다. 논의의 흐름이 끊기지 않고 자연스럽게 공식적인 작업으로 등록되는 파이프라인이 만들어진 것입니다.

📌 Step 3 - 모든 역사를 한 곳에: 'Linear를 단일 진실 공급원(SSOT)으로'

마지막으로, 저희는 흩어져 있던 모든 정보를 한곳으로 모으고 작업의 공식적인 역사를 기록할 최종 목적지를 정했습니다. 바로 Linear입니다. 저희는 다음과 같은 중요한 규칙을 세웠습니다.

"모든 중요한 논의 과정과 최종 결정 사항은 반드시 해당 Linear 이슈의 코멘트로 요약하여 남긴다."

단순히 '완료'라고 적는 것이 아니라, 왜 이 방향으로 결정되었는지, 어떤 기술적 논의를 거쳤는지, 디자인이 왜 변경되었는지와 같은 핵심적인 히스토리를 상세히 기록했습니다. Discord 쓰레드에서는 자유롭게 의견을 나누되, 그 결과는 반드시 Linear에 응축하여 남기는 것입니다.

이 규칙을 통해 Linear는 명실상부한 우리 팀의 '단일 진실 공급원(Single Source of Truth)'이 되었습니다.

잠깐, Linear가 무엇인가요?

혹시 리니어(Linear)가 생소한 분들을 위해 간단히 짚고 넘어가겠습니다. 리니어는 특히 소프트웨어 개발팀을 위해 설계된, 현대적인 이슈 트래커 및 프로젝트 관리 도구입니다.

기존의 무겁고 복잡한 도구들과 달리, 매우 빠르고 직관적인 사용자 경험(UX)에 초점을 맞추어 개발자가 불필요한 과정 없이 오롯이 작업 자체에만 집중할 수 있도록 돕습니다. 저희 팀은 바로 이 Linear를 모든 작업의 진행 상황을 공유하고, 논의의 역사를 기록하는 '중앙 허브'로 사용하기로 결정했습니다.

🔗 Linear 공식 홈페이지: https://linear.app

---

✨ 우리팀 프로세스 한 번에 보기

1단계: 모든 것의 시작, Discord

쓰레드 생성: 특정 주제에 대한 논의를 위해 Discord 채널에 쓰레드(Thread)를 생성합니다.

이슈 생성: 논의 결과, 공식적인 작업으로 등록할 필요가 생기면 해당 쓰레드에 간단한 명령어(!이슈생성 [이슈 내용]-[담당자])를 입력합니다.

2단계: 이슈 생성 봇의 활약 (자동화)

Linear 이슈 자동 생성: Discord 봇이 명령어를 감지하고, 입력된 내용으로 Linear에 새로운 이슈를 즉시 생성합니다.

Notion DB 자동 추가: 동시에, 해당 이슈 내용을 Notion 데이터베이스에도 새로운 항목으로 자동 추가합니다.

3단계: 프로젝트 관리까지 한번에 (자동화)

Google Apps Script 실행: Notion 데이터베이스에 새로운 항목이 추가된 것을 트리거(Trigger)로, 미리 작성해 둔 Google Apps Script가 자동으로 실행됩니다.

Google Sheets WBS 자동 생성: 실행된 스크립트는 Notion에 추가된 정보를 바탕으로 Google Sheets의 WBS(작업분류체계)에 새로운 행을 추가하고 내용을 자동으로 채워 넣습니다.

4단계: 히스토리 기록의 중심, Linear

논의 및 결정사항 기록: 생성된 Linear 이슈 카드 내에서, 관련된 모든 논의 과정과 최종 결정 사항을 코멘트로 상세하게 기록합니다. 이로써 Linear는 모든 작업의 공식적인 '단일 진실 공급원(Single Source of Truth)'이 됩니다.

이처럼, Discord에서 시작된 간단한 명령어 하나가 Linear, Notion, Google Sheets까지 연쇄적으로 업데이트하여, 팀원들은 반복적인 기록 작업에서 해방되고 오직 중요한 업무에만 집중할 수 있게 되었습니다.

---

🚀 배운점

지금까지 저희 팀이 어떻게 업무 프로세스를 개선했는지 그 과정과 결과를 쭉 공유해 드렸습니다. 하지만 이 글을 마무리하며 정말로 강조하고 싶은 것은, 멋진 자동화 시스템을 구축하는 기술 그 자체가 아니었습니다. 정작 가장 중요했던 것은 기술 외적인 부분에 있었습니다.

1. '무엇을' 만들지보다 '왜' 만드는지가 훨씬 중요합니다.

처음 이 문제를 해결해야겠다고 마음먹었을 때, 저는 곧바로 '어떤 봇을 만들까?', '어떤 기술을 쓸까?'를 고민했습니다. 하지만 잠시 멈춰 생각해보니 그건 순서가 아니었습니다. 가장 먼저 했어야 하는 일은 팀원 모두가 '우리의 이 문제가 정말 해결이 필요한 심각한 문제'라고 공감대를 형성하는 것이었습니다.

"다들 특정 대화 찾느라 시간 낭비한 적 많으시죠?", "지난번에 나왔던 그 아이디어, 기록이 안 돼서 놓친 거 너무 아깝지 않나요?" 와 같이 문제점을 함께 공유하고 나서야, 비로소 제가 만들 솔루션이 '개인의 욕심'이 아닌 '팀을 위한 도구'가 될 수 있었습니다. 기술은 목적이 아니라, 공유된 문제를 해결하기 위한 수단일 뿐이라는 것을 깊게 깨달았습니다.

2. 설명이 아닌 '설득'의 핵심은 '그들의 언어'로 말하는 것입니다.

단순히 "이 시스템을 도입하면 업무 효율이 올라갑니다"라고 말하는 것은 아무런 힘이 없습니다. 팀원들의 마음을 움직인 것은 '그래서 이걸 쓰면 내 소중한 주말 시간이 어떻게 절약되는데?' 라는 질문에 대한 명확한 답변이었습니다.

• '리니어 작성하고, 노션 작성하고, 구글 시트 작성하고... 어휴, 작업 시작하기도 전에 되게 뭔가를 많이 해야 하네.' 이런 생각 이제 안 하셔도 돼요. 그냥 디스코드에서 명령어 한 번이면 이 모든 게 한 번에 끝납니다."

• "'어? 그때 이 내용 논의했던 것 같은데 뭐였지? 분명 대화 기록이 있을 텐데...' 하면서 한참 동안 디스코드 채널 스크롤 올리며 과거를 헤맬 필요 없어요. 이제 관련 리니어 티켓 하나만 열어보면 모든 논의의 역사가 정리되어 있을 거예요."

이처럼 팀원 각자의 입장에서 겪는 불편함(Pain Point)을 정확히 짚어주고, 그것이 어떻게 해결될 수 있는지 구체적인 '이점(Benefit)'을 보여주었을 때 비로소 모두가 기꺼이 새로운 변화에 동참하기 시작했습니다.

3. 가장 강력한 무기는 '함께 만들어간다'는 동료 의식입니다.

제가 만약 모든 것을 혼자 완벽하게 만들어 "자, 이제부터 이렇게 쓰세요!"라고 일방적으로 발표했다면 분명 큰 저항에 부딪혔을 겁니다.

대신 저는 초기 아이디어 단계부터 동료들에게 의견을 구했습니다. "명령어는 어떤 게 편할 것 같으세요?", "리니어 티켓에 어떤 정보가 자동으로 들어가면 가장 유용할까요?" 와 같이 계속해서 질문하며 그들을 과정에 참여시켰습니다. 덕분에 이 개선 프로젝트는 저 혼자만의 것이 아닌 '우리 팀 모두의 프로젝트'가 될 수 있었습니다.

결론적으로, 성공적인 프로세스 개선은 훌륭한 자동화 도구를 만드는 기술적인 능력을 넘어, 팀원들과 함께 문제를 공감하고, 더 나은 방향을 제시하며, 모두가 기꺼이 참여하도록 이끄는 '설득과 소통의 기술'에 달려있다는 것을 배울 수 있었던 값진 경험이었습니다.