시민 개발은 만능이 아니다, ‘초안 개발’이다 5/7회

서문

4회에서는 코드로 남지 않은 자산이 장차 부정적 유산으로 남을 것임을 확인했다. 여기서 다시 묻고 싶은 것이 있다. 시민 개발은 본판 시스템을 만드는 수단인가?

결론부터 말하면 시민 개발은 본판을 떠맡는 구조가 아니다. 그 본질은 **이용자 시각의 요구를 “움직이는 형태”로 담아내는 ‘초안 개발’**이다.

이 관점을 잊고 “시민 개발 = 누구나 즉시 시스템을 만드는 마법의 도구”라고 착각하면, 역사가 반복하듯 부정적 유산을 또다시 양산하게 된다. 그렇다면 ‘초안 개발’이란 어떤 의미를 가지며 어떻게 활용해야 할까.

시민 개발로 현장이 만든 앱이나 도구는 종종 “미완성” 또는 “거칠다”고 평가된다. 그러나 그 “거침”이 바로 가치다.

영업부가 로우코드로 만든 고객 관리 앱을 상상해 보자. 그 안에는 현장이 매일 느끼는 “이렇게 해야 편하다”라는 직감이 반영된다.

이런 요소는 단순한 “요구사항 정의서”로는 전달되지 않는다. 문장으로 사양을 설명해도 현장이 원하는 뉘앙스나 “업무의 촉감”은 거의 빠진다. 동작하는 프로토타입이 있어야만 “이건 쓸 만하다”, “실제로는 불편하다”와 같은 반응을 생생하게 끌어낼 수 있다.

움직이는 초안이 있으면 “여기에 검색 기능이 없으면 곤란하다”, “승인 플로는 3단계가 아니라 2단계여야 한다” 처럼 요구의 오해나 누락을 빠르게 찾는다.

기존 시스템 개발은 “요구사항 정의서를 읽은 전문가가 상상으로 설계”하는 경우가 많았다. 그 때문에 완성 후 “생각과 다르다”는 현장의 불만이 쏟아져 되돌리기가 일상화됐다. 시민 개발은 이런 불모의 되돌리기를 줄이는 강력한 무기가 될 수 있다.

그러나 초안을 그대로 본판으로 쓰면 안 된다. 그곳에는 큰 함정이 숨어 있다.

즉 “초안에 가치가 있다”와 “초안을 본판으로 써도 된다”는 완전히 다른 문제다. 카미 엑셀이 잠시 구세주였다가 끝내 부정적 유산으로 추락한 것과 똑같은 구조가 반복될 뿐이다.

그렇다면 시민 개발 산출물을 어떻게 다뤄야 할까. 답은 명확하다.

이 역할 분담을 철저히 지키면 서로의 강점을 극대화할 수 있다. 시민은 “현장의 생생한 감각”을 그대로 도구에 담는다. 전문가는 “품질과 지속성”을 보장하는 본판을 책임진다.

과거 방식이 “요구사항 정의서만 의지해 상상으로 설계”했다면, 초안이 존재할 때는 처음부터 해상도가 높은 논의가 가능하다. 그 결과 시스템 개발은 효율화되고 산출물의 품질도 높아진다.

시민 개발을 건전하게 활용하려면 조직 차원의 규칙이 반드시 필요하다.

이런 거버넌스를 갖추면 카미 엑셀 같은 부정적 유산을 재생산할 위험을 크게 줄일 수 있다. 반대로 이 규칙이 없다면 시민 개발은 “야생 앱 제조기”에 불과해 조직의 기술 부채만 늘린다.

시민 개발은 “누구나 본판 시스템을 만들 수 있는 만능 구조”가 아니다. 하지만 “초안”으로 활용하면 요구 정의의 오해와 누락을 줄이고, 이용자 시각이 충분히 반영된 시스템 설계를 실현할 수 있다.

본판을 담당하는 사람은 전문가, 초안을 그리는 사람은 시민. 이 역할 분담을 철저히 하면 시민 개발은 부정적 유산이 아니라 미래 생산성 향상의 출발점이 된다.

즉 시민 개발의 진정한 의의는 “민주화된 요구 정의 프로세스”에 있다. 이 이해가 있어야만 시민 개발은 조직에 지속 가능한 힘이 된다.