"만든 사람이 안 열어본 화면은, 결국 아무도 안 열어본 화면이다."
관리자 화면은 저 혼자 쓰는 화면이라, 지금까지 데스크톱에서만 확인하고 넘어갔습니다. 그런데 우연히 모바일로 /admin/projects를 열어봤다가 "사이드"라는 배지 텍스트가 "사이\n드"로 쪼개져 있는 걸 발견했습니다. 처음엔 이 페이지 하나만 고치면 될 줄 알았습니다. 그런데 다른 admin 페이지를 하나씩 열어보니 같은 증상이 계속 나왔습니다:
배지 텍스트가 글자 단위로 줄바꿈됨 헤더의 "새 글 작성" 같은 버튼이 제목/설명 텍스트와 어긋나게 배치됨 테이블이 모바일에서 컬럼 폭을 억지로 유지하려다 제목이 한 글자씩 세로로 쌓임 일부 버튼 텍스트("확정", "삭제" 등)도 똑같이 쪼개짐 좁은 flex 칸에 갇힌 일반 문장이 부자연스럽게 잘림
전부 다른 페이지, 다른 컴포넌트인데 근본 원인은 하나였습니다 — 텍스트가 좁은 공간에 들어갈 때 줄바꿈을 막는 처리(whitespace-nowrap)가 애초에 없었던 것입니다.
8개 admin 페이지를 375px 폭으로 전수 조사한 뒤, 문제를 5가지 유형으로 분류했습니다:
배지 글자 단위 줄바꿈 (9개 파일) 헤더 제목/설명과 액션 버튼 어긋남 (4개 파일) 테이블이 모바일에서 안 깨지는 오버플로우 (3개 파일) 버튼 텍스트 줄바꿈 (1개 파일) 일반 텍스트가 좁은 칸에 갇혀 쪼개짐 (2개 파일)
1번과 2번은 각각 Badge, AdminPageHeader라는 공유 컴포넌트로 뽑아서 한 번에 해결했습니다. 3번은 <table> 구조를 걷어내고 데스크톱은 12분할 grid, 모바일은 세로 카드형으로 전환했습니다. 4번과 5번은 컴포넌트화 대신 필요한 곳에 whitespace-nowrap, break-keep 같은 유틸리티 클래스를 직접 추가했습니다.
관리자 화면을 모바일에서 열어봤다가 배지 텍스트가 한 글자씩 쪼개지는 걸 발견했습니다. 하나를 고치고 보니 같은 화면 다른 곳에서 또, 다른 페이지에서 또 나왔습니다. 8개 페이지를 전수 조사해서 5가지 패턴으로 분류하고, 공유 컴포넌트 2개로 근본 해결한 과정을 기록합니다.
컴포넌트화와 개별 수정을 어떻게 나눌지가 이번 작업의 핵심 판단이었습니다.
배지, 헤더: 8개 페이지 중 4곳 이상에서 똑같은 패턴이 반복됐고, 앞으로 admin 페이지가 늘어날 걸 감안하면 공유 컴포넌트로 뽑는 게 맞았습니다. 테이블: 컬럼 개수와 내용이 페이지마다 완전히 달라서, 억지로 공통 Table 컴포넌트를 만들면 오히려 조건 분기가 늘어나 가독성이 떨어질 거라 판단했습니다. 대신 반응형 CSS 패턴(hidden sm:grid, flex-col sm:grid)만 반복 적용했습니다. 버튼, 일반 텍스트: 발생 빈도가 낮고 각각 스타일이 커스텀되어 있어서, 컴포넌트화보다 클래스 하나 추가하는 게 더 낮은 비용으로 같은 효과를 냈습니다.
즉 "반복되는 정도"와 "구조의 다양성"을 기준으로 컴포넌트화 여부를 나눴습니다.
이번 작업에서 일반화할 수 있는 체크리스트는 이렇습니다:
관리 화면이라도 모바일에서 한 번은 열어본다 — 본인만 쓰는 화면일수록 오히려 검증이 빠지기 쉽습니다. 같은 버그가 두 곳 이상에서 나오면 그 시점에 공유 컴포넌트 여부를 판단한다 — 세 번째 반복부터가 아니라 두 번째부터 검토합니다. 좁은 화면에서 텍스트가 줄바꿈되는 문제는 대부분 whitespace-nowrap, min-w-0, flex-1 세 가지 조합으로 해결됩니다. 리팩터링 커밋은 반드시 원본 스타일(색상, 여백, 조건 분기)을 1:1로 대조하며 진행합니다 — 컴포넌트화 과정에서 미묘한 색상 차이가 생기기 쉽습니다.
관련 프로젝트
프로젝트 개요 기획자(PM)로서 AI를 활용한 업무 자동화(AX) 사례를 문서화하는 개인 포트폴리오 사이트입니다. 국내 기업의 AX 기획자/AI PM 직군으로의 커리어 전환을 목표로, 사이트 자체가 채용 지원용 스토리텔링 자료로 실사용되고 있습니다. 핵심 패턴: 업무 병목 발견 → AI로 워크플로우 재설계 → Before/After·근거·재현 가능성 문서화 전체 서사는 '실행하지 않은 아이디어 나열'이 아니라, 하나의 검증된 자동화 패턴과 도메인별 확장 블루프린트를 갖춘 재사용 가능한 엔진을 보유하는 방향으로 수렴하고 있습니다. 기술 스택 Next.js 16, Tailwind CSS v4, TypeScript Supabase (개발/운영 환경 분리), Vercel, Resend Claude API 기반 기술 자문 및 프롬프트 설계 보안 아키텍처 관리자 CRUD는 세션 기반 인증과 RLS(Row Level Security)로 보호 공개 읽기 전용 경로는 별도의 익명 클라이언트로 분리 서비스 롤 키는 애플리케이션 코드에서 완전히 배제 권한 검증은 마이그레이션 파일 및 대시보드 검토를 통해서만 진행 작업 방식 (에이전틱 IDE 협업 워크플로우) AI 에이전트 기반 IDE가 파일/버전관리 작업을 담당하고, LLM은 기술 자문 및 프롬프트 작성 역할을 수행하는 협업 구조를 운영합니다. AI 자문 → 에이전트용 프롬프트 작성 → 실행자가 붙여넣기 → 계획 확인 → 자문 검토 → 실행 승인 → 로그 검토 → 직접 클릭 테스트 → 명시적 지시 시에만 커밋 통제 규칙 실행 전 계획 검토 필수 요약 보고가 아닌 직접 클릭 테스트로 검증 개발 환경 우선 적용 후 명시적 승인 하에 운영 환경 반영 커밋은 명시적 지시가 있을 때만 수행 DB 자격증명 직접 연결 및 범위 외 삭제 금지 브랜치 전략: 개발 브랜치에서 작업 후 운영 브랜치는 배포 전용으로 직접 커밋 금지, 병합 전 변경 범위 검증 현재 진행 상황 고객사 미팅 브리핑 자동화 사례: 1단계 완료, 개발/운영 환경 배포 및 실데이터 테스트 완료 범위 변경 감지 자동화 사례: 상태 확인 진행 중 리스크 조기 경보 자동화 사례: 운영 환경 배포 완료 보안 사고 관련 포스트: 'AI 리스크 거버넌스 사례'로 재구성 예정 AI 활용 관련 콘텐츠 시리즈 초안 작성 완료, 게시 미확정 핵심 학습 원칙 보고가 아닌 검증: 버그·보안 이슈는 항상 직접 로그/브라우저 검토를 통해서만 발견되며, 에이전트의 자체 결과 요약을 그대로 신뢰하지 않음 보안 사고의 콘텐츠화: 실제 발생한 권한 관련 이슈 사례를 케이스 스터디로 재구성하여 콘텐츠화 커밋 의미 분리: 기능 단위/변경 유형별로 항상 분리 커밋 자동화하지 않는 것도 스토리: 저사용 빈도 기능을 의도적으로 고도화하지 않은 결정 자체를 AX 스토리텔링 소재로 활용