개발은 이렇게 합니다 — 빠르고 견고한 퍼블리싱·인터랙션

왜 워드프레스·웹빌더 대신 직접 코드를 짜나요?

빌더로 만들면 화면은 빨리 나옵니다. 문제는 그 화면 뒤에 안 쓰는 기능까지 따라온다는 점입니다. 슬라이더 플러그인 하나를 넣으면 거기 딸린 자바스크립트와 CSS가 통째로 실려 오고, 테마는 모든 상황에 대비한 코드를 미리 담고 있습니다. 우리 현장에서 한 번도 안 쓰는 코드가 방문자 기기에 매번 내려받아지는 셈입니다. 그러면 첫 화면이 늦게 뜨고, 모바일에서 특히 무겁습니다.

Findable 개발 파트는 현장마다 필요한 마크업과 CSS만 직접 짭니다. 버튼 하나, 메뉴 하나가 왜 그 코드인지 설명할 수 있는 상태를 유지합니다. 그래서 페이지가 가볍고, 속도·접근성·검색 신호를 우리가 통제합니다. 우리가 만든 결과물이 그 증거이고, 역량 쇼케이스에서 실제 화면과 코드 품질을 볼 수 있습니다.

이 판단을 매번 즉흥으로 내리지 않으려고, 개발 파트가 모든 페이지에 공통으로 거는 원칙을 정해 두었습니다.

이 다섯 가지가 빌드 도구 없이 바로 열리는 파일, 외부 의존성 없는 스크립트, 그리고 동작·폰트 배려를 한 번에 보장해 줍니다.

시맨틱 HTML이 화면에 안 보이는데 왜 챙기나요?

겉모양은 같아도 안쪽 구조가 다르면 기계가 읽는 결과가 달라지기 때문입니다. 똑같은 메뉴라도 의미 없는 <div>만 쌓아 만든 것과, <header>·<nav>·<main>·<article> 같은 의미 태그로 짠 것은 다릅니다. 후자는 스크린 리더가 "여기는 메뉴, 여기부터 본문"이라고 안내하며 영역을 건너뛸 수 있습니다.

검색엔진과 AI도 같은 신호를 봅니다. 어디가 제목이고 어디가 본문인지 태그로 분명해야, 검색 결과에서 정확히 요약되고 AI 답변에서 인용할 본문을 골라냅니다. 우리는 제목을 h1부터 순서대로 쓰고, 버튼은 버튼 태그로, 링크는 링크 태그로 짭니다. 보이지 않는 이 차이가 접근성·검색·AI 인용을 동시에 끌어올립니다.

반응형과 접근성은 어디까지 챙기나요?

반응형은 '화면을 줄이면 깨지지 않는다' 수준이 아니라, 휴대폰에서 읽고 누르기 편한가까지 봅니다. 글자 크기, 줄 간격, 버튼이 손가락으로 누를 만큼 큰지, 가로 스크롤이 생기지 않는지를 실제 기기 폭에서 확인합니다. 한글은 어절 단위로 줄바꿈되게 처리해 어색하게 끊기지 않도록 합니다.

접근성도 기본값으로 둡니다. 키보드만으로 메뉴와 폼을 끝까지 쓸 수 있는지, 포커스가 지금 어디 있는지 눈에 보이는지, 이미지에 대체 텍스트가 있는지, 글자와 배경의 명도 대비가 충분한지를 점검합니다. '본문 바로가기' 링크를 맨 위에 두어, 메뉴를 건너뛰고 바로 내용으로 가게 합니다. 접근성은 일부 사용자만을 위한 게 아니라, 모두에게 더 또렷한 화면을 만듭니다.

성능, 즉 코어 웹 바이탈은 어떻게 챙기나요?

코어 웹 바이탈은 구글이 보는 사용자 체감 속도 지표 세 가지입니다. 첫 화면의 큰 요소가 얼마나 빨리 뜨는지(LCP), 누른 뒤 얼마나 빨리 반응하는지(INP), 화면이 갑자기 들썩이지 않는지(CLS)입니다. 우리는 이 셋을 실제 측정해 손봅니다.

가장 큰 절약은 '안 부르는 것'에서 나옵니다. 외부 폰트와 큰 자바스크립트 라이브러리는 매번 다른 서버에서 내려받아야 해서 첫 화면을 늦춥니다. 그래서 가능하면 기기에 이미 깔린 시스템 폰트를 쓰고, 무거운 라이브러리 대신 필요한 동작만 가벼운 코드로 직접 씁니다. 이미지는 알맞은 크기·형식으로 내보내고, 자리 크기를 미리 잡아 글자나 그림이 늦게 들어와 화면이 들썩이는 현상을 줄입니다. 이런 절약은 제작 단계에서 설계에 녹일 때 가장 효과가 큽니다 — 그 이유는 제작 단계에서 최적화를 심는 이유에서 다룹니다.

제가 빌드를 마치고 가장 먼저 보는 건, 우리가 외부에 의존하지 않았다는 점이 출력으로 그대로 드러나는지입니다.

$ 외부 라이브러리: 0
$ JS 번들: 가볍게 유지(무의존)
$ Lighthouse(예시): 성능 高 · 접근성 高
$ ✓ transform/opacity만 애니메이션

의존성이 0으로 찍히면 방문자 기기가 우리 코드 외에 따로 내려받을 게 없다는 뜻이라, 첫 화면 속도를 우리가 끝까지 통제할 수 있습니다.

애니메이션은 얼마나, 어떻게 넣나요?

기준은 하나입니다. 콘텐츠를 읽는 데 도움이 되는가. 스크롤에 맞춰 요소가 부드럽게 나타나는 정도, 버튼에 손을 올렸을 때 가볍게 반응하는 정도까지입니다. 화면을 가리거나, 다 끝날 때까지 클릭을 막거나, 들어가자마자 긴 인트로가 재생되는 연출은 피합니다. 멋이 콘텐츠를 이기면 그 화면은 실패입니다.

또 하나 꼭 챙기는 것이 '동작 줄이기(reduced-motion)' 배려입니다. 움직임에 어지러움을 느끼는 분들은 기기 설정에서 이 옵션을 켭니다. 우리는 그 설정을 감지해, 켜져 있으면 애니메이션을 자동으로 끄거나 최소화합니다. 같은 페이지라도 어떤 사람에게는 차분한 화면으로 보이는 것 — 인터랙션을 '넣는 것'만큼 '거두는 것'도 설계에 넣습니다. 이런 인터랙션 판단은 디자인 파트와 함께 정하며, 그 과정은 UI는 이렇게 만듭니다에서 설명합니다.

구조화 데이터를 왜 처음부터 코드에 넣나요?

구조화 데이터(JSON-LD)는 사람 눈엔 안 보이지만, 기계에게 "이 회사는 무엇을 하고, 이 페이지의 FAQ는 이렇다"라고 알려 주는 표시입니다. 이게 정확하면 검색 결과에 별점·FAQ 같은 리치 요소가 붙고, AI가 답을 만들 때 인용 후보로 더 잘 들어갑니다.

문제는 넣는 시점입니다. 사이트를 다 만든 뒤 플러그인으로 덧붙이면, 표시한 내용과 화면 본문이 어긋나기 쉽고 검증에서 오류가 납니다. 우리는 본문을 짤 때 같은 자리에서 구조화 데이터도 함께 넣어, 화면과 표시가 항상 일치하게 합니다. 이 글에도 글·이동경로·FAQ 세 종류의 구조화 데이터가 코드에 들어 있고, 검증 도구를 통과하도록 작성했습니다. 검색·AI 노출 관점의 전체 그림은 SEO 검색 최적화에서 정리했습니다.

말로만 설명하면 와닿지 않으니, 우리가 페이지 머리에 실제로 심는 JSON-LD가 어떤 모양인지 그대로 보여 드립니다.

<script type="application/ld+json">
{ "@context":"https://schema.org","@type":"Organization",
  "name":"Findable","url":"https://find-ables.com/" }
</script>

이 블록을 본문과 같은 파일·같은 커밋에서 짜기 때문에, 회사명이나 주소가 바뀌어도 화면과 표시가 따로 놀지 않습니다.

한눈에, 무거운 빌더와 가벼운 코드는 무엇이 다른가요?

둘 다 화면은 만들어 냅니다. 갈리는 지점은 방문자가 실제로 겪는 속도, 모두가 쓸 수 있는지, 그리고 나중에 고치기 쉬운지입니다.

Findable은 디자인·개발·콘텐츠·GEO/SEO를 한 팀에서 진행하는 중소기업 전문 웹 에이전시입니다. 개발 파트가 만든 화면을 직접 보고 싶다면 역량 쇼케이스를, 지금 사이트가 얼마나 빠르고 견고한지 궁금하다면 무료 진단으로 시작하시면 됩니다.