1:1 문의 목록과 엑셀에 인입구분 컬럼 추가

1:1 문의 목록에 인입구분 컬럼을 노출하는 작업을 마무리했다. 목록 화면과 엑셀 다운로드 두 군데 모두 반영.

왜 이 작업이 필요했나

운영자 입장에서 1:1 문의를 처리할 때, 해당 문의가 어떤 경로로 들어왔는지를 한눈에 파악하는 게 꽤 중요하다. 앱인지, 웹인지, 아니면 특정 페이지에서 직접 유입됐는지에 따라 담당 팀이나 처리 우선순위가 달라질 수 있기 때문이다. 그런데 기존 목록 화면에는 인입구분 데이터가 DB에는 쌓이고 있었지만 컬럼 자체가 노출되지 않았다. 운영자들이 개별 상세 페이지를 열어서 확인하거나, 엑셀 뽑아서 별도로 정리하는 불편함을 감수하고 있었던 것.

이런 류의 "데이터는 있는데 UI에서 안 보여줬던 것"을 뒤늦게 올려달라는 요청은 사내 어드민에서 꽤 자주 들어온다. 처음 기획 단계에서 빠졌거나, 운영을 해보니 필요성이 생긴 경우다. 빠른 피드백 루프라고 볼 수도 있는데, 팀 입장에서는 이런 작은 요청들이 쌓이면 개발 흐름이 자주 끊기기 때문에 배치로 묶어서 처리하는 게 낫다.

변경 범위 훑기

이번 변경에서 손댄 파일은 크게 네 곳이다.

딱 이 4개 레이어를 수직으로 관통하는 작업이다. 레이어 하나라도 빠지면 화면엔 보이지만 엑셀엔 없거나, 엑셀엔 있는데 값이 null로 나오거나 하는 식의 반쪽짜리 결과가 나온다. 이 정도 규모는 흔히 "단순 컬럼 추가"로 취급받지만 실제로는 전 레이어를 다 확인해야 해서 꼼꼼함이 필요한 작업이다.

ExcelConfigRegistry 패턴에 대해

ExcelConfigRegistry 방식은 엑셀 다운로드 컬럼 구성을 중앙에서 관리하는 구조다. 각 화면별로 어떤 컬럼을 어떤 순서로, 어떤 헤더명으로 내보낼지를 코드 한 곳에 등록해두는 방식인데, 이 패턴의 장점은 JSP나 Controller에서 엑셀 로직이 분산되는 걸 막아준다는 점이다.

// ExcelConfigRegistry 등록 예시 (일반적인 패턴)
registry.register("support_ticket",
    ExcelColumn.of("inqType",    "인입구분"),
    ExcelColumn.of("title",      "문의 제목"),
    ExcelColumn.of("status",     "처리 상태"),
    ExcelColumn.of("createdAt",  "등록일시")
);

이런 구조가 잡혀 있으면 새 컬럼 추가할 때 registry에만 한 줄 추가하면 되니까 팀원들도 부담 없이 건드릴 수 있다. 반대로 각 화면마다 HSSFCell, CellStyle 설정이 흩어져 있는 레거시 구조에서는 컬럼 하나 추가하는 데 파일을 3~4개씩 열어서 맞춰야 한다. 이번 작업하면서 이 Registry 구조가 잘 되어 있어서 엑셀 쪽 변경은 상대적으로 빠르게 끝났다.

SQL 쪽에서 놓치기 쉬운 것

쿼리 매퍼에서 SELECT 절에 컬럼 추가하는 건 간단해 보이지만, 목록 쿼리에서 빠진 경우 결과 VO나 Map에 값이 아예 안 실리기 때문에 Controller까지 올라와도 null이다. 이번처럼 기존 데이터가 DB에 잘 쌓여 있는 상황에서 쿼리만 빠졌던 케이스라면, 쿼리 수정 후 바로 값이 뜨는 걸 확인할 수 있다.

-- 기존
SELECT ticket_id, title, status, created_at
  FROM tb_support_ticket

-- 변경 후
SELECT ticket_id, title, status, inq_type, created_at
  FROM tb_support_ticket

간단한 변경이지만 코드리뷰 때 이 부분을 명시적으로 diff로 보여주는 게 중요하다. "쿼리도 같이 변경했습니다" 한 마디로 리뷰어의 확인 포인트가 줄어든다.

회고

• 목록과 엑셀을 동시에 작업하는 게 맞는 방향이었다. 둘을 따로 티켓으로 쪼개면 "목록엔 보이는데 엑셀엔 없다"는 QA 이슈가 생기고, 다시 배포 한 번 더 나가는 일이 벌어진다.
• 이번 작업처럼 전 레이어를 건드리는 "단순 컬럼 추가"는 주니어 멤버가 처음 도전하기 좋은 유형이다. 레이어 간 흐름을 직접 따라가면서 구조를 익힐 수 있기 때문이다. 다음번엔 이런 작업을 멘토링 소재로 활용해볼 생각.
• ExcelConfigRegistry 같은 중앙 관리 구조의 가치는 이런 반복 요청이 올 때 체감된다. 처음 구조 잡을 때 조금 더 신경 쓴 덕분에 지금 팀이 덜 고생한다.

끝.