기능 개발보다 중요한 것, 그 기업의 일하는 방식 이해하기
홈페이지 제작이나 기업 전산 시스템 개발을 진행하다 보면
많은 프로젝트가 비슷한 요청에서 출발한다.
“이 기능을 추가해 주세요.”
“이 화면을 이렇게 바꿔 주세요.”
하지만 실제로 프로젝트를 깊이 진행할수록
기능보다 훨씬 더 중요한 요소가 드러난다.
바로 그 기업이 실제로 어떻게 일하고 있는지,
그리고 그 방식이 지금도 효율적인지에 대한 이해다.
웹사이트와 전산 시스템은 단순한 화면이나 기능의 집합이 아니라
기업의 업무 구조와 의사결정 방식을 그대로 담아내는 결과물이다.
1) 왜 기능 개발만으로는 문제가 해결되지 않을까
많은 기업 시스템이 시간이 지날수록 복잡해지는 이유는 명확하다.
업무 구조에 대한 정리 없이
당장의 요구사항과 기능부터 구현하기 때문이다.
이런 경우 다음과 같은 문제가 반복된다.
- 부서마다 다른 기준이 시스템에 그대로 반영됨
- 예외 처리 로직이 계속 누적됨
- 정책 변경 시 수정 범위가 과도하게 커짐
결과적으로 시스템은 점점 무거워지고
유지보수 비용과 운영 피로도는 계속 증가한다.
2) 전산 시스템 개발은 ‘업무 구조’를 설계하는 일이다
전산을 만든다는 것은
기능을 구현하는 작업이 아니다.
그 회사가 어떤 기준으로 판단하고,
어떤 순서로 일을 처리하며,
어디에서 비효율이 발생하는지를 구조로 정리하는 일이다.
좋은 시스템은 다음 질문에 답할 수 있어야 한다.
- 이 정보는 어디서 생성되는가
- 누가 어떤 기준으로 판단하는가
- 사람이 해야 할 일과 시스템이 대신할 일은 무엇인가
- 정책이나 조건이 바뀌면 어디까지 자동으로 반영되는가
이 질문에 대한 답이 정리되지 않은 상태에서 만든 기능은
결국 다시 수정하게 된다.
3) 사례 ① 타이어 쇼핑몰 개발에서 드러난 업무 구조
타이어 쇼핑몰과 재고관리 시스템을 개발할 당시,
처음에는 단순한 상품 판매 구조처럼 보였다.
하지만 실제로 구현을 시작하자
일반 상품과는 전혀 다른 관리 기준이 존재했다.
- 단면폭·편평비·인치로 구성된 표기 체계
- DOT(제조 월·년)에 따른 재고 관리 기준
- 장착점 예약과 실물 재고의 연동 구조
이 요소들은 단순한 정보가 아니라
검색, 비교, 재고 회전, 고객 신뢰에 직결되는 핵심 데이터였다.
결국 시스템은 ‘상품을 나열하는 쇼핑몰’이 아니라
타이어 유통 구조 자체를 반영하는 형태로 설계되어야 했다.
4) 사례 ② 렌탈 통합 전산에서 발견한 정책 구조
렌탈 전산 시스템을 설계하면서 가장 중요했던 포인트는
판매 채널이 아니라 정책 구조였다.
대기업 렌탈 상품은
누가 판매하든 동일한 월·년 단위 정책을 따른다.
이 구조를 반영하지 않으면
채널이 늘어날수록 관리 부담은 기하급수적으로 증가한다.
그래서 전산의 기준을
쇼핑몰 단위가 아닌
브랜드 + 정책 단위의 상품 구조로 재정의했다.
그 결과 정책을 한 번 수정하면
연동된 모든 상품과 채널에 동시에 반영되는 구조를 만들 수 있었다.
5) 사례 ③ 지도 기반 시스템이 만든 정보 인식의 변화
부동산 솔루션을 개발하며 확인한 사실은 명확했다.
위치 기반 정보는 텍스트 목록보다
공간 중심 구조가 훨씬 직관적이라는 점이다.
이 경험은 경기 어촌특화지원센터 프로젝트에서도 그대로 적용됐다.
행정 단위 리스트 대신 지도를 중심으로 정보를 배치하자
사용자는 훨씬 빠르게 위치와 환경을 이해할 수 있었다.
이는 단순 UI 변경이 아니라
정보 인식 방식 자체를 바꾼 구조 설계였다.
정리
기능은 언제든 추가할 수 있다.
디자인도 얼마든지 바꿀 수 있다.
하지만 기업의 일하는 방식과 업무 구조에 대한 이해 없이 만든 시스템은
결국 다시 뜯어고치게 된다.
그래서 웹과 전산은
기존 업무를 그대로 옮기는 도구가 아니라
더 나은 구조를 제안하는 수단이어야 한다.
기능 개발보다 중요한 것은
그 기업이 어떻게 일하고 있는지를 이해하는 일이다.
