웹 표준과 웹 접근성 그리고 검색 엔진 최적화(SEO)

Novelike·2025년 4월 30일

Tech

목록 보기

4/8

시작하기에 앞서 본 포스트의 자료 조사는 ChatGPT 4.5의 심층 리서치 기능을 활용하였음을 밝힌다.

웹 표준 (Web Standards)

정의 및 목적: 웹 표준은 HTML, CSS, JavaScript 등 웹 개발에 사용되는 기술에 대한 공식적인 규격과 규칙을 뜻한다. W3C(World Wide Web Consortium) 등 국제 표준화 기구에서 권고한 이 표준을 따르면, 어떤 운영체제나 브라우저에서도 일관된 화면 출력과 기능 동작이 보장된다 (웹표준) (Web Standards | W3C). 이를 통해 개발자는 코드 재사용성 및 유지보수를 높이고, 사용자는 다양한 기기·브라우저에서 안정적인 웹 경험을 할 수 있다. 웹 표준 준수는 상호운용성(interoperability), 보안, 개인정보 보호, 국제화, 접근성 등을 최우선 가치로 두며, 개방형(Web) 플랫폼 구축을 목표로 한다 (Web Standards | W3C).

기술 스펙 및 권고안: 웹 표준의 대표적인 기술로는 HTML5, CSS3, ECMAScript(자바스크립트) 등이 있으며, 이들은 모두 W3C 권고(Recommendation)로 제정되어 있다 (Web Standards | W3C) (웹표준). 또한 문서의 의미를 풍부히 하는 시맨틱 태그(Semantic Tag ¦ <header>, <nav>, <main>, <footer> 등)와 ARIA(Web Accessibility Initiative – Accessible Rich Internet Applications)와 같은 접근성 보조 기술도 웹 표준의 일환이다. 주요 권고안으로는 HTML Living Standard(WHATWG), W3C HTML5/HTML Living Standard, CSS 스펙, WCAG(Web Content Accessibility Guidelines) 등이 있으며, 이와 더불어 웹 성능, 보안 관련 권고(예: CORS, HTTPS 권장)도 포함된다. 브라우저는 최신 버전을 통해 이러한 표준을 지원하며, 웹 표준을 따르면 크로스브라우징 이슈가 감소한다 (웹표준).

실무 적용 및 체크리스트:

유효성 검사: W3C Validator 등을 사용하여 HTML/CSS 문서가 표준에 맞는지 검증한다.
시맨틱 마크업: 콘텐츠에 맞는 HTML5 시맨틱 태그(<article>, <section>, <ul> 등)를 사용해 구조를 명확히 한다 (알아두면 쓸모 있는 '시맨틱 마크업' 개념 정리 | 요즘IT) (웹표준).
레이아웃·스타일 분리: HTML은 구조/내용만, CSS는 레이아웃·스타일만을 담당하도록 분리한다. 이를 통해 코드 경량화 및 유지보수를 용이하게 한다 (웹표준).
크로스브라우징: 다양한 브라우저(Chrome, Firefox, Safari 등) 및 기기(PC, 모바일)에서 일관된 UI/UX를 제공하는지 확인한다 (웹표준) (KISA 한국인터넷진흥원).
표준 문서 인코딩: <meta charset="utf-8"> 등으로 문자 인코딩을 명시하고, <html lang> 속성으로 언어를 지정하여 국제화를 지원한다.

백엔드/서버 관점 구현 요소:

HTTP 응답 헤더: Content-Type: text/html; charset=utf-8 등 올바른 헤더로 인코딩을 선언한다. X-Robots-Tag 헤더를 이용하여 검색 엔진 색인 규칙을 지정할 수 있다 (X-Robots-Tag - HTTP | MDN).
404/301 처리: 올바른 HTTP 상태 코드를 반환(예: 리소스 없음은 404, 영구 이동은 301)하여 SEO 및 사용자 경험을 관리한다 (테크니컬 SEO 필수 요소, HTTP 상태 코드!). 301 리디렉트는 구글에서 페이지 랭크와 링크 점수를 새 URL로 전달하는 데 사용된다 (테크니컬 SEO 필수 요소, HTTP 상태 코드!).
메타 태그 관리: <title>과 <meta name="description">을 백엔드에서 동적으로 생성해 페이지별로 고유하게 지정한다. 메타 설명은 검색 결과의 스니펫으로 활용되므로 간결하고 흥미를 유발하도록 작성한다 (메타 설명 작성 방법 | Google 검색 센터 | Documentation | Google for Developers).
시맨틱 마크업 생성: 템플릿 엔진이나 서버 렌더링 시, 시맨틱한 HTML 구조를 유지한다. 예를 들어 게시글의 제목은 <h1>, 목차는 <nav><ul><li>로 마크업한다 (알아두면 쓸모 있는 '시맨틱 마크업' 개념 정리 | 요즘IT).
사이트맵/XML 및 robots.txt: 서버에서 자동 생성되는 sitemap.xml과 robots.txt를 활용하여 검색 엔진에 크롤링할 페이지와 색인 우선순위를 안내한다. robots.txt는 접근 금지할 URL을 명시하여 크롤러의 자원 낭비를 줄인다 (robots.txt - Search Console 도움말).

실제 사례:

공공기관 웹사이트: 한국인터넷진흥원(KISA) 사이트는 웹 표준과 웹 접근성을 준수하여 제작되었다고 명시하고 있으며, KWCAG 2.0 지침에 따라 장애인·고령자도 불편함 없이 이용할 수 있도록 구조화했다 (KISA 한국인터넷진흥원) (KISA 한국인터넷진흥원). 이처럼 공공기관 사이트는 법률(국가정보화기본법 등)에 따라 접근성이 의무화되어 있으므로 WCAG/KWCAG 준수와 크로스브라우징, 반응형 디자인을 필수 적용한다 (KISA 한국인터넷진흥원).
전자상거래 사이트: 쇼핑몰은 검색 유입이 매출에 직접 영향이 크므로 SEO 최적화(키워드 기반 타이틀, 서술형 URL, 구조화된 데이터)와 빠른 페이지 로딩, 신뢰성 있는 보안(HTTPS) 구현이 중요하다. 또한 이미지를 많이 쓰는 만큼 alt 텍스트로 상품 정보를 제공해 이미지 검색 최적화에도 신경쓴다.
블로그/콘텐츠 사이트: 개인 블로그나 뉴스 매체는 콘텐츠 품질과 시맨틱 마크업(제목 태그, 게시 일자 태그 등)을 통해 검색 노출을 극대화한다. 예를 들어 블로그 CMS에서 <h1> 태그를 게시글 제목으로 자동 배치하고, <article>로 글 영역을 감싸 SEO와 접근성을 동시에 고려한다.

웹 접근성 (Web Accessibility)

정의 및 목적: 웹 접근성은 장애인, 고령자, 임시 장애자 등 모든 사용자가 웹 사이트의 정보와 기능을 동등하게 이용할 수 있도록 보장하는 개념이다 (웹 접근성(WAI)과 시맨틱 웹의 중요성) (KISA 한국인터넷진흥원). 즉, 시각 장애인, 청각 장애인은 물론 손상된 모빌리티를 가진 사람들도 키보드나 보조기기를 통해 불편 없이 웹 콘텐츠를 이용할 수 있도록 하는 것을 말한다. 웹 접근성 향상은 정보 접근의 평등을 보장하고 법적 의무를 충족시키며 더 넓은 사용자 기반을 확보하는 데 필수적이다 (웹 접근성(WAI)과 시맨틱 웹의 중요성).

기술 스펙 및 권고안: 접근성 표준으로는 WCAG(Web Content Accessibility Guidelines) 2.x(현재 최신 WCAG 2.2, 2023년 10월 제정)와 한국형 WCAG(KWCAG)가 있다 ( WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C) (KISA 한국인터넷진흥원). WCAG는 인지성, 운영성, 이해성, 견고성의 4원칙(POUR)을 기반으로 구성되며, Level A/AA/AAA 성공기준을 갖는다 ( WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C) ( WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C). 또한 WAI-ARIA는 자바스크립트로 구현된 인터랙티브 위젯 등에 접근성을 부여하기 위한 역할(role)·속성 집합이다 (ARIA - Accessibility | MDN). 이밖에 시맨틱 HTML5 태그, 동영상 자막, 고대비 색상, 키보드 내비게이션, 폼 레이블 등이 접근성 구현을 위한 권고 요소다.

실무 적용 및 체크리스트:

대체 텍스트 제공: 이미지·그래픽에는 alt 속성으로 내용을 설명한다 (KISA 한국인터넷진흥원). 아이콘이나 레이아웃용 이미지가 아니라면 의미 있는 텍스트를 반드시 포함해야 한다.
키보드 접근성: 모든 기능(링크, 버튼, 입력 폼 등)이 탭 키 등으로 조작 가능해야 한다. :focus 스타일을 적용해 포커스 이동이 시각적으로 명확하게 보이도록 한다 (KISA 한국인터넷진흥원). 스킵 내비게이션(skip nav)을 제공하면 반복 영역을 건너뛸 수 있다 (KISA 한국인터넷진흥원).
색상 대비: 텍스트와 배경의 명도 대비를 WCAG 권고 수준(일반 텍스트 4.5:1 이상)으로 맞춘다 (KISA 한국인터넷진흥원). 시각 장애인을 위해 색상이 아닌 텍스트나 아이콘으로 정보를 구분한다.
문서 구조화: <h1>~<h6>을 적절한 계층으로 사용하고, 리스트(<ul><li>, <ol><li>), <table> 등 의미 태그를 올바르게 쓴다. 화면 리더가 내용을 쉽게 해석하도록 HTML이 시맨틱하게 작성되어야 한다 (알아두면 쓸모 있는 '시맨틱 마크업' 개념 정리 | 요즘IT) (KISA 한국인터넷진흥원).
폼 접근성: <label>을 이용해 입력 필드와 설명을 연결한다. aria-live 등을 사용해 동적으로 변경되는 콘텐츠(실시간 채팅 등)를 안내한다. 에러 메시지나 가이드 문구도 시각 이외의 방법으로 제공한다.

백엔드/서버 관점 구현 요소:

콘텐츠 관리: CMS나 서버에서 게시글, 상품 이미지 등의 텍스트 정보를 입력할 때, alt 텍스트, 제목 태그, ARIA 속성 등을 포함할 수 있도록 필드를 설계한다. 예를 들어 상품 이미지 업로드 시 대체 텍스트 입력란을 마련해 비즈니스 로직에서 빠뜨리지 않고 저장하도록 한다.
다국어·인코딩 지원: <html lang> 속성이나 Content-Language 헤더로 페이지 언어를 명시한다. 한국어 사이트라면 lang="ko", 다국어라면 언어 코드에 따라 페이지를 생성하도록 한다.
접근성 폴리필/라이브러리: 서버 사이드 렌더링 시 ARIA 속성이나 WAI-ARIA Landmark(역할, 역할 트리) 등을 넣어주고, 필요하면 자동 변환 스크립트(e.g. 이미지 대체 텍스트 자동 삽입 플러그인)를 사용한다.
동영상 자막 및 대체 콘텐츠: 서버에 저장된 동영상에는 SRT나 VTT 자막 파일을 제공하고, 브라우저 지원이 없으면 <track> 태그로 삽입한다. 오디오 콘텐츠에는 텍스트 스크립트를 함께 제공한다.
접근성 테스트 자동화: CI/CD 파이프라인에서 WAVE, axe 같은 도구를 돌려 접근성 오류를 자동 검출하게 할 수 있다. 접근성 규격 미준수 상황이 발생하면 배포를 중단하도록 설정할 수 있다.

실제 사례:

공공기관: 앞서 언급한 KISA 사례처럼, 정부·지자체 사이트는 웹 접근성 인증 마크 획득 및 KWCAG 준수를 의무적으로 시행한다. 금융권 및 공공 서비스(교통, 의료)도 ‘웹 접근성 품질인증마크’ 등을 취득해 장애인 이용 편의를 높인다.
전자상거래: 해외 아마존·이베이 등과 달리 국내 쇼핑몰은 접근성 이슈가 상대적으로 적지만, 점점 모바일 사용이 늘어나면서 키보드 외 터치 접근성(핸드폰 단말 접근)에도 유의해야 한다. 상품 페이지와 네비게이션이 분리된 레이어로 제공되어야 스크린 리더가 메뉴를 건너뛰게 된다.
블로그/미디어: 매체 사이트는 인용, 표, 동영상 등 복합 콘텐츠 접근성을 위해 ARIA 속성과 자막을 적극 활용한다. 예를 들어, 뉴미디어 포털은 동영상 콘텐츠에 영어 자막을 제공하며, 그래프나 차트에는 설명 텍스트를 추가해 비장애인도 이해할 수 있도록 한다.

검색 엔진 최적화(SEO)

정의 및 목적: SEO는 “Search Engine Optimization(검색 엔진 최적화)”의 약자로, 검색 엔진이 웹사이트의 콘텐츠를 잘 이해하도록 돕고 사용자가 검색 시 해당 사이트를 찾도록 최적화하는 활동을 말한다 (SEO 기본 가이드: 기본사항 | Google 검색 센터 | Documentation | Google for Developers). 즉, 검색 결과에서 상위에 노출되어 방문자를 늘리는 것이 목표다. 구글 검색 센터는 “사용자가 콘텐츠를 발견하게 해주는 검색 엔진도 사용자의 일종”이라며, SEO를 통해 검색 엔진이 사이트를 크롤링·색인·이해하기 쉽게 만드는 것이라 정의한다 (SEO 기본 가이드: 기본사항 | Google 검색 센터 | Documentation | Google for Developers).

기술 스펙 및 권고안: 구글 등의 검색 엔진은 크롤링(crawling), 색인(indexing), 랭킹(ranking) 과정을 거쳐 결과를 보여준다. 이를 지원하는 기술로는 robots.txt, sitemap.xml, 메타 태그(robots, canonical), 구조화된 데이터(Schema.org JSON-LD), 모바일 친화성(Responsive Design, 모바일 프렌들리) 등이 있다. 구글은 검색 센터 문서에서 “사이트가 Google 색인에 추가된다는 보장은 없으나, 크롤링·색인·이해하기 쉽도록 권장사항을 따르면 검색결과 노출 가능성이 높아진다”라고 강조한다 (SEO 기본 가이드: 기본사항 | Google 검색 센터 | Documentation | Google for Developers). 또한, 모바일 우선 색인화(Mobile-first indexing), 코어 웹 바이탈(Core Web Vitals)과 같은 사용자 경험 신호도 순위 요소로 작용하므로, 사이트 성능과 모바일 최적화도 반드시 챙겨야 한다 (Understanding Core Web Vitals and Google search results | Google Search Central | Documentation | Google for Developers).

실무 적용 및 체크리스트:

콘텐츠 최적화: <title> 태그와 <meta name="description">에 페이지 핵심 키워드를 포함하고, 길이(제목 ~60자, 설명 ~160자)를 권장범위 내로 유지한다 (메타 설명 작성 방법 | Google 검색 센터 | Documentation | Google for Developers). 본문에는 <h1> 등 제목 태그와 <strong> 등을 사용해 강조 키워드를 표시한다.
URL 구조: 사람이 읽기 쉽고 키워드가 드러나는 URL을 사용한다(e.g. /products/blue-widget). 필요시 서버에서 301 리디렉트를 활용해 URL 변경을 관리한다.
크롤링 제어: robots.txt로 비공개 페이지 또는 자원(예: 서드파티 스크립트, 폰트 등)을 차단하고, 필요시 <meta name="robots"> 또는 HTTP 헤더 X-Robots-Tag로 검색 엔진 색인 여부를 제어한다 (robots.txt - Search Console 도움말) (X-Robots-Tag - HTTP | MDN).
사이트맵: 모든 주요 페이지를 수집한 XML 사이트맵을 생성하여 검색 엔진에 제출한다. 신규 콘텐츠가 생길 때마다 업데이트하도록 자동화한다.
구조화된 데이터: 상품, 리뷰, 행사 등의 정보를 Schema.org 태그(JSON-LD)로 마크업하여 리치 스니펫 노출을 유도한다. Google Search Console의 구조화된 데이터 보고서를 이용해 오류를 점검한다.
속도 및 모바일 최적화: 이미지 최적화, 캐시 설정, 서버 압축 등을 통해 페이지 로딩 속도를 개선한다. Responsive Design 또는 Mobile-First 구현으로 다양한 화면에 대응한다. 이런 페이지 경험 요소들은 Core Web Vitals로 측정되며, 구글도 좋은 Core Web Vitals 성적을 추천한다고 밝힌다 (Understanding Core Web Vitals and Google search results | Google Search Central | Documentation | Google for Developers).

백엔드/서버 관점 구현 요소:

HTTP 상태 코드 관리: 페이지 이동 시 301/302 리디렉트, 없는 페이지는 404/410 처리 등을 통해 검색 엔진에 상황을 명확히 전달한다. 예를 들어 301은 기존 페이지의 SEO 점수를 새 주소로 넘겨준다 (테크니컬 SEO 필수 요소, HTTP 상태 코드!). 404는 일반적으로 SEO에 큰 영향을 주지 않으나 불필요한 404는 제거하도록 한다 (테크니컬 SEO 필수 요소, HTTP 상태 코드!).
메타 태그 및 헤더 렌더링: 서버에서 각 페이지의 <head> 내용을 동적으로 생성한다. 또한, 비HTML 파일(PDF, 이미지)에는 HTTP 헤더 X-Robots-Tag를 써서 색인 동작을 제어할 수 있다 (X-Robots-Tag - HTTP | MDN).
스키마 마크업 배포: 예를 들어 전자상거래 사이트라면 서버 템플릿에서 Product, Offer, Review 등의 JSON-LD를 주입해 검색 엔진이 정보를 쉽게 파싱하게 한다.
AMP/PWA 지원: 필요한 경우 서버에서 AMP(Accelerated Mobile Pages) 버전을 제공하거나, PWA용 서비스 워커를 설정하여 구글 검색의 페이지 랭킹 및 Core Web Vitals를 향상시킨다.
로그 분석 및 Search Console 활용: 서버 로그로 크롤러 접근 빈도나 오류를 모니터링하고, Search Console을 연계해 색인 처리 현황과 페널티 여부를 점검한다.

실제 사례:

전자상거래: 국내 대형 쇼핑몰(Auction, Coupang 등)은 상품마다 고유한 메타데이터와 구조화된 데이터를 사용한다. 예를 들어 schema:Product 태그로 상품명·가격·재고 등을 표기하고, 서버에서 실시간 반영하도록 한다. 또한, 할인 행사 페이지에는 noindex, follow 같은 메타를 붙여 중복 이슈를 방지한다.
블로그: 유명 기술 블로그나 뉴스 사이트는 글마다 고유한 URL, 제목, 요약을 사용한다. <h1>은 글 제목, <h2> 이하로 소제목을 구분하여 콘텐츠 구조를 명확히 하고, 구글 봇이 내용을 이해하기 쉽게 마크업한다.
다국어 사이트: 다국어 지원 사이트는 hreflang 태그를 서버 사이드에서 삽입해 각 언어별 페이지를 구글에 연결시킨다. 예를 들어 한국어 페이지 <link rel="alternate" hreflang="ko" href="...">, 영어 페이지 <link rel="alternate" hreflang="en" href="...">를 설정한다.

웹 표준/접근성과 SEO의 상호작용

긍정적 상호작용: 웹 표준과 접근성을 준수하면 검색 최적화에도 유리하다. 시맨틱한 HTML 구조(헤더, 기사, 네비게이션 태그 등)는 콘텐츠의 의미를 분명히 전달해 검색 엔진이 페이지를 정확히 이해하도록 돕는다 (알아두면 쓸모 있는 '시맨틱 마크업' 개념 정리 | 요즘IT). 예를 들어 <header>, <main>, <footer>, <article>, <section> 같은 태그를 사용하면 문서의 논리적 구조가 명확해져 SEO와 접근성 모두 개선된다. 실제로 시맨틱 마크업을 도입하면 유지보수가 편해지고, 검색 엔진 최적화(SEO)와 접근성 측면에서 이점이 있다고 알려져 있다 (알아두면 쓸모 있는 '시맨틱 마크업' 개념 정리 | 요즘IT).
상충 가능성: 지나친 스크립트나 비표준 동적 로딩은 오히려 SEO와 접근성을 해칠 수 있다. 예를 들어, 자바스크립트로만 콘텐츠를 로드하면 구글 봇과 스크린 리더 모두 내용을 인식하지 못할 수 있다. 따라서 서버 사이드 렌더링(SSR) 또는 프리렌더링을 사용하여 기본 콘텐츠를 HTML에 포함시키는 것이 중요하다. 또한, ARIA를 잘못 사용하면 접근성은 물론 검색 색인에 혼란을 줄 수 있기 때문에 “바쁘게 ARIA 넣기보다 가능하면 본래 요소를 사용하라”는 모토를 준수해야 한다 (ARIA - Accessibility | MDN).
성능과 경험: Core Web Vitals처럼 SEO 순위 요소로서 사용자 경험(UX)이 강조됨에 따라 웹 표준(적절한 캐시, 최소화된 코드)과 접근성(예: 빠른 렌더링을 위한 대체 텍스트 사용) 모두 페이지 속도 향상과 연계된다. 검색 성과와 사용자 만족도를 동시에 고려해야 한다.
중복 콘텐츠 방지: 웹 표준의 일환으로 canonical URL을 설정하면 중복 페이지 이슈를 방지해 SEO에 유리하다. 이는 접근성과 직접 관련되진 않지만 표준 준수 사례다.
음성 검색/AI 시대: 음성 비서나 인공지능 검색이 확산되면서 구조화된 데이터와 명확한 의미(시맨틱)는 더욱 중요해졌다. 접근성 측면에서도 AI 보조 기술(화면 읽기 소프트웨어 등)이 콘텐츠를 해석하기 쉽게 하기 위해 SEO 시맨틱 구조가 도움을 준다.

항목	웹 표준	웹 접근성	SEO
문서 구조	올바른 시맨틱 HTML(`<header>`, `<nav>`, `<main>` 등) (알아두면 쓸모 있는 '시맨틱 마크업' 개념 정리 \| 요즘IT)	헤딩 순서 준수, `<ul>`, `<table>` 사용 등	`<h1>`~`<h6>`로 계층, 키워드 강조
메타정보	`<meta charset>`, `<html lang>` 지정	없음	`<title>`, `<meta desc>`, `canonical`
키보드 내비게이션	표준 `<button>`, `<a>` 사용	탭 포커스 순서, 스킵 내비 적용 (KISA 한국인터넷진흥원)	–
이미지	적절한 크기·포맷 사용, CSS로 배경 처리 가능	`alt` 텍스트 필수 (KISA 한국인터넷진흥원)	`alt`는 이미지 검색에도 유리
자바스크립트	표준 이벤트 사용, Progressive Enhancement	ARIA 속성 활용(필요 시) (ARIA - Accessibility \| MDN)	서버 렌더링 또는 프리렌더 권장
URL/리디렉션	–	–	읽기 쉬운 URL, 301 리디렉트 적용 (테크니컬 SEO 필수 요소, HTTP 상태 코드!)
폰트/컬러	웹 안전 폰트 사용 권장	대비 기준 준수, 유연한 글자 크기	페이지 속도 영향 고려 (폰트 최적화)
테스트 툴	W3C Validator	WAVE, axe, screen reader	Google Search Console, Lighthouse (Introduction to Lighthouse \| Chrome for Developers)

정리

국·내외를 막론하고 세계적인 IT 기업, 기구, 재단들이 이와 같은 여러가지 표준을 제정하고 가이드를 제공하는 데에는 여러가지 이유가 있을 것이다.

모범 기업의 이미지를 갖기 위해서, 세계 전반적으로 IT 기술의 수준을 높이기 위해서, 보안을 위해서, 공익을 위해서 등등...

수많은 사람들이 개발자는 트렌드에 민감해야 한다고 말하는 이유가 괜히 있는 것이 아니다.

결국 최고의 플랫폼들은 이러한 약속들을 잘 지킨 사이트들을 자주 노출시킬 것이고, 그것은 수익에 직결되기 때문이다.

이와 비슷하게 백엔드 개발자들 사이에선 클린 코드라는 주제가 오간다.

필자는 전 직장에서 입사 첫 주에 다음과 같은 질문을 받은 적이 있다.

재현아, 혹시 클린 코딩이라고 알아?
너는 사람마다 코드의 스타일이 다른 것에 대해 어떻게 생각하니?
과연 사람마다 스타일이 다른 것이 항상 정답일까?

여러 프로젝트들에 참여하며 이에 대한 나만의 생각을 정리할 수 있었다.

euc-kr 인코딩과 함께 cross browsing을 고려하지 않은 Internet Explorer 기준으로 개발되었고, jdk 1.4 버전이 적용되어 기존에 사용하던 변수들의 이름이 무료로 상업적 이용이 허용된 Oracle JDK 8u202버전 기준 예약어로 등록되어 버전 업그레이드 마저 쉽지 않은 상황에 주석도 중구난방이고 서버간의 인코딩 설정을 고려하지 않아 한글 주석이 전부 외계어로 깨져있는 사이트도 경험할 수 있었다.

~~여기서 놀라운 점은 내가 초급 개발자의 경력이라는 것이다. 즉, 지난 1~2년 안에 경험했던 일이라는 이야기.~~

클린 코드라는 개념이 정립되지 않았던 과거 개발 시장의 분위기가 전반적으로 그러했다는 것은 어렴풋이 알고는 있었지만 직접 경험해보니 쇼킹 그 자체였다.

물론 클린 코드 작성 규칙에 따라 소프트웨어를 생산한다면 생산성이 뛰어나다고 하기에는 힘들다.

하지만 클린 코드의 개념을 준수하며 개발된 소프트웨어는 품질이 좋을 뿐만 아니라 유지 보수가 뛰어나다.

해당 백엔드 서비스를 개발한 사람이 아닌 그 누가와도 읽기 쉽고 이해하기도 쉽게 작성된 서비스는 프로그램의 동작을 보장하고, 버그와 오류를 잡기에도 수월하다.

따라서 사람마다 코드의 스타일은 다를 수 있으나, 그 스타일의 바운더리가 정해져 있다는 것이 내 결론이다.

웹 표준, 웹 접근성, 검색 엔진 최적화라는 개념을 처음 접했을 때는 무의식적으로 서버의 입장과는 거리가 멀지 않나? 라는 생각을 하기도 했다.

소프트웨어를 개발할 때 이러한 것들을 가장 고려해야 할 대상은 프론트단이지 서버단이 아니라는 생각이 들었기 때문이다.

하지만 결국 소프트웨어를 개발할 때에는 프론트와 백엔드를 떼어놓고 볼 수가 없다.

이 개념들에 대해 조사하고 포스트를 작성하며 백엔드 개발자가 프론트를 같이 개발하는 경우도 있고 그렇지 않은 경우엔 백엔드 역시도 이러한 것들을 알아야 짜증나는 프론트 개발자에게 한마디라도 지적을 하거나, 서버 구성시 우리 사이트가 노출되었으면 하는 플랫폼과 그렇지 않은 사이트들의 크롤링에 대응이 가능하다는 등의 생각이 들었다.

앞으로 많이 성장하고자 하는 개발자인 나에겐 또 하나의 과제로 다가온 이 개념들에 대해 더욱 많은 학습이 필요할 것 같다.

Novelike

주니어 개발자

이전 포스트

GPU는 스케줄링을 어떻게 할까?

다음 포스트

웹 표준과 웹 접근성 그리고 검색 엔진 최적화(SEO)

Tech

웹 표준 (Web Standards)

웹 접근성 (Web Accessibility)

검색 엔진 최적화(SEO)

웹 표준/접근성과 SEO의 상호작용

최신 동향 및 도구

정리

GPU는 스케줄링을 어떻게 할까?

변수 호이스팅 과 이벤트 전파 방식

0개의 댓글