업무 시스템 다시 만들기 (1) 칸반보드로 시작했습니다

첫 제품이 왜 방향을 바꿨는지를 다룹니다. 시리즈의 다른 글 보기

안녕하세요. 오픈소프트랩 개발팀입니다.

지금은 보안 운영과 AI 거버넌스 제품을 만들고 있지만, 회사의 첫 제품은 애자일 기반 프로젝트 관리 도구였습니다. 2015년에 회사가 문을 열었고 이 제품이 모양을 갖춘 건 그다음 해였으니, 10년쯤 됐습니다.

이 시리즈는 그 뒤로 업무 시스템을 몇 번 다시 만들면서 무엇을 잘못 판단했는지에 대한 이야기입니다. 첫 편은 첫 제품입니다.

도구를 만들면 팀이 바뀔 거라고 봤습니다

당시 애자일은 국내에 막 들어오던 참이었습니다. 해외에서는 이미 기본이었고, 국내 선도 기업들이 도입을 시작하던 시기였습니다.

저희가 만든 건 스크럼을 그대로 담은 도구였습니다.

• 스프린트 단위로 작업을 끊고
• 번다운 차트로 계획 대비 진척을 보여주고
• 칸반보드로 지금 무엇이 어디까지 갔는지 펼쳐 보이고
• 작업 흐름의 단계를 프로젝트마다 직접 정의할 수 있게

생각은 단순했습니다. 보이게 만들면 나아진다. 어디가 막혔는지 모두가 알면 스스로 조정할 거라고 봤습니다. 애자일 책에 그렇게 적혀 있었고, 저희도 그렇게 믿었습니다.

개인 능률을 퍼센트로 보여주는 화면

문제는 "보이게" 만드는 방식에 있었습니다.

저희가 만든 화면 중에 이런 게 있었습니다.

개인 능률 그래프

  A  ████████████████████░░  133%
  B  ░░░░░░░░░░░░░░░░░░░░░░    0%

당시 제품 화면의 구조입니다.

번다운 차트도 프로젝트 단위와 팀원 단위를 나란히 뒀습니다. 누가 계획대로 가고 있고 누가 뒤처져 있는지가 한 화면에 들어왔습니다.

만들 때는 좋은 기능이라고 생각했습니다. 관리자는 리스크를 빨리 발견할 수 있고, 팀원은 자기 상태를 객관적으로 볼 수 있으니까요. 소개서에도 개인 능률을 시각적으로 표현하여 빠른 의사결정을 돕는다고 적었습니다.

실제로는 사람들이 도구를 피했습니다.

작업을 잘게 쪼개 등록하면 진척이 정확히 드러납니다. 그래서 잘게 쪼개지 않았습니다. 상태를 제때 옮기면 지연이 바로 보입니다. 그래서 제때 옮기지 않았습니다. 데이터가 안 들어오니 차트는 비어 가고, 비어 있는 차트를 보고 관리자는 더 채우라고 합니다.

기능이 고장 난 게 아니었습니다. 설계한 대로 정확히 동작했고, 그래서 쓰이지 않았습니다.

방법론이 문화를 못 이겼습니다

시간이 지나고 나서 정리된 건 이겁니다.

애자일에서 진척 공개는 팀이 스스로 조정하기 위한 것입니다. 뒤처진 사람을 돕기 위해 보는 것이지 평가하려고 보는 게 아닙니다. 책에는 그렇게 쓰여 있고, 그 전제가 성립하는 조직에서는 실제로 그렇게 돌아갑니다.

그런데 그 전제가 성립하지 않는 곳에서는 같은 화면이 평가표가 됩니다. 공수가 적나라하게 드러나고, 드러난 숫자는 사람을 따라다닙니다. 그러면 사람은 숫자가 안 나오게 행동합니다.

저희는 도구로 문화를 바꿀 수 있다고 봤는데, 도구는 문화 위에서만 동작했습니다.

이걸 알고 나서 선택지는 둘이었습니다. 방법론을 지키고 맞는 고객만 찾거나, 방법론을 버리고 실제로 쓰이는 것을 만들거나.

저희는 후자를 골랐습니다.

디자인도 시장과 어긋나 있었습니다

같은 시기에 다른 문제도 있었습니다.

저희 화면은 색이 많았습니다. 작업 흐름의 단계마다 색을 지정할 수 있게 했더니 진행률 막대 하나에 색이 열 개 넘게 들어갔습니다. 칸반보드는 컬럼마다 다른 파스텔 톤이었습니다.

만들 때는 구분이 잘 된다고 생각했습니다. 단계가 많으니 색으로 갈라주는 게 친절하다고 봤습니다.

그런데 공공 사업에서 요구하는 화면은 그런 게 아니었습니다. 더 절제되고 정돈된 쪽을 원했습니다. 색이 열 개씩 들어간 화면은 그 기준에서 완성도가 낮아 보입니다.

디자인 역량이 부족했던 것도 사실입니다. 그때 저희는 여섯 명이었고 디자인을 전담하는 사람이 따로 있지 않았습니다.

기능이 아무리 맞아도 첫 화면에서 판단이 끝나는 자리가 있다는 걸 그때 배웠습니다.

방법론을 버리고 남긴 것

다음 제품은 애자일 방법론을 걷어냈습니다.

버린 것 — 스프린트 강제, 팀원별 번다운 차트, 개인 능률 지표. 그리고 칸반보드도 없앴습니다. 지금 제품에는 칸반보드가 없습니다.

남긴 것 — 요청을 등록하고, 담당자를 정하고, 상태를 옮기고, 이력을 남기는 뼈대. 방법론과 무관하게 업무 시스템이면 다 필요한 부분입니다.

얻은 것 — 데이터가 들어오기 시작했습니다. 개인이 아니라 일 단위로 보게 되니 등록을 피할 이유가 없어졌습니다. 그리고 공공 사업에 들어갈 수 있는 형태가 됐습니다.

포기한 것 — 진척 가시성이 낮아졌습니다. 개인 단위로 보면 분명 빨리 보이는 것들이 있었습니다. 지금은 프로젝트나 조직 단위까지만 보고, 개인까지 내려가지 않습니다. 관리자 입장에서는 답답한 구석이 남습니다.

칸반보드를 없앤 자리에는 조직마다 다르게 구성하는 대시보드를 넣었습니다. 모두에게 같은 보드를 보여주는 대신, 각자 보고 싶은 것을 고르게 하는 방향입니다.

어디까지 보여줄 것인가

이건 지금도 조직마다 다르게 답하는 문제입니다.

업무 시스템은 결국 누가 무엇을 언제 했는지를 기록합니다. 그 기록을 어디까지 누구에게 보여줄 것인가는 기능의 문제가 아니라 조직의 문제입니다. 같은 화면이 어떤 조직에서는 협업 도구가 되고 어떤 조직에서는 감시 도구가 됩니다.

저희가 지금 쓰는 기준은 기본값을 낮게 두는 것입니다. 개인 단위 지표는 기본으로 보여주지 않고, 필요하면 조직이 켜게 합니다. 켜는 순간 그건 조직의 결정이 되고, 저희가 대신 결정하지 않습니다.

이게 옳은지는 모르겠습니다. 안 보여줘서 놓치는 것도 분명히 있습니다. 다만 첫 제품에서 기본값으로 보여줬을 때 무슨 일이 일어나는지는 봤기 때문에, 반대쪽에서 시작하기로 했습니다.

다음 편에서는 방법론을 걷어낸 뒤 그 뼈대를 어떻게 다시 썼는지 다룹니다.

오픈소프트랩 개발팀이 작성합니다. 보안 운영 포탈과 생성형 AI 사용 통제를 만들고 있습니다.