SI 모듈화: 반복되는 절반과 다른 절반을 가르는 기준

견적 미팅에서 가장 많이 듣는 질문은 "이거 얼마나 걸려요"입니다. 그런데 로그인 화면 하나, 관리자 목록 화면 하나를 놓고 볼 때 이 답이 프로젝트마다 크게 흔들립니다. 매번 다른 고객, 다른 요구사항이니 당연해 보이지만, 실제로 화면을 다시 열어 보면 로그인 화면의 구조는 거의 항상 같습니다. 다른 것은 로고와 색상, 그리고 소셜 로그인 두어 개의 유무 정도입니다.

매번 새로 만든다는 전제가 틀린 이유

IT 수익모델을 다룬 글에서 SI와 SM 모두 "요구사항이 고객마다 달라 표준화가 어렵다"는 신호를 짚었습니다. 이 문장은 절반만 맞습니다. 요구사항 전체가 아니라 요구사항의 일부만 고객마다 다릅니다. 인증, 관리자 CRUD 화면, 파일 업로드, 결제 연동, 알림 발송처럼 어느 프로젝트에나 등장하는 부분이 있고, 그 회사의 업무 흐름과 예외 처리처럼 정말 그 고객만의 부분이 따로 있습니다.

문제는 이 둘을 가르지 않고 프로젝트를 시작하는 데 있습니다. 공통 부분까지 매번 새로 짜면, 그 시간이 정작 고객만의 요구사항을 깊이 파고들 시간을 깎아 먹습니다. 저는 SI에서 속도가 안 나는 원인의 상당수가 어려운 부분 때문이 아니라 쉬운 부분을 매번 반복하기 때문이라고 봅니다.

반복되는 절반을 미리 만들어 둔다는 것

이 절반을 미리 모듈로 만들어 두고 프로젝트마다 가져다 쓰는 방식을 저는 실제로 이렇게 쓰고 있습니다. DEUX는 검증된 컴포넌트를 재사용해 개발 시간을 줄이고 화면을 일관되게 유지하려고 만든 디자인 시스템입니다(deux.duolabs.co.kr). PAGE는 화면 단위의 UI 패턴을 모아 둔 패턴 킷이고, 새 프로젝트에서 비슷한 화면이 필요할 때마다 처음부터 그리는 대신 여기서 패턴을 골라 시작합니다(page.duolabs.co.kr).

두 자산의 성격은 다릅니다. DEUX는 버튼, 입력창, 카드처럼 화면을 이루는 작은 조각의 일관성을 잡고, PAGE는 로그인 화면이나 목록 화면처럼 조각들이 모인 화면 단위의 패턴을 잡습니다. 저는 이 두 층을 나눠 둔 것이 중요하다고 봅니다. 조각만 재사용하면 화면마다 조립하는 시간이 여전히 들고, 화면 단위만 재사용하면 그 고객만의 미세한 요구를 반영할 때 패턴 전체를 뜯어고쳐야 합니다. 둘을 같이 둬야 조각은 그대로 쓰고 화면 구성만 그 프로젝트에 맞게 바꾸는 일이 가능해집니다.

패턴 하나가 자산으로 쌓이는 과정

PAGE에 패턴 하나가 늘어나는 과정도 새로 짜는 것과는 다릅니다. 화면 스크린샷 한 장과 이 화면을 무엇으로 태그할지만 정하면, 그 화면의 구조를 패턴 소스와 데모로 만들고 레지스트리와 문서에 등록하는 절차가 뒤따릅니다. 등록하는 곳이 여러 군데(패턴 목록, 데모, 문서 ID, 추가 날짜, 썸네일)라는 것 자체가 핵심입니다. 이 중 하나라도 손으로 하다 빠뜨리면 그 패턴은 만들어졌는데 찾을 수 없는 패턴이 됩니다. 그래서 이 등록 과정 자체도 자동화해 두는 편이 낫습니다.

이 절차가 번거로워 보일 수 있지만, 저는 이 번거로움이 딱 한 번만 든다는 점이 핵심이라고 봅니다. 화면 하나를 패턴으로 등록하는 데는 시간이 들지만, 그 화면과 비슷한 요구가 세 번째 프로젝트에서 나오는 순간부터는 그 시간을 매번 아낍니다. 반대로 한 번밖에 안 쓸 화면을 패턴으로 만들면 등록 비용만 남고 아끼는 시간은 없습니다.

이 방식이 거꾸로 작동하는 경우

모듈화가 항상 이득은 아닙니다. 여기에는 두 가지 반대 방향의 위험이 있습니다.

첫째는 재사용을 과신하는 경우입니다. 겹치는 부분이 실제로는 적은데 모듈부터 만들면, 그 모듈은 프로젝트마다 다시 뜯어고쳐야 하는 짐이 됩니다. 만들 때 든 시간과 고치는 데 드는 시간을 더하면 처음부터 새로 짜는 것보다 느려집니다.

둘째는 반대로, 모듈에 맞추려고 고객의 요구를 깎는 경우입니다. 패턴 킷에 있는 화면이 편하다고 그 화면에 요구사항을 억지로 끼워 맞추면, 계약을 따낸 이유였던 그 고객만의 차별점이 사라집니다. 저는 이 실수가 첫 번째보다 더 위험하다고 봅니다. 속도는 빨라졌는데 고객이 원한 것과 다른 결과물이 나가면, 그 계약은 검수 단계에서 다시 길어집니다.

미리 재 볼 수 있는 기준

이전 글에서 "그 조건과 맞는 줄을 표에서 찾아 확인하는 순서"라고 적은 것과 같은 맥락에서, 저는 모듈화를 시작하기 전에 하나만 재 봅니다. 최근에 진행한 프로젝트 몇 건을 놓고, 화면 수 대비 DEUX와 PAGE에서 그대로 가져다 쓸 수 있었던 화면이 몇 개였는지를 셉니다. 이 비율이 낮다면 그 시기에 들어오는 프로젝트들이 서로 겹치지 않는다는 뜻이고, 모듈을 늘리기보다 그때그때 짜는 편이 낫습니다.

이 비율에 정해진 기준선은 없습니다. 다만 이 숫자를 재지 않고 "모듈화하면 빠를 것 같다"는 느낌만으로 자산을 늘리면, 위에서 말한 첫 번째 위험, 아무도 다시 안 쓰는 모듈을 쌓아 두는 상황에 가장 쉽게 빠집니다.

같은 숫자는 견적을 낼 때도 씁니다. 화면 열 개짜리 프로젝트에서 여섯 개가 기존 패턴으로 시작할 수 있다면, 그 여섯 개의 견적 시간은 처음부터 짜는 시간이 아니라 그 고객에 맞춰 수정하는 시간으로 계산합니다. 이 계산을 프로젝트 시작 전에 미리 해 두면, 앞서 말한 "이거 얼마나 걸려요"라는 질문에 감이 아니라 근거로 답할 수 있습니다.

SM 계약에서 달라지는 것

SM 쪽에서는 속도보다 다른 이득이 있다고 저는 봅니다. 여러 고객이 같은 디자인 시스템과 패턴 킷 위에서 시스템을 쓰고 있다면, 한 고객에서 발견한 개선이나 버그 수정이 다른 고객에게도 같은 방식으로 적용될 수 있습니다. 이 점은 아직 제가 실제 계약 조건에 반영해 본 적은 없는, 앞으로 시도해 볼 방향입니다. 다만 "이번 유지보수가 이 고객 한 명만을 위한 것이 아니다"라는 사실이, 매번 가격을 새로 협상해야 하는 이유를 줄여 줄 수는 있다고 봅니다.

모듈화가 목적이 되면 안 되는 이유

여기서 다룬 것은 결국 고객마다 다른 부분과 같은 부분을 먼저 가르고, 같은 부분만 미리 만들어 두자는 이야기입니다. 반대로 모듈화 자체를 목표로 삼아 모든 프로젝트를 그 모듈에 맞추려 들면, SI의 본질인 "이 고객만의 문제를 푼다"는 부분이 없어집니다. 저는 모듈화가 잘된 상태를 화면을 더 적게 만드는 상태가 아니라, 같은 시간에 고객만의 문제에 더 많은 시간을 쓸 수 있는 상태로 정의하고 싶습니다.