본문이 길어지면 문서 전체가 스크롤되어 사이드바까지 함께 밀려 올라갔다. shell을 뷰포트 높이로
못박고 overflow를 끊은 뒤, 두 칸이 각자 overflow-y를 갖게 했다(AdminShell과 같은 방식).
좁은 화면에서는 종전처럼 위아래로 쌓이고 문서가 스크롤된다.
사이드바를 디자인 시스템으로 옮겼다 — 손으로 그린 테마 전환 버튼 묶음을 FoxSegmentedControl로,
항목 옆 개수를 FoxBadge로 바꿨다. 대체된 .themeSwitch·.themeButton·.navCount 스타일은 지웠다.
검증 — 1600×900 실측: shell 900·overflow hidden, 문서 전체 스크롤 없음, 사이드바(3237)·
본문(9432) 각각 자체 스크롤.
Co-Authored-By: Claude Opus 5
`FoxStatusIndicator`는 색이 성공/경고 둘뿐이라 「답변대기·처리중·답변완료·보류」를
`answeredAt`의 유무로만 갈라 두 색에 욱여넣고 있었다. 상태 수만큼 색을 줄 수 있는
`FoxBadge`(pastel/md — 같은 표의 「구분」 배지와 같은 계열)로 바꾼다.
색은 코드값이 아니라 **코드명**으로 고른다. `BBS_ANS_CD`의 실제 코드값을 아직 확인하지
못했고(백엔드 소스에 없고 DB 코드테이블에만 있다), 코드값을 맞게 적어도 코드관리 화면에서
언제든 바뀔 수 있다. 반면 코드명은 화면에 그대로 보이는 값이라 「완료」·「대기」 같은 낱말로
읽는 편이 실제로 맞을 확률이 높다. 「미처리」가 「처리」보다 먼저 걸리도록 순서를 두었고,
걸리는 낱말이 없으면 `neutral`로 떨어진다 — 뜻을 지어내지 않는다.
코드값이 비어 있으면 배지 없이 `-`만 둔다(빈 배지를 그리지 않기 위해서다).
확인: 임시 페이지로 답변대기=warning, 처리중=information, 답변완료=success, 보류=danger,
모르는 값=neutral, 빈 값=`-`를 렌더링해 확인 후 페이지를 지웠다.
Co-Authored-By: Claude Opus 5
상태를 프론트 상수 표(`WAIT`/`ING`/`DONE`)로 치환하고 있었다. 그 표를 지우고 공통코드
`BBS_ANS_CD`를 조회해 코드명으로 옮긴다 — 꾸미기 아이템 카테고리(`ITEM_CATE_CD`)와 같은 방식이다.
목록의 "상태" 열과 답변 팝업의 진행상태 선택지, Server Action의 허용 코드 검증이 모두 같은
응답을 본다. 페이지가 한 번 조회해 목록으로 내리고, Server Action은 저장 직전에 다시 조회한다
(화면이 보낸 코드를 그대로 믿지 않기 위해서다 — 아이템 카테고리와 같은 근거).
`ANSWER_STATUS_DONE`만 상수로 남는다. "답변완료일 때만 FO 노출·답변일 표시"라는 판단이 특정
코드값을 알아야 하는데 BBS_ANS_CD의 실제 값을 아직 확인하지 못해 TODO로 표시해 두었다.
Co-Authored-By: Claude Opus 5
1:1문의 컬럼이 공지·FAQ와 같은 `actionsColumn('inquiry')`를 쓰고 있어 연필을 누르면 **글 수정
폼**이 열렸다. 관리자는 질문 글을 수정하지 않는다 — 전용 `InquiryRowActions`가 이미 있었는데
컬럼에 연결되지 않아 쓰이지 않고 있었다. 연결하고, 그 버튼도 무스타일 `components/ui/button`
에서 다른 목록과 같은 `FoxIconButton`(연필·휴지통)으로 바꿨다.
답변 팝업은 기획(1676:18693)대로 @fox로 다시 그렸다 — FoxModal·FoxInput·FoxTextArea·FoxSelect.
기획의 "게시물의 항목 (조회 전용)" 구분 제목, 질문자명/작성일·이메일/전화번호 2열, 진행상태
안내 문구를 그대로 옮겼다. 답변내용에는 글자수 카운터가 붙는다.
## 곁들여 고친 것
첨부 상한 상수를 `file-repository`(server-only)에서 도메인으로 옮겼다. 지난 커밋에서 클라이언트
컴포넌트가 그 상수를 가져오게 만들어 `next/headers`가 클라이언트 번들로 끌려들어 갔고, dev에서
"You're importing a module that depends on next/headers"로 빌드가 깨졌다.
첨부 입력은 Tailwind 제거 이후 무스타일이라 토큰으로 파일선택 버튼 모양을 맞췄다.
Co-Authored-By: Claude Opus 5
두 가지가 겹쳐 세 토글이 모두 먹히지 않았다.
1. 폼과 Server Action의 값 규약이 어긋났다. 팝업을 @fox로 옮기며 토글을 value="true"로 두었는데
게시판 액션의 readBoolean은 'Y'만 참으로 본다 — 켜도 항상 false가 되어 'N'으로 저장됐다.
꾸미기 아이템 쪽 규약을 그대로 가져온 것이 원인이라 게시판 규약('Y')에 맞췄다.
2. 수정 PUT을 쿼리스트링으로 보내고 있었다. 백엔드 update는 @RequestBody(JSON)라 본문이 비어
바인딩이 되지 않고, 통과하더라도 전 필드가 null이라 UPDATE의 가드가
모두 건너뛴다 — 수정으로는 어떤 값도 바뀌지 않았다. 1:1문의 답변 저장도 같은 경로였다.
등록 POST는 컨트롤러가 form 바인딩이라 그대로 둔다.
검증 — 팝업 FormData 실측: 기본 상태 isVisible='Y'(켜짐)·isPinned/isPushEnabled 없음(꺼짐),
두 토글을 켜면 셋 다 'Y'로 실린다(액션의 'Y' 규약과 일치).
TODO(백엔드): 앱푸쉬는 이 수정으로도 저장되지 않는다 — PUSH_YN이 MngrBbsMapper.xml의
INSERT·UPDATE·SELECT 어디에도 없다.
Co-Authored-By: Claude Opus 5
## 확인한 것
임시 Server Action에 파일을 크기별로 보내 재현했다.
- 100KB · 9MB → 정상 도달
- 10.5MB · 12MB · 21MB → 500 `Unexpected end of form`
21MB에서도 "Body exceeded 20mb limit."이 아니라 같은 오류가 나므로 `bodySizeLimit`의 판정이
아니다 — Next 16.2.12(Turbopack) dev에서 Server Action의 multipart 본문이 **10MB 부근에서
잘리고**, 그러면 액션 본문이 실행되지 않아 서버에서 손쓸 방법이 없다.
## 고침
막을 수 있는 곳이 브라우저뿐이라 첨부 input에서 크기를 먼저 잰다. 상한을 넘으면 선택을 비우고
문구를 띄운다 — 종전에는 그대로 전송돼 처리 불가한 500으로 끝났다.
`bodySizeLimit`은 20mb로 올려 두었다. 이번 절단과는 무관하지만, 앱 상한(첨부 10MB)과 같은 값이면
초과 파일이 우리 검증 대신 전송 단계에서 먼저 잘려 "10MB 이하만" 문구를 영영 보여줄 수 없다.
Co-Authored-By: Claude Opus 5
`/dev-test/design`이 개발 빌드에서만 인증 면제였다(proxy의 DEV_ONLY_PUBLIC_PATHS가
NODE_ENV !== 'production'일 때만 평가됐다). 운영·테스트 환경에서는 세션이 없으면 /login으로
리다이렉트돼 볼 수 없었다.
PUBLIC_PATHS에 넣어 환경 구분을 없앴다. 페이지 쪽에는 이미 프로덕션 차단이 없어 주석만 정리했다.
검증 — 쿠키를 모두 지운 상태에서 /dev-test/design 요청이 200, 리다이렉트 없음. 프로덕션
빌드 산출물에도 라우트가 포함된다.
Co-Authored-By: Claude Opus 5
등록·수정·답변·삭제 네 곳 모두 Repository 호출을 try/catch 없이 부르고 있었다. 첨부 업로드만
감싸여 있었다. 백엔드가 거절하면 `BackendRequestError`가 Server Action 밖으로 그대로 튀어
프레임워크의 오류 처리로 넘어가고, 화면에는 "Cannot read properties of undefined (reading
'stack')" 같은 엉뚱한 오류가 뜬다 — 사용자는 무엇이 잘못됐는지 알 수 없다.
네 곳을 `runWrite`로 감싸 실패를 폼 상태로 바꾼다. 백엔드가 준 문구를 그대로 보여주고, 그것이
없을 때만 일반 문구로 떨어진다 — 다른 화면(관리자·아이템)이 이미 쓰는 방식이다.
Co-Authored-By: Claude Opus 5
두 가지가 어긋나 있었다.
**분류 필터가 탭이었다.** 시안은 `chip-area`에 `chip` 세 개(전체·노출·미노출)다.
`FoxTab`을 `FoxChipArea` + `FoxChip type="action"`으로 바꿨다 — `check` 계열은 켜졌을 때
체크 아이콘이 붙는데, 시안의 "전체"와 "노출"이 둘 다 42px로 같아 아이콘이 없는 계열이다.
초기화 버튼도 시안이 28×28이라 `size="md"`(40)에서 `sm`으로 내렸다.
**검색 대상에 구분이 없었다.** 시안은 닫힌 상태가 "구분"인데 공지사항의 검색 대상이 제목
하나뿐이었다. 구분을 첫 항목으로 넣어 기본값이 되게 하고, 검색값은 코드가 아니라 표기 라벨로
견준다(사용자가 "공통"을 치면 걸리게).
확인: 초기화 버튼 28×28, chip-area x=36, 칩 43/43/56×28, 체크 아이콘 없음, 검색 대상 "구분" —
시안 치수와 1px 안에서 일치한다.
Co-Authored-By: Claude Opus 5
`board-post-columns.tsx`가 `'use client'` 모듈인데 서버 컴포넌트인 page가 거기 함수를 직접
호출했다 — 클라이언트 모듈의 non-component export는 서버에서 참조 프록시라 부르면 던진다
("Attempted to call faqColumns() from the server"). 공지·FAQ·1:1문의 세 화면이 모두 같았다.
컬럼을 클라이언트에서 만들도록 옮겼다. `boardPostColumns(boardType, page, pageSize)` 하나가
세 팩토리를 갈라 주고, `BoardPostList`가 이미 받고 있던 boardType·currentPage·pageSize로 직접
부른다. page는 columns prop을 넘기지 않는다.
옮기지 않고 `'use client'`만 떼는 방법은 안 된다 — 컬럼의 `render`가 함수라 서버에서 만들어
클라이언트로 넘기는 것 자체가 RSC 경계를 못 넘는다. 만드는 쪽을 클라이언트로 옮겨야 한다.
확인: FAQ 목록을 클라이언트에서 렌더해 컬럼 8개(번호·구분·유형·제목·작성자·등록일·사용여부·
관리)가 서고 콘솔 오류가 없다.
Co-Authored-By: Claude Opus 5
