출금 FAQ 비공개 토글로 운영자 직접 제어 가능해짐

출금 관련 FAQ 비공개 처리 토글 기능을 달고, 1:1 문의 흐름도 함께 손봤다.

왜 이 작업이 생겼나

운영 측에서 FAQ 항목을 일시적으로 숨겨야 할 때마다 개발자에게 직접 요청이 들어오는 상황이 반복됐다. 특히 출금 관련 안내 문구는 정책 변경 주기가 짧은 편이라, 해당 항목을 DB에서 직접 지우거나 플래그를 수동으로 바꾸는 일이 잦았음. 운영자가 직접 공개/비공개를 제어할 수 있는 토글이 없으면 매번 배포나 DB 작업 없이는 대응이 안 되는 구조였다.

거기에 1:1 문의 쪽도 같이 손봐야 할 포인트가 있었다. 문의 등록/답변 흐름에서 일부 케이스가 깔끔하게 처리되지 않던 부분이 있었고, 이번 작업과 맞물려서 같이 개선하는 게 낫겠다 판단했다.

작업 내용

이번에 변경된 파일들은 크게 세 레이어로 나뉜다.

FAQ 비공개 토글은 단순해 보이지만 설계 포인트가 몇 가지 있다. 상태값을 Y/N 같은 단순 플래그로 관리할 때, 토글 API가 현재 상태를 받아서 반전시키는 방식으로 갈지, 아니면 명시적으로 "공개 처리", "비공개 처리" 두 엔드포인트로 분리할지 선택이 필요하다. 이번엔 단일 토글 방식으로 처리했는데, 운영자가 실수로 연타했을 때 의도치 않게 뒤집히는 문제가 생길 수 있어서 프론트 쪽에 디바운싱 처리가 함께 가이드됐어야 했다. 나중에 코드리뷰 때 이 부분을 짚어줬다.

// 비공개 토글 처리 예시 패턴 (일반화)
public ResponseEntity<?> toggleFaqVisible(String faqId) {
    FaqVO faq = faqService.selectFaq(faqId);
    String nextStatus = "Y".equals(faq.getVisibleYn()) ? "N" : "Y";
    faq.setVisibleYn(nextStatus);
    faqService.updateFaqVisible(faq);
    return ResponseEntity.ok(Map.of("visibleYn", nextStatus));
}

쿼리 매퍼 쪽에서는 공개여부 컬럼 업데이트와, 목록 조회 시 비공개 항목을 운영자/일반 사용자에 따라 다르게 필터링하는 분기를 추가했다. 이게 꽤 중요한 부분인데, 일반 사용자 화면에서 비공개 항목이 노출되면 안 되고, 운영자 화면에서는 비공개 항목도 같이 보여서 관리가 가능해야 한다. SQL에서 role 조건으로 분기를 태우는 방식이 익숙하지만, 쿼리가 복잡해지면 MyBatis <if> 태그로 조건 분기를 넣는 게 가독성 면에서 낫다.

<!-- MyBatis 공개여부 필터 예시 -->
<select id="selectFaqList" parameterType="FaqVO" resultType="FaqVO">
    SELECT *
    FROM FAQ
    WHERE 1=1
    <if test="isAdmin == null or isAdmin == false">
        AND VISIBLE_YN = 'Y'
    </if>
    ORDER BY SORT_ORDER ASC
</select>

ExcelConfigRegistry.java가 같이 바뀐 건, FAQ 목록을 엑셀로 내려받을 때 비공개 항목 포함 여부를 설정으로 제어하기 위한 연동이었다. 엑셀 다운로드 설정을 중앙에서 레지스트리 형태로 관리하고 있던 구조라, 신규 엔티티가 추가될 때마다 여기에 등록해줘야 하는 흐름이었음. 처음 보는 팀원한테는 이 흐름이 암묵지처럼 숨겨져 있어서 온보딩할 때 꼭 짚어주는 포인트 중 하나다.

회고

이런 운영성 기능은 "작은 것 같지만 안 되면 가장 먼저 클레임이 들어오는" 류다. FAQ 비공개 토글 하나가 없어서 긴급 배포나 DBA 협조가 필요했던 상황이 실제로 반복됐고, 이번에 그 고리를 끊었다. 비슷한 운영 도구들—공지 노출 여부, 배너 노출 제어—이 같은 방식으로 운영자 친화적으로 바뀌어야 할 목록이 아직 몇 개 더 남아 있다.

1:1 문의 개선은 이번에 크게 건드리지 않고 핀포인트로 처리했는데, 문의 흐름 전반을 리팩터링하려면 별도 이슈로 분리해서 영향 범위를 다시 분석해야 한다. 한 커밋에 너무 많은 맥락이 섞이면 나중에 git blame 추적이 힘들어진다. 이번처럼 연관성이 높은 CS 도메인이라 같이 묶었지만, 다음번엔 문의 개선은 별도 PR로 가져가는 게 좋겠다고 팀에도 이야기해뒀다.

다음엔 비공개 상태 변경 이력 로깅도 붙여야 할 것 같다.