앱·웹 제작에서 아키텍처가 곧 유지보수 비용인 이유

홈페이지나 앱을 처음 맡길 때, 많은 분들이 디자인 시안과 가격표부터 보십니다. 그건 자연스러운 일입니다.

그런데 오픈 반 년 뒤 “이것만 고쳐 주세요”가 쌓이면서 견적이 다시 나오는 경우가 많습니다. 결제 수단 하나 추가, 회원 등급, 알림, 재고 연동처럼 처음 목록에 없던 요청이 들어올 때마다 일정이 늘고 비용이 붙습니다.

이때 “기능이 많아서”라고만 설명하면 핵심을 놓칩니다. 실제로 수정 단가를 좌우하는 것은 화면 뒤 구조입니다. 데이터가 어디에 쌓이는지, 서버와 앱이 어떻게 정보를 주고받는지, 권한·기록·배포가 어떻게 되어 있는지가 앞으로의 청구서를 만듭니다.

개발자만 쓰는 말처럼 들릴 수 있지만, 발주자 입장에서는 앞으로 2~3년 동안 유지보수 비용이 어떻게 나올지에 가깝습니다.

왜 이런 일이 생기나요?

잘 나뉜 구조에서는 “주문 상태 하나 추가”가 주문 관련 화면과 알림 규칙 정도로 끝납니다.

반대로 화면·데이터·권한 규칙이 한곳에 뒤섞여 있으면, 같은 요청도 결제·재고·통계 화면까지 연쇄로 건드리게 됩니다. 견적 단위가 “기능 1개”가 아니라 “영향 받은 파일 묶음”이 되는 이유입니다.

장애 대응도 비슷합니다. 비용을 키우는 것은 고치는 시간보다 원인을 찾는 시간인 경우가 많습니다. 기록이 없거나 서버·앱·관리자 로그가 제각각이면, 같은 버그를 며칠씩 반복 문의하게 됩니다.

배포와 설정도 사람 기억에 의존하면 위험합니다. “이 서버에만 수동으로 올려둔 설정”, “개발자 PC에만 있는 키”는 초기에는 빨라 보이지만, 담당자가 바뀌는 순간 비용이 됩니다.

회원, 주문, 결제, 포인트, 재고가 서로 다른 곳에 흩어져 있고 규칙이 코드 여기저기에 있으면, 리포트 하나 만들 때도 전수 조사가 필요합니다. “대시보드 하나 추가”가 비싸지는 전형적인 원인입니다.

이렇게 보면 쉬워요

화면 중심이 항상 틀린 것은 아닙니다. 일회성 랜딩, 이벤트 페이지, 수명이 짧은 캠페인에는 합리적일 수 있습니다.

반면 앱·쇼핑몰·회원 서비스처럼 데이터와 권한이 계속 쌓이는 제품에서는 구조를 같이 잡는 편이 장기 비용을 낮춥니다.

이렇게 준비하면 좋아요

아래 질문은 기술 면접이 아니라 유지보수 청구서를 미리 그려 보는 용도입니다.

1. 회원·주문·결제·콘텐츠 데이터가 어디에 저장되고, 누가 수정할 수 있는지 그림으로 설명 가능한가?
2. 관리자 화면과 사용자 앱·웹이 같은 규칙을 쓰는가, 아니면 관리자만 예외로 우회하는가?
3. 결제 실패·부분 취소·중복 요청 같은 예외 흐름이 설계에 포함되는가?
4. 테스트 환경과 운영 환경이 분리되는가?
5. 소스 저장소, 배포 방식, 서버·도메인·스토어·결제 계정 소유가 발주자 쪽으로 정리되는가?
6. 로그·백업·모니터링이 “나중에”가 아니라 오픈 범위에 포함되는가?
7. 기능 추가 시 견적이 어떤 단위로 산정되는지(화면 수 vs 업무 영향) 사전에 합의되는가?

이 질문에 “최신 기술로 잘 만듭니다”만 돌아온다면, 아직 구조 대화가 시작되지 않은 상태입니다.

회의 안건을 “어떤 프레임워크를 쓰나요?”가 아니라 이렇게 바꿔 보시면 됩니다.

1. 12개월 후 반드시 필요할 기능 3개를 먼저 적습니다. (등급, 정산, 다점포, 앱 푸시 등)
2. 각 기능이 지금 데이터 구조에서 자연스럽게 붙는지 제안사에 묻습니다.
3. “가능합니다”가 아니라 어디를 고치고, 어떤 위험이 있는지를 한 단락으로 받아 적습니다.
4. 그 답변을 견적 비교표의 행으로 만듭니다. 가격 행보다 위에 둡니다.

내부 보고에는 “기술 부채” 대신 운영 비용·장애 시간·재개발 확률 언어가 설득에 유리합니다. 구조에 쓰는 예산은 개발팀 취향이 아니라, 마케팅·고객센터·경영이 함께 지는 리스크 완충 장치입니다.

자주 하는 실수

구조를 미룬 채 오픈하면 단기적으로는 일정이 당겨 보입니다. 그러나 비용은 보통 아래 형태로 돌아옵니다.

• 같은 문구 변경도 여러 화면·하드코딩을 건드려 수정 단가가 올라감
• 앱과 관리자, 웹과 앱이 서로 다른 규칙을 가져 기능을 두 번 구현
• 1~2년 뒤 “처음부터 다시” 견적과 데이터 이관 비용
• 담당자 이탈 시 배포·결제 설정 복구에만 수주 소요
• 권한·개인정보 처리가 임시 구현이면 사고 한 번에 비용이 폭증

싼 초기 견적은 “구조를 안 잡은 가격”인 경우가 많습니다. 그 차액은 사라지지 않고 운영 구간에 이자처럼 붙습니다.

• □ 이번 프로젝트가 3개월 캠페인인지, 3년 운영 제품인지 구분했다
• □ 핵심 업무(회원/주문/결제/콘텐츠 등) 목록을 문서화했다
• □ 관리자·사용자·외부 연동(결제, 알림, 물류) 경계를 표로 정리했다
• □ 예외 흐름(실패, 취소, 중복, 권한 없음)을 최소 한 번씩 시나리오로 적었다
• □ 소스·서버·도메인·스토어·결제 계정 소유자를 계약·체크리스트에 명시했다
• □ 오픈 범위에 로그·백업·테스트 환경 중 무엇을 포함할지 합의했다
• □ 기능 추가 견적 단위를 사전에 합의했다
• □ “화면 수만으로 견적”인 제안과 “구조 포함 견적”을 비교했다

LB Contents는 앱·홈페이지·쇼핑몰 제작과 운영 구조를 함께 설계합니다. 화면 목록만 있는 단계에서도, 어떤 경계와 운영 전제를 먼저 잡을지 상담할 수 있습니다.