홈페이지리뉴얼 메뉴 개편, 드롭다운 5개를 4개로 줄이고 남은 것

홈페이지리뉴얼 전, 메뉴는 왜 방문자에게 어려웠나

메뉴가 어려웠던 이유는 항목 수보다 분류의 기준에 있었습니다. 2026년 7월 2일 기준으로 저희 회사 홈페이지 첫 화면은 “기술컨설팅”과 “데이터”라는 두 사업부(원래 화면 문구는 Two divisions)를 나란히 세우고, 그 아래에서 서비스 카드 링크가 한 갈래로만 이어지는 구조였습니다. 당시 결정 기록은 이 상태를 이렇게 적었습니다.

방문자가 SGK Studio의 전체 서비스 포트폴리오를 한눈에 파악하기 어려웠다.

상단 헤더도 같은 문제를 안고 있었습니다. 드롭다운 메뉴가 5개였고, 그중 하나가 “미디어”였습니다. 미디어 라인은 사실상 중단 상태였는데도 상단 한 칸을 그대로 차지하고 있었습니다. 방문자 입장에서 보면 다섯 갈래 중 한 갈래는 들어가도 새 소식이 없는 길이었습니다.

이 상태의 비용은 눈에 띄는 오류로 드러나지 않습니다. 페이지는 열리고 링크도 살아 있습니다. 다만 처음 온 사람이 '이 회사는 무엇을 해 주는 곳인가'를 메뉴에서 읽어 내려면, 사업부라는 내부 구분을 먼저 이해해야 했습니다. 중소기업 대표가 홈페이지 제작을 맡길 곳을 찾을 때 그 사람에게 사업부 구분은 필요 없는 정보입니다. 이 글은 그 구조를 어떻게 다시 짰고, 무엇을 쟀고, 어떤 안을 버렸는지 순서대로 적은 기록입니다.

처음 잰 숫자: 드롭다운 5개, 사업부 2개, 카드 한 갈래

출발점에서 손에 쥔 숫자는 많지 않았습니다. 상단 드롭다운 5개, 첫 화면의 사업부 블록 2개, 그리고 서비스로 들어가는 카드 링크 한 갈래입니다. 5개 드롭다운 가운데 1곳(미디어)은 운영이 멈춘 상태였습니다.

측정 방법은 단순했습니다. 방문자 행동 데이터를 모은 것이 아니라, 헤더(SiteHeader)·푸터(SiteFooter)·첫 화면(page.tsx)·사이트맵(sitemap.ts) 소스 파일을 열어 메뉴 항목과 링크를 직접 셌습니다. 공통 상수 파일(studio.ts)에는 미디어용 상수(MEDIA)가 따로 있었고, 사이트맵에도 /media 주소가 들어 있었습니다. 즉 멈춘 라인 하나가 헤더·푸터·상수·사이트맵 네 곳에 흩어져 있었습니다.

여기서 하나 짚어 둘 점이 있습니다. 이 단계에는 '방문자가 메뉴에서 몇 번 헤맸는가' 같은 행동 수치가 없습니다. 출발점의 숫자는 전부 구조를 센 값입니다. 그래서 이 글의 전후 비교도 구조 수치의 비교이고, 전환율 같은 결과 지표는 이 기록에 들어 있지 않습니다. 이 한계는 마지막 절에서 다시 다룹니다.

세운 가설: 서비스 카드만 더 붙이면 풀린다

첫 가설은 가장 손이 덜 가는 쪽이었습니다. 사업부 2개 구조는 그대로 두고, 첫 화면에 서비스 카드만 추가하면 '무엇을 파는지'가 보일 것이라는 생각입니다. 카드가 한 갈래뿐이라 서비스가 안 보이는 것이니, 카드를 늘리면 해결된다는 논리였습니다.

둘째 가설은 미디어 라인에 관한 것이었습니다. 멈춘 라인이니 페이지와 링크를 완전히 지우면 메뉴가 깔끔해진다는 안입니다. 흔적이 남지 않으니 가장 단정해 보였습니다.

셋째 가설은 새로 만들 소프트웨어 카탈로그의 위치였습니다. 서비스 목록을 따로 두지 말고 첫 화면에 통째로 넣으면, 방문자가 한 페이지에서 전부 볼 수 있다는 생각입니다.

• 가설 1: 사업부 2개 유지 + 서비스 카드만 추가
• 가설 2: 멈춘 미디어 라인을 완전 삭제
• 가설 3: 소프트웨어 카탈로그를 첫 화면에 통합

세 가설은 모두 '지금 구조에 무언가를 더하거나 빼면 된다'는 공통 전제 위에 있었습니다. 분류 기준 자체를 바꾸는 안은 이 목록에 처음부터 들어 있지 않았습니다.

가설은 어디서 틀렸나?

첫 가설은 화면을 그려 보는 단계에서 무너졌습니다. 사업부 블록 2개를 남긴 채 서비스 카드를 붙이면, 같은 서비스가 '사업부 아래의 항목'과 '서비스 카드'라는 두 경로로 동시에 보입니다. 결정 기록은 이 안을 이렇게 기각했습니다.

Two divisions 유지 + 서비스 카드만 추가(기각: 중복 구조, 방문자 혼란).

카드를 늘릴수록 오히려 '어느 쪽으로 들어가야 하나'라는 질문이 하나 더 생겼습니다. 항목 수의 문제가 아니라 두 분류가 겹친다는 문제였기 때문에, 더하기로는 풀리지 않았습니다.

둘째 가설도 틀렸습니다. 미디어 라인을 완전히 지우면 메뉴는 깔끔해지지만, 나중에 그 라인을 다시 열 때 처음부터 만들어야 합니다. 결정 기록은 '재개 가능성 보존, noindex가 안전'이라는 이유로 완전 삭제를 기각했습니다. 지우는 대신 페이지는 남기고 검색 노출만 끊는 쪽을 골랐습니다.

이 판단에는 저희 쪽 사정도 들어 있습니다. 홈페이지 제작을 의뢰하는 고객 입장에서는 미디어가 멈췄는지 아닌지가 중요하지 않지만, 저희에게는 다시 열 수 있는 선택지가 남아 있는 편이 낫습니다. 완전 삭제는 되돌리기 어렵고, 검색 제외는 표시 하나만 풀면 원래대로 돌아옵니다. 되돌리기 쉬운 쪽을 먼저 고른 셈입니다.

셋째 가설은 페이지의 역할을 섞는 안이었습니다. 첫 화면은 처음 온 사람을 맞는 랜딩이고, 소프트웨어 카탈로그는 이미 관심이 생긴 사람이 세부를 보는 곳입니다. 둘을 합치면 첫 화면이 길어지고 카탈로그는 첫 화면의 일부로 묻힙니다. 결정 기록의 표현으로는 '메인은 랜딩, software는 상세 카탈로그로 분리가 깔끔'이었습니다.

진짜 원인은 무엇이었나: 메뉴가 조직도를 따르고 있었다

세 가설을 버리고 나서야 공통 원인이 보였습니다. 메뉴의 분류 축이 '방문자가 무엇을 살 수 있는가'가 아니라 '회사 안에서 일이 어떻게 나뉘어 있는가'였습니다. 사업부 2개는 내부 구분이고, 미디어 칸은 내부에서 멈춘 일을 그대로 반영한 자리였습니다.

이 원인을 받아들이면 해법의 모양이 달라집니다. 카드를 더하는 것도, 멈춘 칸을 지우는 것도 아니라 분류 기준을 판매 항목으로 바꾸는 일입니다. 결정 기록이 결과로 적은 새 분류 체계는 Software + Services + Data + Studio, 네 축이었습니다.

또 하나의 원인은 멈춘 라인이 네 곳에 흩어져 있었다는 점입니다. 헤더·푸터·상수·사이트맵이 각자 미디어를 알고 있었기 때문에, 한 곳만 고치면 나머지 세 곳에 흔적이 남습니다. 그래서 조치는 메뉴 한 줄을 지우는 데서 끝나지 않고 일곱 갈래로 나뉘었습니다.

조치: 일곱 군데를 한 번에 고쳤다

2026년 7월 2일에 실행한 조치는 7건입니다. 결정 기록의 번호를 그대로 옮깁니다.

눈여겨볼 조합은 6번과 7번입니다. 미디어 페이지 자체는 남겨 두고 검색엔진에 '이 페이지는 색인하지 말라'는 noindex 표시를 붙였습니다. 동시에 사이트맵에서 /media 주소를 뺐습니다. 사이트맵은 검색엔진에 '이 주소들을 봐 달라'고 내미는 목록이라, 색인 제외 페이지를 거기 남겨 두면 두 신호가 서로 어긋납니다.

페이지를 지우지 않은 덕에, 예전 /media 주소로 들어온 방문자는 '페이지를 찾을 수 없음'(404) 대신 '준비 중' 문구를 봅니다. 코드도 그대로 남아 있어 라인을 다시 열 때 noindex를 풀고 메뉴에 한 칸을 되돌리면 복구할 수 있습니다.

5번 조치는 겉으로 보이지 않지만 빠뜨리면 안 되는 단계였습니다. 공통 상수 파일에 MEDIA 상수가 남아 있으면, 나중에 누가 새 페이지를 만들면서 그 상수를 다시 불러 메뉴에 미디어를 되살릴 수 있습니다. 화면에서 지운 항목은 그 항목을 공급하던 상수까지 지워야 실제로 사라집니다. 반대로 미디어 페이지 파일 자체는 남겼기 때문에, 상수와 페이지가 서로 다른 운명을 맞은 셈입니다.

첫 화면의 서비스 카드는 6개로 다시 짰습니다. 기존의 'Previous works' 카드를 빼고, 사업부라는 중간 단계 없이 서비스로 바로 들어가는 카드만 남겼습니다. 상세 목록은 4번에서 새로 만든 소프트웨어 카탈로그 페이지가 맡습니다.

재측정 결과: 드롭다운 4개, 830페이지 9.3초 빌드

조치 후 같은 파일들을 다시 열어 셌습니다. 상단 드롭다운은 4개(소프트웨어·서비스·데이터·스튜디오)로 줄었고, 첫 화면의 사업부 블록 2개는 사라졌으며, 그 자리에 서비스 카드 6개가 들어섰습니다. 푸터에서는 미디어 컬럼이 빠지고 서비스 컬럼이 생겼습니다. 사이트맵에는 /media가 없습니다.

구조를 크게 흔든 변경이라 빌드가 깨지지 않는지도 봤습니다. 운영 배포 빌드 로그 기준으로 9.3초 동안 830페이지를 생성했고, www.sgkstudio.co.kr 운영 사이트에 반영한 것까지 확인했습니다. 사이트맵에서 주소 하나를 뺀 변경이 다른 페이지 생성에 영향을 주지 않았다는 확인이기도 합니다.

재측정은 처음과 같은 방법으로 했습니다. 방문자 데이터를 새로 모으지 않고, 개편 전에 열었던 헤더·푸터·첫 화면·공통 상수·사이트맵 다섯 파일을 다시 열어 같은 항목을 셌습니다. 측정 방법을 바꾸지 않아야 5개에서 4개라는 차이가 측정 방식의 차이가 아니라 구조의 차이라고 말할 수 있습니다. 빌드 시간과 페이지 수는 여기에 더한 값이고, 개편 전 빌드 수치는 기록에 남아 있지 않아 표에서 빈칸으로 두었습니다.

재측정이 말해 주는 것은 '의도한 구조로 바뀌었고 사이트가 정상으로 빌드된다'까지입니다. 방문자가 더 빨리 원하는 서비스를 찾았는지는 이 숫자로 알 수 없습니다. 같은 홈페이지에서 중복 페이지를 합친 다른 기록은 홈페이지 중복 페이지 정리기에 따로 적었습니다.

메뉴를 줄인 뒤 무엇이 더 드러났나?

메뉴 개편 뒤에도 같은 계열의 문제가 몇 차례 더 나왔습니다. 공통점은 '화면에서 빠졌다고 코드에서도 빠진 것은 아니다'였습니다.

2026년 7월 18일에는 AI 서비스 서브도메인(ai.sgkstudio.co.kr)의 주요 문의 버튼이 상대경로 "/contact"를 가리키는데, 정작 그 서브도메인에는 /contact 페이지가 없어 404가 나던 것을 발견했습니다. 커밋 이력을 거슬러 올라가 보니 4일 전 첫 커밋부터 있던 결함이었습니다. 새 문의 페이지를 하나 더 만드는 대신, 이미 운영 중인 www.sgkstudio.co.kr/contact 문의폼을 절대경로로 가리키도록 문의 주소 상수를 한 곳으로 모았습니다. 하드코딩 2곳도 같은 상수를 쓰도록 정리했습니다.

이 방식을 고른 근거는 측정 쪽에 있었습니다. 구글 애널리틱스(GA4)의 도메인 간 추적 설정에 www와 ai 두 도메인이 이미 함께 등록돼 있어서, 방문자가 서브도메인에서 www 문의폼으로 넘어가도 어느 경로로 왔는지가 끊기지 않았습니다. 같은 폼을 서브도메인마다 따로 만들면 고칠 곳이 늘고 추적 설정도 다시 짜야 했습니다. 메뉴 개편 커밋의 제목이 '서브도메인 통일 기반'이었던 것도 이런 연결을 염두에 둔 표현이었습니다.

그보다 앞선 2026년 6월 21일에는 정반대 판단을 내린 적이 있습니다. 이메일을 남기면 기업 5곳 샘플을 주고 20곳을 메일로 보내 주던 무료 도구가, 21,961곳을 바로 열람하는 무료 데이터 콘솔과 메시지가 부딪혔습니다. 그때는 noindex만 거는 안을 '코드 부채 유지'라는 이유로 기각하고 페이지·API·관련 코드를 모두 지웠습니다.

두 판단은 모순이 아닙니다. 다시 열 가능성이 있는 라인은 남기고, 핵심 메시지와 부딪히는 기능은 지웠습니다. 다만 '남긴다'를 고르면 그 코드는 계속 관리 대상으로 남는다는 비용을 함께 받아들인 셈입니다.

남는 한계는 무엇인가

첫째, 결과 지표가 없습니다. 이 개편의 전후 수치는 드롭다운 5개에서 4개, 사업부 블록 2개에서 0개 같은 구조 값과 빌드 9.3초·830페이지뿐입니다. 메뉴가 쉬워졌다는 판단은 구조를 보고 내린 것이고, 방문자의 클릭 경로나 문의 전환으로 확인한 것이 아닙니다. 이 점을 숨기면 개선율만 쓰고 절대값을 감추는 글과 다를 바가 없습니다.

둘째, 결정 기록이 스스로 적은 단점이 있습니다. 사업부 블록 2개를 없애면서 기술컨설팅과 데이터의 구분이 헤더에 직접 드러나지 않게 바뀌었습니다. 그 구분은 이제 '서비스'와 '데이터' 두 드롭다운에 흩어져 있습니다. 두 사업의 차이를 먼저 알고 싶은 방문자에게는 오히려 한 단계가 늘었을 수 있습니다.

셋째, 화면 정리와 코드 정리는 속도가 다릅니다. 이후 쓰지 않는 랜딩 컴포넌트를 세 번에 나눠 지웠는데, 한 번에 3개·4개·3개씩이었습니다(사전 결제 안내·대기 신청 폼·피드백 위젯, 체험 추적기·안내 팝업·결제창·로딩 뼈대, 하단 표기·사업자 푸터·앱 레이아웃). 사이트맵도 뒤에 다시 손봤습니다. 모든 글의 수정 시각이 빌드 시각으로 찍혀 '무엇이 새 글인지' 검색엔진에 알려 주지 못하던 문제를 따로 고쳤습니다.

넷째, 디자인은 이 구조 위에서 다시 바뀌었습니다. 2026년 7월 30일에는 회색 13단계 팔레트와 파란색 #3279f9 하나로 색 체계를 전면 교체하면서 page.tsx 22개와 컴포넌트 8개를 손봤고, 옛 색 변수 참조 2,059건을 바꿨습니다. 메뉴의 네 축은 그대로 유지했지만, 같은 시기에 6개 서브도메인은 새 디자인을 아직 받지 못한 상태로 남았습니다.

이 디자인 교체에서도 메뉴 개편과 닮은 규칙이 하나 생겼습니다. 파란색 #3279f9는 텍스트 링크와 아이콘 링크에만 쓰고, 문의 버튼은 짙은 회색으로 통일했습니다. 결정 기록은 파란색을 어디에나 쓰던 이전 상태를 두고 '디자인 전문성 훼손'이라고 적었고, 참고한 디자인 시스템의 원칙도 브랜드 파란색을 링크에만 쓰는 것이었습니다. 메뉴에서 분류 축을 하나로 정리한 것처럼, 색에도 역할을 하나씩만 맡긴 결정입니다.

우리 회사 홈페이지리뉴얼에 옮긴다면 어떻게 하나?

이 기록에서 다른 회사 홈페이지리뉴얼에 그대로 옮길 수 있는 순서는 세 단계입니다. 먼저 메뉴 항목을 '방문자가 살 수 있는 것' 기준으로 다시 적어 봅니다. 그 목록과 지금 메뉴가 다르면, 카드를 더 붙이기 전에 분류 축부터 바꿉니다.

• 메뉴 항목을 판매 항목 기준으로 다시 적고, 회사 조직 구분은 메뉴에서 뺀다
• 멈춘 라인은 다시 열 가능성이 있으면 noindex + 안내 문구로, 핵심 메시지와 부딪히면 완전 삭제로
• 헤더·푸터·공통 상수·사이트맵을 한꺼번에 고치고, 빌드 페이지 수로 깨지지 않았는지 확인한다

마지막으로, 바꾼 뒤에 무엇을 잴지를 미리 정해 둡니다. 저희는 이번 개편에서 구조 수치만 남겼고, 그래서 '나아졌다'를 방문자 데이터로 말하지 못합니다. 메뉴를 바꾸기 전 일주일의 메뉴 클릭과 문의 수를 적어 두면, 바꾼 뒤 같은 기간과 견줄 수 있습니다.

이 결정 기록 바로 아래에는 다른 SaaS 랜딩 화면을 분석해 첫 화면 요소 4가지(브라우저 틀 안의 데모 영상·캔버스 파티클 배경·로고 흐름 띠·간결한 문의 버튼) 중 3가지를 재사용 부품으로 떼어 낸 항목도 붙어 있습니다. 3개 프로젝트에서 같은 코드를 1곳에서 관리하려는 목적이었고, 강제로 끼워 넣지 않고 필요한 페이지만 골라 쓰도록 두었습니다. 회사 홈페이지 구조를 어디서부터 손댈지 막막하다면 상담에서 지금 메뉴를 같이 세어 보는 것부터 시작할 수 있습니다.

작성: SGK 스튜디오 개발 기록. 이 글의 수치는 2026년 7월 2일 홈페이지 개편 결정 기록과 운영 배포 빌드 로그, 이후 커밋 이력에서 옮겼습니다.