프로젝트 관리, 엑셀만으로도 충분합니다. 이 다섯 가지가 생기기 전까지는

프로젝트 관리툴을 도입하기 전, 우리 팀이 정말 관리해야 하는 것이 무엇인지 판단하는 기준

“저희는 아직 8명인데, Jira 같은 프로젝트 관리툴까지 필요할까요?”

작은 팀을 만나면 자주 듣는 질문입니다.

솔직히 말하면 많은 팀에는 아직 필요하지 않습니다.

동시에 진행하는 프로젝트가 많지 않고, 담당자가 자주 바뀌지 않으며, 구성원들이 업무의 배경을 자연스럽게 공유하고 있다면 엑셀이나 스프레드시트가 더 빠르고 편합니다.

별도의 사용법을 배울 필요가 없습니다. 열을 추가하고 필터를 걸고 필요한 사람에게 공유하면 바로 씁니다.

작은 팀이 무거운 프로젝트 관리툴을 먼저 도입하면 일을 관리하기 위해 새로운 관리 업무가 생길 수도 있습니다.

실제로 저희가 2026년 7월부터 8월까지 10~50명 규모의 개발사·SI·외주 조직 9곳을 인터뷰했을 때, 6곳은 범용 프로젝트 관리툴을 운영의 중심에 두지 않고 있었습니다. 두 곳은 스프레드시트나 Notion·AI를 필요한 만큼 조합해 사용했습니다.

범용 도구를 피한 이유도 기능이나 가격만이 아니었습니다. 새로운 사용법을 교육하고, 프로젝트마다 초기 구조를 만들고, Slack·Notion·GitHub와 같은 내용을 중복 기록하며, 회사의 업무를 도구가 정한 방식에 맞추는 부담이 더 컸기 때문입니다.

물어야 할 질문은 이것입니다.

“엑셀보다 좋은 도구가 무엇인가?”가 아니라
“지금 우리 팀이 관리해야 하는 대상은 무엇인가?”

이 글에서 ‘엑셀’은 Google Sheets를 포함한 스프레드시트 방식 전체를 의미합니다.

엑셀이 오히려 더 좋은 팀도 있습니다

다음 조건에 해당한다면 굳이 새로운 프로젝트 관리툴을 도입할 필요가 없습니다.

• 동시에 진행하는 프로젝트가 한두 개입니다.
• 진행하는 프로젝트가 복잡하지 않습니다.
• 이전에 진행했던 프로젝트의 반복입니다.
• 담당자가 거의 바뀌지 않습니다.
• 구성원들이 업무의 배경과 우선순위를 함께 알고 있습니다.
• 변경 사항을 바로 공유, 추적 가능합니다.
• 누가 무엇을 언제까지 하는지만 확인하면 충분합니다.
• 대표나 PM이 표를 관리하는 데 큰 부담이 없습니다.

이런 팀에서 엑셀은 훌륭한 도구입니다.

자유롭게 구조를 바꿀 수 있고 별도의 도입 과정도 거의 필요하지 않습니다. 새로운 열이 필요하면 추가하면 되고 프로젝트가 달라지면 표를 복사해 수정하면 됩니다.

문제는 인원이 정확히 몇 명인지, 행이 몇 개 쌓였는지가 아닙니다.

엑셀로 충분한지를 판단하는 기준은
셀 밖에서 사라지는 맥락의 양입니다.

표에 필요한 정보가 모두 있는 것처럼 보일 때

예를 들어 프로젝트 표에 이런 행이 있다고 가정해보겠습니다.

업무: 엑셀 다운로드 기능 

담당자: 김개발 

상태: 진행 중 

마감일: 9월 10일 
 

누가 무엇을 언제까지 하는지는 분명합니다.

이 행만으로는 답하기 어려운 질문이 남습니다.

• 어떤 고객의 문제에서 시작됐습니까?
• 고객은 왜 엑셀 다운로드가 필요하다고 했습니까?
• 왜 다른 기능보다 먼저 만들어야 합니까?
• 범용 다운로드 기능입니까, 특정 보고서 기능입니까?
• 무엇이 달라지면 이 업무가 완료됐다고 판단합니까?

표는 제 역할을 합니다.

관리해야 할 대상이 단순한 작업을 넘어섰는데, 여전히 작업만 기록하고 있는 것이 문제입니다.

다음 다섯 가지 현상이 반복되기 시작했다면 엑셀만으로 운영하기 어려운 단계에 들어섰을 수 있습니다.

1. 같은 행을 보고도 업무의 의미를 다르게 이해합니다

• 영업 담당자는 엑셀 다운로드를 고객이 원하는 모든 데이터를 내려받는 기능이라고 이해합니다.
• 기획자는 정해진 보고서 양식을 다운로드하는 기능이라고 생각합니다.
• 개발자는 현재 화면에 보이는 데이터를 CSV로 변환하면 된다고 판단합니다.

모두 같은 행을 보고 있지만 서로 다른 결과를 상상합니다.

태스크 이름과 담당자, 마감일은 전달됐지만 이 일이 해결하려는 문제가 전달되지 않았기 때문입니다.

실제로 고객이 겪는 문제는 엑셀 파일이 없다는 것이 아닐 수 있습니다.

진짜 문제는 따로 있습니다. 매주 이사회 보고서를 만들기 위해 데이터를 다시 정리하는 데 세 시간이 걸리고 복사·붙여넣기 과정에서 숫자 오류가 발생합니다.

이 내용이 여러 사람을 거치면 이렇게 짧아집니다.

고객의 문제 
보고서를 만드는 데 매주 3시간이 걸리고 오류가 발생함 


↓ 


영업팀의 전달 
엑셀 다운로드가 필요함 


↓ 
기획 문서 
데이터 내보내기 기능 추가 


↓ 


개발 태스크 
Export API 구현 
 

태스크는 남았지만 문제는 가려집니다.

2. 결정의 결과는 남지만 이유는 남지 않습니다

엑셀의 결정 사항 열에는 이렇게 적습니다.

B안으로 진행 
 

이 한 문장만으로는 왜 A안을 선택하지 않았고 누가 B안을 최종 결정했는지 알 수 없습니다.

• 일정 때문에 임시로 선택한 것입니까?
• 고객의 요청 때문입니까?
• 어떤 조건이 생기면 다시 검토해야 합니까?

결정의 결과는 셀에 남지만 판단 과정은 회의와 Slack, 담당자의 기억에 나뉘어 남습니다.

당장이 아니라, 시간이 지나면서 팀에서는 다시 같은 질문이 시작됩니다.

“이거 왜 B안으로 했었죠?”

“그때 확정된 것이 맞나요?”

“일정만 괜찮으면 A안으로 다시 가도 되나요?”

정보는 충분하지만, 현재 유효한 결정과 그 이유가 연결되어 있지 않은 것이 문제입니다.

3. 담당자가 바뀌면 표를 보고도 다시 물어봐야 합니다

새 담당자에게 스프레드시트와 문서를 모두 전달했다고 가정해보겠습니다.

태스크도 남아 있고 기획서와 디자인 파일도 있습니다.

그런데 새 담당자는 다시 질문합니다.

• 이 업무는 왜 시작됐습니까?
• 고객과 어디까지 합의됐습니까?
• 중간에 범위가 왜 바뀌었습니까?
• 이 기능이 다른 업무보다 중요한 이유가 있습니까?
• 이전 담당자가 검토했던 대안은 무엇입니까?

행과 파일은 인수인계됐지만 맥락은 인수인계되지 않았습니다. 다음 판단을 내리려면 그 맥락이 필요합니다.

결국 새 담당자는 과거 문서를 처음부터 읽고 회의 참석자를 찾아가고 Slack을 검색하며 프로젝트의 역사를 다시 복원합니다.

엑셀을 전달했다고 프로젝트가 인수인계되지는 않습니다.

4. 현재 상태를 설명하기 위한 문서가 계속 늘어납니다

처음에는 스프레드시트 한 장이면 충분합니다.

하지만 구성원과 프로젝트가 늘어나면 같은 정보를 여러 형태로 다시 정리하기 시작합니다.

실무자가 관리하는 스프레드시트 
→ 대표 보고용 요약 
→ 고객 공유용 문서 
→ 주간회의용 슬라이드 
→ 별도의 Notion 페이지 
 

업무 상태가 바뀔 때마다 여러 문서를 함께 수정해야 합니다.

어느 하나가 갱신되지 않으면 서로 다른 최신 버전이 생깁니다.

Slack에서는 A안으로 이야기했고, 회의에서는 B안으로 바뀌었지만 Notion에는 여전히 A안이 남고 개발자는 GitHub에 적힌 C안을 구현하는 상황이 발생합니다.

이 시점부터 팀은 업무를 관리하는 것보다 현재 상태를 다시 설명하는 일에 더 많은 시간을 쓰기 시작합니다.

5. 행이 완료돼도 고객의 문제는 닫히지 않습니다

엑셀의 상태를 완료로 변경하면 업무는 끝난 것처럼 보입니다.

완료 이후에도 질문은 남습니다.

고객의 보고서 작성 시간은 실제로 줄었습니까?

숫자 오류가 감소했습니까?

고객이 이 기능을 실제로 사용하고 있습니까?

처음 해결하려던 문제가 사라졌습니까?

예상과 다른 결과가 나왔다면 무엇을 다시 바꿔야 합니까?

태스크 완료와 문제 해결은 다른 일입니다.

엑셀의 행은 닫혔지만,
고객의 문제는 아직 닫히지 않았을 수 있습니다.

작업 목록만 관리할 때는 완료가 마지막 단계입니다.

제품과 고객 문제를 관리할 때는 완료된 결과로 무엇이 실제로 달라졌는지 확인하는 단계까지 필요합니다.

“필요한 열을 더 만들면 되지 않나요?”

물론 가능합니다.

스프레드시트에 열을 추가하면 됩니다.

고객 문제, 결정 이유, 검토한 대안, 변경 내역, 최종 결정자, 완료 기준, 성과 지표, 관련 문서, 관련 작업 
 

기술적으로 엑셀에서 관리하지 못할 정보는 거의 없습니다. 하지만, 열이 계속 늘어나면 다른 문제가 생깁니다. 어떤 열을 반드시 작성해야 하는지 알기 어렵고, 담당자마다 작성하는 방식이 달라집니다. 심지어, 새로운 내용이 기존 내용을 덮어쓰기 쉬운 위험한 구조입니다. 혹은, 문서와 메시지 링크가 한 셀에 계속 쌓입니다. 이렇게 계속 사용하다보면, 누가 언제 어떤 이유로 변경했는지 알기 어렵습니다. 

결국 표를 만든 사람만 전체 구조를 이해합니다.

따라서 문제는 엑셀의 기능이 부족하다는 것이 아닙니다.

표로 기록할 수 있는가와
팀이 같은 방식으로 반복해서 운영할 수 있는가는 다른 문제입니다.

그렇다고 바로 Jira를 도입해야 하는 것은 아닙니다

엑셀과 무거운 프로젝트 관리툴 사이에는 여러 단계가 있습니다.

• 작업과 일정만 관리하면 되는 단계
  • 엑셀을 계속 사용하면 됩니다.
     
• 결정 이유가 가끔 사라지는 단계
  • 중요한 결정과 변경 사항만 별도로 남겨도 충분합니다.
     
• 여러 프로젝트에서 인수인계와 재작업이 반복되는 단계
  • 문제·결정·작업·결과가 이어지는 공통 구조가 필요합니다.
     
• 새로운 도구를 도입하는 비용이 지나치게 큰 단계
  • 기존 도구를 유지하고 도구 사이에서 끊기는 연결만 보완하는 방식이 더 적합합니다.

프로젝트 관리툴을 도입할지는 팀원 수만 보고 결정할 문제가 아닙니다.

현재 팀이 관리해야 하는 것이 업무 목록인지, 아니면 업무가 생긴 이유와 결과까지 이어지는 흐름인지 먼저 확인해야 합니다.

엑셀과 프로젝트 관리툴 사이에 필요한 최소 구조

복잡한 프로세스를 한 번에 만들 필요는 없습니다.

중요한 업무가 최소한 다음 흐름 안에 있도록 만드는 것부터 시작합니다.

고객의 문제 또는 목표 

  ↓ 

팀이 내린 결정 

  ↓ 

수행할 작업 

  ↓ 

만들어진 결과물 

  ↓ 

고객과 데이터로 확인한 변화 
 

이 흐름은 기존 글에서 정의한 작은 팀의 최소 실행 구조와도 같습니다.

중요한 업무마다 네 가지 질문에 답할 수 있어야 합니다.

• 왜 지금 이 일을 합니까?
• 어떤 결과를 내려는 일입니까?
• 누가 최종 결과를 책임집니까?
• 무엇을 확인하면 완료됐다고 판단합니까?

이 네 가지가 없다면 업무를 전달한 것이 아니라 해석해야 할 문제를 전달한 것에 가깝습니다.

뤼이도는 엑셀을 없애는 도구가 아닙니다

뤼이도는 엑셀이나 스프레드시트를 사용하면 안 된다고 말하지 않습니다.

Slack의 대화를 없애거나 Notion의 문서와 GitHub의 작업을 모두 한곳으로 옮기려는 것도 아닙니다.

기존 프로젝트 관리 도구가 주로 다음 질문에 답한다면,

• 무엇을 해야 하는가? 
   
• 누가 담당하는가? 
   
• 언제까지 해야 하는가? 
   
• 현재 상태는 무엇인가? 
   

뤼이도는 여기에 이런 질문을 연결합니다.

• 왜 이 일을 하는가? 
   
• 어떤 문제에서 시작됐는가? 
   
• 무엇을 근거로 결정했는가? 
   
• 중간에 무엇이 바뀌었는가? 
   
• 결과가 실제로 어떤 변화를 만들었는가? 
   

뤼이도는 목표, 결정, 작업, 결과물을 하나의 실행 맥락으로 연결하는 구조입니다. 팀이 이미 사용하는 도구는 그대로 두고 그 사이에서 사라지기 쉬운 인과관계를 남깁니다.

엑셀이 전사적인 프로젝트 관리 툴이면서, 이제는 조금 버겁다고 느껴지신다면, 그때 필요한 것은 엑셀을 버리는 일이 아닙니다.

작업이 어떤 문제에서 시작됐고,
어떤 결정을 거쳐 실행됐으며,
실제로 어떤 결과를 만들었는지 연결하는 일입니다.

팀이 관리해야 하는 대상이 단순한 태스크에서 문제·결정·결과의 연결로 바뀐 것입니다.

→ 우리 팀은 아직 엑셀로 충분한지 1분 진단하기

저희는 뤼이도 도입을 강요하지 않습니다. 그저 여러분이 갖고 계신 문제를 해결해드립니다.