프로젝트 관리 도구, 직접 만들 수 있을까? 네 가지 방법과 각각의 한계

프로젝트 관리 도구를 직접 만든다는 선택지는 AI가 등장하면서 훨씬 가까워졌습니다.

이 글에서는 직접 만드는 네 가지 방법을 비교하고, 각각의 수고와 한계를 정리합니다. 결론부터 말하면, 프로젝트 관리 도구는 만들 수 있습니다. 문제는 ‘몇 명이, 언제까지 쓰고, 누가 고칠 것인가’입니다.

참고: 이 글은 GeckoFlag 개발자가 작성했습니다. GeckoFlag는 개발자가 직접 만들어 쓰던 이슈 관리 도구를 제품으로 만든 것입니다. 이 연재에서는 직접 만들어 본 입장에서, 직접 만드는 일의 좋은 점과 힘든 점을 모두 써 나갑니다.

왜 직접 만들고 싶어질까

직접 만들기를 생각하게 되는 계기는 사람마다 다릅니다. 먼저 이유별로, 직접 만드는 것이 정말 해결책이 되는지 정리해 보겠습니다.

‘비싸다’, ‘너무 많다’가 이유라면 다른 기성 도구를 찾는 것으로도 해결될지 모릅니다. 반면 ‘일하는 방식이 특수해서 맞지 않는다’, ‘만드는 것 자체가 목적’이라면 직접 만들기에 잘 맞습니다.

이유가 분명하면, 이어서 소개할 방법 중에서 고를 때도 덜 망설이게 됩니다.

만드는 방법은 네 가지

프로젝트 관리 도구를 만드는 방법은 크게 다음 네 가지입니다.

표는 옆으로 스크롤할 수 있습니다 →

어떤 방법이든 ‘이슈를 등록하고, 담당자와 기한을 붙이고, 상태를 바꾼다’는 기본 형태는 만들 수 있습니다. 차이가 나는 것은 쓰는 사람이 늘어났을 때와, 만든 뒤에 고칠 때입니다. 차례로 살펴보겠습니다.

스프레드시트로 만들기

가장 손쉬운 것은 Excel이나 Google 스프레드시트로 만드는 방법입니다. 최소한의 구성이라면 열은 다음 네 개면 충분합니다.

• 이슈: 할 일을 한 행에 하나씩 쓴다
• 담당자: 누가 할지
• 기한: 언제까지 할지
• 상태: 시작 전·진행 중·완료 등을 드롭다운으로 고른다

기한이 지난 행에 색이 칠해지도록 조건부 서식을 설정하면 지연도 한눈에 보입니다. 1명~몇 명이 몇 달이면 끝나는 프로젝트라면, 이것만으로 충분히 돌아가는 경우도 적지 않습니다.

하지만 인원이나 이슈 수가 늘면 표는 조금씩 무너집니다. 경위를 적을 곳이 없고, 담당자를 적어도 본인에게 알림이 가지 않는다는 점 등입니다.

관련스프레드시트로 관리할 때의 한계는 입문 연재 「처음 쓰는 프로젝트 관리 도구」 제2회 「Excel 관리표는 어디서 한계가 올까?」에서 자세히 다룹니다

노코드 도구로 만들기

Notion이나 Airtable 같은 노코드 도구에서는 데이터베이스를 만들고, 이를 목록·칸반·캘린더 등의 형태로 표시할 수 있습니다. 프로그래밍을 하지 않아도 이슈 관리의 구조를 짜 맞출 수 있습니다.

항목을 자유롭게 추가할 수 있고 보기 좋게 다듬기 쉬운 것이 강점입니다. 우리 일에 맞춘 형태를 시험해 가며 만들 수 있습니다.

한편 다음과 같은 점에는 주의가 필요합니다.

• 인원에 따라 비용이 늘기 쉽다: 쓰는 사람 수에 따라 요금이 오르는 요금 체계가 많아, 결국 기성 도구와 비슷한 비용이 드는 경우가 있습니다.
• 만든 사람만 구조를 안다: 어떤 항목이 어디와 연결되어 있는지 만든 사람만 아는 상태가 되기 쉽습니다.
• 서비스 사정에 좌우된다: 서비스 쪽의 사양 변경이나 요금 개정이 있으면 그 영향을 그대로 받습니다.

코드를 직접 작성해 만들기

프로그래밍을 할 수 있다면 처음부터 만드는 방법도 있습니다. 자유도가 가장 높고, 우리 일에 딱 맞출 수 있습니다. 학습 소재로도 훌륭합니다.

다만 시간이 걸리는 것은 이슈 목록이나 등록 화면 같은 눈에 보이는 부분보다, 화면에 보이지 않는 부분입니다.

• 로그인과 비밀번호 관리
• 누가 어디까지 볼 수 있고 조작할 수 있는지에 대한 권한
• 데이터 저장, 그리고 데이터가 사라졌을 때를 위한 대비

게다가 만든 뒤의 버그 수정이나 서버·프로그래밍 언어의 업데이트 대응도 모두 직접 해야 합니다. 만드는 시간보다 만든 뒤에 계속 고치는 시간이 더 길어지는 일도 드물지 않습니다.

AI에게 만들게 하기

지금 가장 주목받는 것은 AI에게 코드를 써 달라고 하는 방법입니다. “이슈를 등록할 수 있고, 담당자와 기한과 상태를 붙일 수 있는 앱을 만들어 줘”라고 부탁하면, 몇 시간 만에 화면 위에서 돌아가는 것이 만들어지기도 합니다.

코드를 쓸 줄 몰라도 형태가 갖춰진다는 것은 큰 변화입니다. 다만 주의할 점이 있습니다.

바로 완성된 코드를 스스로 읽지 못하면, 버그가 생겼을 때 고칠 수 없다는 점입니다. AI에게 다시 부탁하면 고쳐지기도 하지만, 다른 곳이 망가지기도 합니다. 어디가 망가졌는지 판단하려면 결국 코드를 읽는 힘이 필요합니다.

또한 AI가 쓴 코드의 안전성이나 권리 관계는 사용하는 서비스의 약관과, 만든 것을 어떻게 쓰느냐에 따라 달라집니다. 업무에 쓴다면 사용하는 AI 서비스의 약관을 확인해 두세요.

연재실제로 AI로 어디까지 만들 수 있는지는 제2회 「AI에게 이슈 관리 앱을 만들게 해 보았다」에서 실험합니다(곧 공개)

무엇을 고를지는 ‘몇 명이, 언제까지, 누가 고칠 것인가’

네 가지 방법 중 무엇을 고를지는 도구의 기능보다 쓰는 상황으로 정해집니다. ‘몇 명이’, ‘언제까지’, ‘누가 고칠 것인가’의 세 가지로 기준을 정리하면 다음과 같습니다.

또한 일하는 방식이 특수해서 기성 도구로는 도저히 맞지 않는다면, 인원이나 기간과 관계없이 직접 만들기(코드를 직접 작성하거나 AI에게 만들게 하기)를 검토할 가치가 있습니다.

이 표는 어디까지나 기준입니다. 1명이나 소규모라도 도구를 쓰면 편해지는 경우는 있습니다.

특히 신경 써 주셨으면 하는 것은 마지막 행입니다. 외부 사람이 쓴다, 몇 년 동안 쓴다, 만든 사람이 이동이나 퇴사로 떠날 수도 있다. 이런 조건이 하나라도 해당된다면, 만들기 시작하기 전에 제3회 이후도 읽어 보세요.

‘돌아간다’와 ‘쓸 수 있다’ 사이에 있는 것

직접 만들기를 시작하면, 많은 사람이 도중에 깨닫는 것이 있습니다. ‘돌아간다’는 것과 ‘여러 사람이 오래 쓸 수 있다’는 것 사이에는 큰 거리가 있다는 사실입니다.

예를 들어 다음과 같은 것은 첫 화면을 만드는 동안에는 떠올리기 어려운 항목입니다.

• 멤버별로 볼 수 있는 범위: 외부 사람에게는 이 프로젝트만 보여 주고 싶다
• 비밀번호를 잊었을 때의 재설정: 본인이 메일로 재설정할 수 있는 구조가 필요하다
• 알림 메일: 담당자가 되었을 때, 댓글이 달렸을 때 알리고 싶다
• 데이터 백업: 서버가 고장 나도 이슈 기록을 잃고 싶지 않다

모두 쓰는 사람이 늘어나는 순간 필요해집니다. 그리고 하나씩 만들 때마다 확인할 것과 고칠 것이 늘어 갑니다.

연재직접 만든 뒤에야 깨닫는 항목은 제3회 「‘돌아간다’에서 ‘쓸 수 있다’까지의 거리」에서 체크리스트로 정리합니다(곧 공개)

정리

• 프로젝트 관리 도구는 스프레드시트, 노코드, 코드를 직접 작성, AI에게 만들게 하기의 네 가지 중 어떤 방법으로도 만들 수 있다
• 직접 만들기가 가장 효과적인 것은 일하는 방식이 특수해서 기성 도구가 맞지 않는 경우와, 만드는 것 자체가 목적인 경우
• 무엇을 고를지는 ‘몇 명이, 언제까지 쓰고, 누가 고칠 것인가’로 정해진다
• ‘돌아간다’와 ‘여러 사람이 오래 쓸 수 있다’ 사이에는 큰 거리가 있다

직접 만드는 것은 결코 무모한 선택이 아닙니다. 다만 만들기 전에 만든 뒤의 일까지 생각해 두면 돌아가는 길을 줄일 수 있습니다.

다음 회에서는 실제로 AI에게 이슈 관리 앱을 만들게 해서 어디까지 되는지 시험해 봅니다. 연재 마지막에는 직접 도구를 만든 개발자로서, 직접 만들기와 기성 도구 중 무엇을 골라야 하는지에 대한 결론을 쓸 예정입니다.

AI를 업무에 쓰게 되면서 태스크 관리 자체가 어떻게 달라지는지는 연재 「AI와 일하는 팀의 태스크 관리」 제1회 「AI를 쓰기 시작하면 태스크 관리 도구는 필요 없어질까?」에서 다룹니다.