정렬과 세부 설정을 어디까지 정의해야 하는가

백오피스 화면설계를 하다 보면, 생각보다 자주 부딪히는 질문이 있습니다. 화면 곳곳에 드롭다운이 붙고, 그 드롭다운은 대개 “공통 코드”에서 불러오게 되어 있는데, 막상 설계서를 쓰다 보면 이런 고민이 생깁니다. “공통 코드에서 이미 정의된 값이라면, 이 화면에서는 어디까지 다시 적어야 하지?”라는 고민입니다. 특히 숙소/리조트 목록, 지역 목록, 법인 목록, 유형 코드처럼 여러 화면에서 반복 사용되는 값일수록, 한 번 기준이 흔들리면 전체 설계와 운영이 동시에 흔들릴 수 있습니다. 그래서 이 주제는 단순한 문서 작성 습관이 아니라, 시스템을 안정적으로 운영하기 위한 원칙의 문제로 다루어야 합니다.

 

질문: “가져다 쓰는 화면에서 다시 정의해야 하나?”

이 질문의 본질은 결국 하나로 모입니다. 공통 코드 관리에서 이미 정의되어 있는 드롭다운 데이터라면, 그 데이터를 불러오는 각 화면에서도 정렬 기준이나 표시 순서, 활성/비활성 여부, 노출 우선순위 같은 세부 속성을 다시 한 번 정의해야 하느냐는 것입니다. 예시로 들었던 숙소/리조트 목록, 지역 목록, 법인 목록, 유형 코드 같은 것들은 한 번 만들어지면 여러 화면에서 계속 등장합니다. 그러니 화면 설계자가 “이 화면에서 보기 좋게”라는 이유로 순서를 다시 손대기 시작하면, 어느 순간부터는 어디가 기준인지가 흐려지고, 유지보수할수록 시스템이 복잡해지는 문제가 생깁니다.

답: 기본적으로는 ‘안 한다’

결론부터 분명히 말씀드리면, 공통 코드에서 불러오는 드롭다운 데이터라면 기본적으로는 화면에서 다시 정렬이나 정책을 정의하지 않습니다. 여기서 “안 한다”는 말은 대충 넘어간다는 뜻이 아닙니다. 오히려 설계의 책임을 정확히 분리하겠다는 선언에 가깝습니다. 공통 코드를 공통 코드답게 쓰겠다는 태도이며, 이 태도가 백오피스 설계를 안정적으로 만드는 핵심이 됩니다.

 

공통 코드의 역할

공통 코드가 왜 존재하는지를 먼저 정의해야 합니다. 공통 코드는 여러 화면에서 동일한 의미로 반복 사용되는 데이터를 하나의 곳에서 관리하기 위한 장치입니다. 다시 말해 “정의와 관리가 한 곳에서만 이루어지는 단일 기준”을 만드는 것이 공통 코드의 목적입니다. 값 자체가 공통인 것도 중요하지만, 그 값이 어떤 순서로 노출되어야 하는지, 사용 가능한 상태인지, 운영 정책이 무엇인지까지 한 곳에서 일관되게 관리되도록 만드는 것이 더 중요합니다.

그래서 공통 코드가 제대로 설계되어 있다면, 그 안에는 이미 정렬 순서가 들어가 있고, 사용 여부(활성/비활성)가 정의되어 있으며, 노출 정책이 포함되어 있다는 전제를 두는 것이 자연스럽습니다. 그리고 화면 설계자는 그 전제를 기반으로 “이 드롭다운은 공통 코드 관리에 정의된 순서와 상태를 그대로 따른다”라는 의도를 가져가는 것이 일반적입니다. 여기서 화면이 할 일은 공통 코드의 정책을 재정의하는 것이 아니라, 공통 코드가 관리하고 있는 결과를 그대로 받아서 UI에 반영하는 것입니다.

이 관점에서 화면 설계서에서 정렬에 대한 설명을 생략하는 것은 ‘누락’이 아닙니다. 공통 코드에 책임을 위임하는 설계 결정입니다. 즉, “안 적는다”가 아니라 “그건 저쪽에서 관리한다고 명시하고 이쪽에서는 반복하지 않는다”에 가깝습니다.

 

중복 정의는 곧 불일치의 시작

공통 코드에서 순서가 정해져 있는데도, 어떤 화면에서 “이 화면에서는 이렇게 보이면 좋겠는데요?”라는 이유로 정렬을 다시 두기 시작하면, 곧바로 질문이 따라옵니다. 공통 코드에서 순서가 바뀌면 이 화면은 어떻게 되는가라는 질문입니다. 그 순간 선택지는 사실상 두 개뿐입니다. 공통 코드를 따라가며 화면의 정렬도 같이 바꾸든지, 아니면 화면만 따로 유지하든지인데, 둘 다 문제가 생깁니다. 전자는 화면이 공통 코드에 종속된다는 사실을 인정하고 화면에서 별도 정렬을 둘 이유가 사라지고, 후자는 공통 코드와 화면의 정렬 불일치를 낳습니다.

불일치가 생기면 운영과 개발, 기획 커뮤니케이션이 동시에 어려워집니다. 공통 코드에서 A→B→C 순서로 정의돼 있는데 어떤 화면은 C→A→B로 보여주는 순간부터 “어디가 기준이죠?”, “누가 책임지죠?”라는 질문이 나오기 시작합니다. 그리고 그 설명 비용은 결국 화면 설계자가 떠안게 됩니다. “공통 코드가 바뀌었는데 이 화면은 따로 유지합니다” 같은 예외 규칙을 계속 설명해야 하고, 그 예외는 시간이 갈수록 누적됩니다. 결국 시스템은 유지보수 지옥으로 들어가게 됩니다.

그래서 화면에서 정렬을 또 두는 것은 단지 문서가 길어지는 문제가 아니라, 정책 충돌을 만드는 설계가 될 수 있다는 점을 명확히 인식해야 합니다.

 

책임은 한 곳에만 둔다

실무에서 가장 안전하고 관리 비용이 적은 원칙은 “데이터의 정렬과 정책은 그 데이터를 관리하는 메뉴에서만 한다”는 것입니다. 공통 코드의 정렬은 공통 코드 관리에서 결정하고, 값을 불러오는 화면은 그대로 가져다 씁니다. 이 원칙을 지키면, 정렬을 바꾸고 싶을 때 어디를 고치면 되는지가 명확해집니다. 공통 코드에서만 바꾸면 모든 화면에 동일하게 반영됩니다. 이런 구조가 공통 코드의 존재 이유와 정확히 맞아떨어집니다.

그리고 값을 호출하는 화면은 설계서에서 “출처”만 명시하면 됩니다. 예를 들어 “공통 코드 > 리조트 관리에서 호출” 같은 식으로 어디에서 관리되는지 연결점을 적어주고, 화면에서는 “해당 코드의 활성 상태만 노출” 정도로만 정의해 주면 충분합니다. 이렇게 되면 정렬에 대한 설명은 의도적으로 생략됩니다. 생략이 아니라 설계 원칙에 따른 역할 분리입니다.

또 하나 중요한 태도는 설명을 한 번만 한다는 것입니다. 모든 화면에서 모든 요소의 모든 조건을 반복해서 설명하려고 하면 문서는 끝없이 길어지고, 내용은 중복되고, 수정할 때마다 불일치가 생길 가능성이 커집니다. 반대로 “이건 여기서 관리된다”고 한 번만 확실하게 정해두면, 그 관리 화면을 보면 된다는 흐름이 생깁니다. 이것은 불친절이 아니라 구조적으로 더 친절한 방식입니다. 기준이 한 곳에 있으니 찾아보기 쉬워지고, 책임이 분명해지기 때문입니다.

 

예외: 화면별 순서가 ‘정책’인 경우에만

다만 언제나 예외가 없는 것은 아닙니다. 공통 코드의 순서를 그대로 따르지 않고 화면별로 다른 정렬이 필요해지는 경우가 있습니다. 대표적으로 화면별로 다른 순서가 ‘정책’인 경우입니다. 공통 코드에서는 지역을 A→B→C 순서로 관리하지만, 특정 화면에서는 “최근 사용 빈도 기준으로 정렬한다”처럼 화면의 목적상 다른 정렬 기준이 정책으로 필요한 상황이 있을 수 있습니다. 이 경우에는 화면 전용 정렬 로직을 명시할 수 있습니다. 다만 이때는 “이 화면 전용”이라는 점을 분명히 적어야 합니다. 그래야 공통 코드와 충돌하지 않고, 예외의 책임 범위도 명확해집니다.

또 하나는 임시성이나 실험성 기능인 경우입니다. A/B 테스트를 하거나 특정 관리자 전용 화면처럼 실험적 목적이 분명한 경우에는 화면별 정렬을 둘 수 있습니다. 하지만 이 경우에도 “왜 다르게 하는지”를 반드시 명시해야 합니다. 이유 없이 다르게 하면 그것은 정책이 아니라 혼란이 됩니다.

 

지금 케이스에서 화면에서 정렬을 다시 정의하지 않는 이유

정리하면, 지금 이야기하고 있는 케이스에서는 공통 코드가 이미 존재하고, 그 순서/정렬이 의미 있는 데이터이며, 여러 화면에서 재사용될 가능성이 높고, 화면 단위에서 따로 바꿀 이유가 없는 상황입니다. 그러니 가장 합리적인 결론은 공통 코드의 정렬을 그대로 따른다는 것입니다. 화면에서는 따로 설정하지 않습니다. 이 선택은 단순히 편해서가 아니라, 관리 비용을 가장 적게 만들고, 정책 충돌을 예방하고, 설명 중복을 줄이며, 유지보수 포인트를 최소화하는 방향입니다.

 

“하나의 기능은 하나의 메뉴에서만 책임진다”

공통 코드 기반 드롭다운을 다룰 때 가장 중요한 원칙은 이것입니다. 하나의 기능은 하나의 메뉴에서만 책임진다. 공통 코드가 공통 코드로 기능하려면, 정의와 정책과 정렬이 한 곳에 있어야 하고, 다른 화면들은 그 결과를 사용해야 합니다. 그래야 기준이 흔들리지 않고, 프로젝트가 커져도 무너지지 않습니다.

결국 공통 코드에서 가져오는 데이터라면 정렬과 정책은 공통 코드에서만 관리하고, 호출하는 화면에서는 다시 정의하지 않는 것이 기본 원칙입니다. 이 원칙을 분명하게 이해하고 문서에 자연스럽게 녹여낼 수 있으면, 백오피스 설계에서 흔히 발생하는 혼란을 초반에 차단할 수 있고, 이후 화면이 늘어나도 일관된 구조를 유지할 수 있습니다.