템플릿화와 하드코딩

기획자가 반드시 이해해야 할 구조

온라인 서비스는 겉으로 보기에는 디자인과 화면이 전부처럼 보이지만, 실제로는 데이터의 입력–처리–출력 구조 위에서 움직이는 시스템입니다. 사용자가 웹 브라우저나 앱을 통해 접속하면, 서버에서 전달된 데이터와 코드가 해석되어 화면에 표현됩니다. 브라우저는 서버로부터 받은 코드를 그림처럼 렌더링하고, 앱은 설치된 프로그램 구조 안에 데이터를 주입하여 화면을 구성합니다. 즉, 우리가 보는 화면은 결국 “데이터가 어떻게 설계되어 있는가”에 따라 달라집니다. 기획자는 화면을 설계하지만, 실제로는 데이터를 설계하고 있는 셈입니다

 

온라인 서비스에서 데이터는 어떻게 존재하는가

서비스에서 다루는 데이터는 매우 단순한 형태에서 시작합니다. 예를 들어 어떤 기능이 활성화되어 있는지 여부를 판단할 때는 Y/N 같은 값이 사용됩니다. 상태 변화를 구분할 때는 01, 02, 03처럼 숫자로 구분하기도 합니다. 반복적으로 생성되는 값에는 Sequence 방식이 쓰입니다. 이벤트 ID처럼 하나씩 증가하는 번호가 대표적입니다. 그리고 텍스트(TEXT) 데이터는 언어와 코드 조합을 통해 다양한 메시지를 표현합니다. 이처럼 단순해 보이는 데이터 구조가 쌓여서 하나의 서비스 로직을 형성합니다. 그렇기 때문에 기획 단계에서 “이 데이터가 앞으로 어떻게 쓰일 것인가”를 고민하지 않으면, 나중에 확장과 유지보수에서 큰 문제가 발생합니다.

 

확장성

초기 기획에서 가장 흔히 발생하는 실수가 바로 “지금 필요한 것만 설계하는 것”입니다. 예를 들어 상품 상태를 ‘판매중’과 ‘품절’ 두 가지로만 정의했다고 가정해 보겠습니다. 하지만 나중에 ‘예약판매’, ‘단종’, ‘한정특가’ 같은 상태가 추가된다면 어떻게 될까요? 초기 설계에서 확장 가능성을 고려하지 않았다면 시스템 전체를 수정해야 할 수도 있습니다. 따라서 상태값이나 조건값을 정의할 때는 “앞으로 추가될 가능성”을 반드시 열어두어야 합니다. 이것이 바로 확장성을 고려한 기획입니다.

 

코드화 논의는 왜 중요한가

기획자는 종종 “이 문구를 이렇게 보여주세요” 수준에서 멈추기 쉽습니다. 그러나 실제로는 그 문구를 텍스트 그대로 저장할 것인지, 코드값으로 관리할 것인지에 따라 시스템의 유연성이 달라집니다.

예를 들어 상품 상태를 “특가”라는 텍스트로만 저장한다고 가정해 보겠습니다. 나중에 다른 시스템에서 이 상태를 참조하거나 조건문에 활용하려고 할 때 문제가 발생합니다. 반면 상태값을 01(특가), 02(일반), 03(예약)처럼 코드로 관리한다면, 로직에서 훨씬 유연하게 활용할 수 있습니다. 코드화는 단순히 개발 편의를 위한 것이 아닙니다. 확장성과 관리 효율성, 쿼리 활용도, 타 시스템 연동까지 고려한 구조적 설계입니다. 따라서 기획자는 개발자와 이 부분을 반드시 협의해야 합니다.

 

하드코딩이란 무엇인가

하드코딩은 말 그대로 조건이나 변수 없이 특정 값을 고정해 두는 방식입니다. 예를 들어 이벤트 기간을 코드 안에 직접 “2026년 3월 1일 ~ 3월 10일”이라고 작성해 두는 것이 하드코딩입니다. 이 방식은 당장은 빠르고 단순합니다. 그러나 변경이 필요할 때마다 개발 작업이 다시 들어가야 합니다. 이벤트가 수시로 반복되는 서비스라면 유지보수 비용이 기하급수적으로 증가합니다. 하드코딩은 단기적으로는 편리해 보이지만, 장기적으로는 확장성과 자동화를 가로막는 구조입니다.

 

시스템 템플릿화란 무엇인가

반대로 시스템화는 로직을 통해 데이터를 동적으로 불러와 처리하는 방식입니다. 예를 들어 이벤트명을 변수 a, 이벤트 기간을 변수 b로 정의해 두고, 해당 기간에만 자동으로 노출되도록 설정할 수 있습니다. 어드민에서 이벤트 기간만 수정하면 프론트 화면은 자동으로 반영됩니다. 또는 이벤트 종료 시간을 기준으로 타이머가 자동으로 작동하도록 설계할 수도 있습니다. 이 경우 이벤트 페이지는 하나의 템플릿으로 유지되며, 데이터만 바뀌면 새로운 이벤트로 동작합니다. 이것이 바로 템플릿화입니다. 하나의 구조를 만들어두고 데이터를 바꿔가며 재사용하는 방식입니다.

 

개발 시 반드시 고려해야 할 관점

중요한 점은 UI 중심이 아니라 데이터 중심으로 개발을 바라봐야 한다는 것입니다. 화면이 어떻게 보일지가 아니라, 그 화면을 구성하는 데이터가 어떤 구조로 저장되고 어떤 로직으로 불러와지는지가 더 중요합니다. 특히 어드민이나 백오피스에서 데이터를 저장할 때는 “최종 출력 형태”를 염두에 두어야 합니다. 예를 들어 이벤트를 등록할 때 이벤트명, 기간, 노출 여부, 배너 이미지, 혜택 설명 등을 각각 데이터로 저장해 두면, 프론트에서는 해당 값을 조합해 자동으로 페이지를 구성할 수 있습니다. 이 구조가 잡히지 않으면, 매번 새로운 화면을 따로 개발해야 하는 비효율이 발생합니다.

 

하드코딩의 근본적인 문제

하드코딩은 결국 “텍스트를 텍스트로만 다루는 방식”입니다. 변수 없이 값이 고정되어 있기 때문에 로직으로 불러오거나 조건 처리하기가 어렵습니다. 기능이 추가될 때마다 코드 수정이 필요하고, 자동화가 어렵습니다. 반면 시스템화는 데이터와 로직을 분리합니다. 값은 데이터베이스에 있고, 화면은 로직을 통해 그 값을 불러옵니다. 이 구조가 되면 자동화, 템플릿화, 확장, 재사용이 가능합니다.

 

정리

하드코딩은 고정된 값 중심의 구조입니다. 빠르게 만들 수 있지만 유지보수와 확장이 어렵습니다. 시스템화는 데이터 중심의 구조입니다. 로직에 의해 동적으로 처리되며 자동화와 템플릿화가 가능합니다.

결국 차이는 이것입니다.
하드코딩은 “한 번 쓰고 버리는 구조”에 가깝고,
템플릿화는 “계속 재사용되는 구조”입니다.