더 나은 내일을 위한 웹 만들기 웹표준 웹접근성 배리어프리 지난 5월 16일은 무척 특별한 날이었습니다. 바로 ‘세계 접근성 인식의 날(Global Accessibility Awareness Day, GAAD)’이었는데요.  2012년부터 매해 5월 세 번째 목요일, 올해로 열세 번째를 맞은 이 날은 모든 사람들이 장애 여부나 개인의 능력과 관계 없이 누구나 디지털 기술과 정보에 접근할 수 있는 환경을 만들기 위해 마련된 기념일이에요.  인프메이션 #70에서는 세계 접근성 인식의 날을 맞아 웹 접근성에 대한 이야기를 합니다. IT 업계에서 많은 사람들이 접근성에 대한 고민을 모으는 이유가 무엇인지 함께 살펴보도록 해요. 인프메이션 #70 🌿 더 나은 세상을 만드는 웹 접근성과 기술 속에 담긴 권리 이야기 웹 접근성이 뭘까? The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect. 웹의 힘은 보편성에 있습니다. 장애와 무관하게 모든 사람이 접근할 수 있도록 하는 것이 필수적인 측면입니다. ― 월드 와이드 웹(WWW)의 창시자, 팀 버너스리(Tim Berners-Lee) 세계보건기구(WHO)에 따르면 전 세계 인구의 약 16%에 달하는 약 13억 명이 장애를 가지고 있다고 합니다. 한편 세계 인구의 약 66%가 인터넷을 사용하고 있는데요. 처음으로 인터넷을 사용하는 사람들이 매년 늘어나고 있는 만큼(DataReportal 참고) 웹 접근성은 점점 더 중요한 이슈로 떠오르고 있어요. 웹 접근성(Web Accessibility)은 장애를 가진 사람을 비롯한 모든 사용자가 웹 콘텐츠에 동등하게 접근하고 사용할 수 있도록 보장하는 개념이에요. 1999년, 여러 웹 관련 표준을 만들고 장려하는 W3C(월드 와이드 웹 컨소시엄, World Wide Web Consortium)가 처음 공식적으로 제안했죠. W3C는 웹 접근성을 단순히 기술적인 측면에만 한정짓지 않고 모두가 웹을 인식하고, 이해하고, 탐색하고, 상호작용하며, 또 웹에 기여할 수 있게끔 하는 것을 지향합니다. W3C에서는 웹 접근성 표준화를 위한 일환으로 웹 접근성 지침(Web Content Accessibility Guidelines, WCAG)을 공개하고 있는데요. 1999년 1.0 버전 이후 현재 2.1 버전까지 발전한 WCAG는 웹 페이지 및 웹 애플리케이션에 쓰이는 텍스트, 이미지, 소리 등의 자연 정보뿐만 아니라 구조와 표현을 정의하는 코드 및 마크업(Markup)을 대상으로 웹 접근성을 보장하기 위한 여러 방법을 마련하고 있어요.  WCAG는 상황과 역할에 따라 다양한 방식으로 참고할 수 있는데요. 먼저 웹 콘텐츠 제작과 관련한 일을 한다면 웹 페이지를 개발하고 디자인하거나, 웹 페이지에 들어갈 콘텐츠를 작성하는 과정에서 쓸 수 있겠죠. CMS나 웹 빌더, IDE 같은 웹 저작 도구를 개발하고 있다면 도구 자체의 접근성을 향상시킬 수 있고요. 뿐만 아니라 저작 도구 사용자가 콘텐츠를 제작하는 과정에서 접근성 표준을 준수할 수 있게끔 보조하는 기능을 마련하는 데도 도움이 될 수 있죠. 물론 이밖에도 웹 서비스를 만들어가는 데 웹 접근성 표준이 필요한 모든 사람들이 참고할 수 있습니다. 웹 표준, 웹 호환성, 웹 접근성은 어떻게 다를까? 세 가지 모두 사용자가 웹을 편리하고 자유롭게 이용할 수 있게 돕는 개념이에요. 서로가 서로를 보완하는 관계죠. 웹 표준(Web Standards) : HTML, CSS, JavaScript 등 웹 페이지의 구조를 만들고 내용을 표현할 때 필요한 기술의 일관성과 호환성을 보장하는 규칙이에요. 웹 호환성(Web Compatibility) : 웹 표준을 준수함으로써 사용하는 웹 브라우저 및 운영체제, 디바이스의 버전과 종류에 관계 없이 동일한 화면으로 웹 페이지에 접근할 수 있도록 보장해요. (Cross Browsing) 웹 접근성 (Web Accessibility) : 장애, 연령 등 사람의 특징이나 환경적 요인에 따라 웹에서 정보를 접근하는 데 제약이 없도록 해요. 웹 접근성과 웹 호환성을 향상시키는 데는 웹 표준을 준수하는 것이 큰 도움이 돼요. 다만 웹 표준을 지킨다고 해서 반드시 웹 접근성과 호환성을 보장한다고 할 수는 없어요. 웹 표준을 준수하는 것 말고도 실제 사용자 테스트를 비롯해 다양한 사용자의 경험을 보장하기 위한 다른 여러 노력이 필요합니다. WCAG에서는 웹 접근성을 위한 4가지 기본 원칙을 소개하고 있는데요. 각각의 원칙에 대한 뜻과 대표적인 적용 예시를 몇 가지 들어볼게요. 인식의 용이성 (Perceivable) ‘사용자가 콘텐츠를 인식할 수 있어야 한다’는 원칙이에요. 시각장애 사용자가 이미지가 삽입된 웹 페이지를 이용할 때는 페이지에 이미지가 포함되어 있다는 사실을 인지하고, 각각의 이미지가 어떤 내용을 담고 있는지를 알 수 있어야겠죠. 웹페이지에 쓰인 텍스트를 스크린 리더(Screen Reader)를 통해 소리로 이해하는 것처럼 이미지도 마찬가지예요. 웹 페이지에 그래픽 이미지를 표현할 때 쓰이는 <img> 태그에는 ‘대체 텍스트(Alternative Text)’ 속성을 추가할 수 있어요. <img src="123.png">라는 태그를 통해 인프런 마스코트가 그려져 있는 이미지를 웹 페이지에 추가할 때, 스크린 리더는 이 이미지를 “123.png”라는 파일명 그대로 읽어 사용자에게 이미지가 있다는 사실을 전달해 줘요. 그런데 파일명만으로는 그 이미지가 어떤 내용을 담고 있는지를 충분히 이해할 수 없는데요. 대체 텍스트를 추가하는 alt 속성 기호를 사용하고, 이미지를 설명하는 대체 텍스트를 적어둔다면 스크린 리더가 대체 텍스트를 읽을 수 있습니다. 다만 해당 이미지가 내용을 전달하지 않고, 배경이나 구분선처럼 단순한 꾸밈 역할만 한다면 대체 텍스트를 비워둘 수 있죠. alt=""처럼 대체 텍스트를 비워두면 이미지가 핵심 요소가 아니라는 의미이기 때문에 텍스트 리더가 이미지를 따로 읽어주지 않고 넘어가게 돼요.  인식의 용이성 원칙이 시각적 인지를 보조하는 데만 한정되는 건 아닌데요. 유튜브 같은 동영상 플랫폼에 자막을 자동 생성할 수 있게 하거나 파일을 업로드할 수 있게 하는 기능을 지원하는 것도 소리를 듣기 어려운 상황에서 콘텐츠를 잘 인식할 수 있도록 하기 위해서예요.  인프런에 등록된 영상 강의에는 AI가 자동 생성한 자막이 지원돼요. 운용의 용이성 (Operable) ‘사용자가 편리하게 조작할 수 있어야 한다’는 원칙이에요. 웹 페이지의 모든 기능을 마우스 없이 키보드만으로 조작하는 키보드 네비게이션 지원이 대표적인데요. 마우스를 사용하기 어려운 경우, 웹 페이지를 구성하는 모든 링크나 버튼, 양식 필드 등이 Tab 및 Enter 키로 조작할 수 있어야 해요. 또 키보드를 통해 선택하고 있는(포커스) 요소에 테두리나 배경색 등으로 현재 위치를 명확하게 파악할 수 있어야 합니다. 이해의 용이성 (Understandable) ‘콘텐츠가 이해할 수 있어야 한다’는 원칙입니다. 웹 페이지는 사용자를 고려해 명확한 언어를 쓰고 기능과 상황을 이해할 수 있도록 피드백을 줘야 해요. 의도하지 않은 기능이 함부로 실행되거나, 논리적인 순서로 제공되지 않거나, 입력한 정보에 대응하는 도움말 레이블(label)을 제공하는 등 여러 방식으로 사용자의 이해를 도울 수 있죠. <label for="email">이메일 주소:</label> <input type="email" id="email" name="email" aria-describedby="emailHelp"> <span id="emailHelp">유효한 이메일 주소를 입력하세요.</span> 만약 이메일 주소를 입력하는 양식 입력 필드가 있다면, 사용자가 올바르게 본인의 주소를 입력할 수 있도록 ‘유효한 이메일 주소를 입력하세요’ 같은 도움말을 제공함으로써 스크린 리더를 사용할 때에도 어려움이 없도록 해야 해요. 견고성 (Robust) ‘콘텐츠가 미래의 기술과도 접근할 수 있도록 견고하게 만들어져야 하고, 다양한 보조 기술과 호환되어야 한다’는 원칙입니다. 웹 페이지는 시맨틱 HTML 태그 요소를 통해 문서의 구조와 의미를 명확히 해야 해요. 웹 서비스 화면이 푸터<footer>, 헤더<header>, 웹 페이지 사이드바<aside> 등을 구분하지 않고 단순히 어떤 영역을 묶었다는 의미만 지닌 <div> 태그로만 이루어져 있다면 페이지를 이루는 영역별 구조나 계층을 파악하기 어려워지기 때문이에요. 겉보기엔 비슷해 보이더라도, 시맨틱 HTML 태그 요소를 잘 따른 페이지가 훨씬 계층을 파악하기 쉽고 다른 보조 기술과의 호환성도 뛰어나요. 지키기 어렵다고? 갈 길 먼 웹 접근성 웹 접근성에 대한 논의가 처음 시작된 지 30년 가까이 지났지만, 사실 여전히 많은 웹 서비스가 웹 접근성을 충분히 지키지 못하고 있어요. 웹 접근성 솔루션을 제공하는 비영리 단체 WebAIM이 실시한 접근성 평가에 따르면, 2024년 기준 상위 100만 개 웹 사이트 가운데 WCAG 적합성에 문제가 있는 요인이 감지된 웹 페이지가 무려 95.9%에 달한다고 해요. (텍스트 대비가 낮거나, 대체 텍스트가 누락되었거나, 링크나 버튼이 비어 있거나…)  많은 웹 서비스의 복잡성이 점점 커지는 가운데, 서비스를 만드는 조직과 개인이 웹 접근성을 준수하는 데 여러 어려움이나 제약이 있다는 걸 완전히 부정하기는 어려워요.  먼저 기술적인 어려움이 웹 접근성을 준수하기 어려운 이유로 꼽힙니다. 웹 접근성을 위한 여러 요구 조건을 구현하기 위해 고려해야 하는 여러 사항들이 개발 복잡성을 증가시킬 수 있죠. 특히 이미 구축된 시스템과의 호환성을 유지하면서 접근성 기준에 맞게 변경하는 작업은 때때로 기술적으로 까다로운 작업이 될 수 있어요. 더욱이 웹 접근성을 고려함으로써 드는 추가적인 개발 시간이 많은 조직에 큰 부담으로 다가오곤 합니다. 프로젝트 일정 외에도 접근성을 개선하기 위한 도구나 테스트 등에도 추가로 비용이 발생할 수 있고요. 상황이 이렇다보니 웹 접근성이 조직 내에서 우선순위로 인식되지 않고 다른 업무에 밀리거나, 쉽게 받아들여지지 않는 경우도 부지기수죠. 이런 조직적 저항이 접근성 향상을 위한 노력에 큰 걸림돌이 되고요. 무엇보다 웹 접근성에 대한 인식 부족 자체가 가장 큰 문제로 다가오는데요. 여전히 웹 서비스를 만드는 많은 사람들이 웹 접근성의 중요성이나 구체적인 방법을 충분히 이해하지 못하는 경우가 많아요. 웹 접근성에 대해 명확하게 이해하지 못하면 실제로 이를 구현해야 할 이유를 느끼지 못하기 때문입니다. ‘ActiveX 시대’ 기억하시나요? Microsoft에서 개발한 프레임워크, ActiveX(액티브엑스)는 2000년대 초반부터 민간 서비스와 공공 서비스를 가리지 않고 한국 웹 환경에서 폭넓게 쓰이기 시작했어요. 당시 한국 웹 브라우저 시장을 독점하다시피 하던 인터넷 익스플로러(Internet Explorer, IE)에서 주로 쓰이던, 정적인 웹 문서를 멀티미디어 기술을 통해 동작할 수 있게 하는 기술이었죠. 하지만 보안 취약점이나 호환성, 성능 저하 등 여러 문제점이 제기됐고, 특히 웹 접근성 측면에서 많은 비판을 받았어요. Windows 및 IE 외에 다른 운영체제와 브라우저를 쓰는 사용자들에게 접근성 문제를 일으키는데다, 스크린 리더나 음성 인식 소프트웨어 등 장애를 가진 사용자들에게 필요한 보조 기술과 호환되지 않는 경우가 잦았습니다. 더욱이 ActiveX 기반 시스템은 업데이트 및 유지보수에도 어려움이 많아 최신 웹 표준을 적용하기 힘들다는 고질적인 문제를 가지고 있었죠. 지금은 IE 지원 종료, 법 개정 등을 거치며 ActiveX가 사실상 퇴출되는 방향으로 나아가고 있습니다. 하지만 이런 어려움이 웹 접근성을 ‘지키지 않아도 되는’ 이유가 되지는 않아요. PC와 스마트폰 없는 하루를 상상하기 어려운 만큼, 웹은 이미 우리 삶의 여러 측면에서 점점 더 중요한 자원이 되어가고 있어요. 그만큼 웹 접근성은 누구에게나 정보에 동등하게 접근할 권리의 문제입니다. 유엔 장애인 권리 협약에서도 웹을 비롯한 정보 및 통신 기술에 대한 접근을 기본 인권이라고 밝히고 있죠. “웹의 힘은 보편성”이라는 팀 버너스리의 말처럼, 웹은 차별을 뛰어넘는 기술을 지향합니다. 인쇄나 오디오, 시각 매체 등 웹 이전의 미디어가 가진 접근성에 대한 장벽을 훨씬 더 쉽게 극복할 수 있고요. 그리고 실제로 웹 접근성의 등장은 IT 생태계에서 접근성을 논의하는 단초가 되었습니다. 웹 접근성을 준수하는 건 모든 사람들에게 함께 도움이 되는 일이에요. 전반적인 사용자 경험(UX)을 개선함으로써 장애인뿐만 아니라 노인, 농촌 지역이나 개발도상국에 사는 주민 등 다양한 사람들을 사회적으로 통합하는 역할도 하죠. 더욱이 웹 접근성의 기초가 되는 웹 표준을 잘 준수한 웹 서비스는 검색 엔진 최적화(SEO)에도 유리할 뿐만 아니라, 빅데이터 및 AI 산업 등 IT 생태계를 더욱 풍성하게 하는 데 기여할 수 있기도 합니다. Google 검색 센터에서 제공하는 문서 및 블로그 아티클 등을 살펴보면, 접근성 및 웹 표준을 잘 따를 경우 검색 결과에 표시될 가능성이 높다고 여러 번 언급되어 있어요. 웹 접근성에 대해 생각할 때 가장 중요한 건 ‘접근성’을 생각하는 것 자체에 있습니다. W3C에서도 웹 접근성에 대한 적합성을 판단하고 결정하는 기준은 WCAG에서 제안한 4가지 원칙(▲인식의 용이성 ▲운용의 용이성 ▲이해의 용이성 ▲견고성)을 지켰는지가 되어야 한다고 밝히고 있는데요. 끊임없이 변화하는 기술의 흐름, 그리고 수많은 상황 가운데 웹 접근성을 지키기 위한 절대적 기술을 찾기보다는 4가지 원칙을 충족할 수 있는 ‘방법’을 고민하는 게 무엇보다도 중요하겠죠. 모두가 동등한 경험을 할 수 있도록 어떤 노력을 하면 좋을까 W3C에서는 웹 표준을 준수하는 데 도움이 되는 CSS 검사기를 비롯해 링크 검사기, 국제화 검사기 등 다양한 도구를 제공하고 있어요. 마크업에는 오류가 없는지, 모든 브라우저에서 페이지가 제대로 표현되고 있는지를 검사할 수 있죠. WebAIM에서도 웹 접근성 평가 도구 WAVE를 제공합니다. 웹 접근성을 확인하고자 하는 페이지 URL을 입력하면 접근성을 지키지 못한 부분에 대해 에러나 경고를 띄워주는 등 페이지 구조를 이루는 여러 요소를 분석해줘요. (인프런도 아직 개선할 것이 무척 많아요.) 웹 브라우저 자체에서 개발자가 웹 접근성을 준수하는 데 도움이 되는 기능을 제공해요. 점유율 1위인 구글 크롬의 개발자 도구(Chrome DevTools)에서도 웹 접근성 관련 기능을 제공하죠. 텍스트 색상과 배경색의 대비가 적절한지 확인하는 명암비(Contrast Ratio) 검사, 색각 이상이나 저시력 장애 사용자 입장에서의 화면 렌더링 등 여러 보조 기능을 찾아볼 수 있어요. 서비스 UI를 그리는 프로토타이핑 툴 피그마(Figma)에서도 접근성 주석을 작성하는 A11y, 명암비를 확인해 주는 Contrast 등 접근성 관련 여러 플러그인을 쓸 수 있어요. 올해 공개된 ‘디지털 정부서비스 UI/UX 가이드라인’에서도 WCAG을 참고하여 색상 명암비 등이 기준을 충족하는지 확인해야 한다는 내용 등을 찾아볼 수 있어요. (디지털 정부서비스 UI/UX 가이드라인에 대한 이야기는 지난 인프메이션 #68에서 더 자세히 읽을 수 있어요.) 2023년 7월부터는 모바일 앱에 장애인 접근성에 대한 의무가 사업장 규모 및 업종에 따라 단계적으로 적용됩니다. 대통령령으로 정한 「장애인차별금지 및 권리구제 등에 대한 법률 시행령」에서 적용 범위에 대한 내용을 찾아볼 수 있어요. 네이버에서는 디지털 정보 접근성을 담당하는 널리(NULI) 서비스를 운영하며 접근성을 주제로 세미나를 진행하거나, 접근성 매뉴얼 등을 공개하고 있어요. 올 하반기 애플은 새로운 ‘손쉬운 사용’ 기능을 공개할 예정이라고 해요. 눈 추적 및 음악 햅틱, 음성 단축어 기능 등을 추가로 선보인다고 합니다. 삼성전자는 세계 접근성 인식의 날을 맞아 올해 5월 16일부터 2주간 ‘접근성 페스티벌 위크(Accessibility Festival Week, AFW)’ 행사를 진행하고 있습니다. 카카오는 올해 세계 접근성 인식의 날에 맞춰 발달장애인, 노인 등 디지털 소외계층의 카카오톡 이용을 돕는 ‘더 쉬운 카톡설명서’를 공개했어요. 접근성은 모든 사용자의 동등한 경험을 위한 요소예요. IT 서비스를 제작하는 데 있어 꼭 고려해야 하는 만큼 접근성을 지키기 위한 개인과 기업, 기관 등 모두의 노력이 필요합니다. 그동안 웹 접근성을 지키기 어려웠거나, 웹 접근성에 대해 잘 몰랐다면 지금부터라도 웹 접근성을 생각해 보면 어떨까요? 어떤 것부터 개선해보면 좋을지 고민하며 하나씩 바꿔나가는 작은 변화가 모여 큰 차이를 만들어나갈 수 있을 테니까요. 함께 나누고 싶은 이야기가 있다면, 여러분의 목소리를 댓글로 남겨주세요. 😊 모두의 고민과 의지를 모아, 더 풍성한 IT 생태계를 가꿔 나갈 수 있기를 바랍니다. 함께 보면 좋은 강의 add_shortcode('course','159719,330798,201184,326319','card','card1') 나의 성장을 돕는 IT/커리어 콘텐츠, 인프메이션 구독하면 먼저 빨리 알려드려요. 이번 인프메이션 어떠셨나요? 💌 의견 보내기 빠르게 받아보는 새 글 🔔 소식 알림 설정 지난 글이 궁금하다면 📚 인프메이션 모아보기

이름에도 규칙이 있다? 알고 쓰는 네이밍 컨벤션 A to Z 프로그래밍 코딩컨벤션 네이밍컨벤션 Quora 및 Ubuntu 포럼에서 진행된 토론 스레드에 따르면 토론에 응답한 개발자 49%가 이름 짓는 걸 가장 어려운 작업으로 꼽았다고 해요. ⓒPhil Johnson/ITworld (번역) ‘개발자의 가장 큰 고민은 이름 짓기’라는 말, 들어보셨나요? 농담 같지만 마냥 농담이라고만 할 수 없는 얘기죠. 프로그래밍을 하다 보면 변수와 함수, 클래스, 디렉토리, 데이터베이스 필드 등 프로그램을 이루는 수많은 요소 하나하나 계속해서 이름을 붙여야 하니까요. 많은 개발자들이 이름 ‘잘’ 짓는 방법을 고민하는 이유는 뭘까요? 인프메이션 #69에서는 개발자의 영원한 숙제(!) 네이밍 컨벤션에 대해 이야기합니다. 인프메이션 #69 🌿 그냥 짓는 건 쉬워도 잘 짓는 건 어렵다? 네이밍 컨벤션이 필요한 이유 알아보기! 코딩 컨벤션? 네이밍 컨벤션? 코딩 컨벤션의 한 갈래인 네이밍 컨벤션(Naming Convention)은 코드에서 사용되는 명명(命名) 규칙이에요. 그렇다면 코딩 컨벤션은 뭘까요?  흔히 ‘개발자는 코드를 쓰는 시간보다 코드를 읽는 시간이 더 길다’고들 하죠. 프로젝트가 진행됨에 따라 이미 작성된 코드를 수정하고 버그를 찾는(Debugging) 일이 늘기 마련입니다. 이미 만들어진 외부 라이브러리 등을 활용할 목적으로 관련 코드를 읽는 경우도 많죠. 더욱이 여럿이 협업하는 프로젝트라면 다른 사람이 작성한 코드를 이해해야 하고요. 이렇듯 코딩 컨벤션(Coding Convention)은 읽고 관리하기 쉬운 코드를 작성하기 위해 코드를 ‘쓰는’ 방식을 정하는 규칙과 관행이에요. 들여쓰기(Space를 쓸 것인지 Tab을 쓸 것인지), 공백, 줄바꿈, 주석 작성 방식, 코드 구조 등 코드 스타일에 대한 여러 규칙을 통일해 소스 코드의 가독성을 높이고 일관성을 유지하게끔 해요.  ‘조선 붕당의 이해’ 밈을 패러디한 ‘코딩으로 본 조선 붕당의 이해’. 들여쓰기에 탭과 스페이스 중 어떤 걸 사용해야 하는지는 개발자 사이 오랜 논쟁(?)거리이기도 하죠. 그중에서도 네이밍 컨벤션은 소스 코드에 쓰이는 식별자(변수, 함수, 클래스, 타입 등)에 이름을 붙이는 방법을 다뤄요. 쉽게 말해 변수나 함수 등의 이름을 어떻게 지으면 좋을지에 대한 약속이라고 할 수 있어요. 뱀부터 케밥까지, 대표적인 네이밍 컨벤션 6가지 보통은 식별자 이름으로 영단어를 조합해 붙이는 경우가 많은데요. 유의할 점 중 하나는 여러 단어를 이어 만들 때 단어와 단어 사이에 공백(띄어쓰기)을 넣지 않아야 한다는 것입니다. 많은 프로그래밍 언어에서 두루 쓰이는 변수(Variable)가 대표적인데요. 일반적으로 프로그래밍 언어에서 변수명은 공백이 없는 낱말로 이루어져야 해요. 만약 공백이 포함되면 컴퓨터는 변수가 들어간 코드를 하나의 변수로 해석하지 못하고 문법 오류(Syntax Error)로 처리하기 때문이죠. 더욱이 데이터를 저장하고 조작하는 데 변수가 폭넓게 쓰이는 만큼, 변수명을 어떻게 짓는지에 따라 코드의 가독성과 유지보수 편의가 크게 좌우될 수 있어요.  때문에 변수명을 비롯한 여러 식별자 이름을 짓는 데 쓰이는 네이밍 컨벤션은 여러 단어를 이어 쓸 때를 전제로 한 규칙을 세우고 있습니다. 잘 알려진 네이밍 컨벤션으로는 이런 것들이 있어요. snake_case 스네이크 케이스 모든 철자를 소문자로 쓰고 단어 사이에 언더스코어_를 표기하는 방식이에요. 단어를 연결하는 언더스코어가 뱀의 몸처럼 보인다며 붙은 이름입니다. 파이썬(Python) 등에서 주로 권장하며, DB 컬럼(column)명으로도 흔히 사용돼요. 예: user_id, created_at, phone_number SCREAMING_SNAKE_CASE스크리밍 스네이크 케이스 모든 철자를 대문자로 쓰고 단어 사이에 언더스코어_를 표기하는 방식이에요. 대문자 철자가 소리를 지르듯(Screaming) 강조하는 느낌을 주죠. 주로 프로그램 실행 중 값이 변하지 않아야 하는 특정 상수(Constant)를 강조하는 데 사용돼요. 예: DEFAULT_FONT_SIZE camelCase 카멜 케이스 맨 앞 단어의 첫 철자를 소문자로 시작하되, 그 다음 이어지는 단어의 첫 철자를 대문자로 표기하는 방식이에요. 첫 단어를 제외한 각 단어가 혹이 솟아오른 단봉낙타 등처럼 보여요. 자바(Java), 자바스크립트(JavaScript), 타입스크립트(TypeScript) 등에서 많이 쓰이며, 변수·메서드·함수 이름 등에 사용돼요. 예: userId, createdAt, phoneNumber UpperCamelCase, PascalCase 어퍼 카멜 케이스, 파스칼 케이스 맨 첫 단어를 비롯한 모든 단어마다 첫 철자를 대문자로 표기하는 방식이에요. 단어마다 솟아오른 철자가 쌍봉낙타 등처럼 보여 붙은 이름이죠. 클래스(Class) 이름을 지정하는 데 많이 쓰여요. 예: UserProfile, ShoppingCart kebab-case케밥 케이스 모든 철자를 소문자로 쓰고 단어 사이에 대시-를 표기하는 방식이에요. 연결된 단어가 꼬챙이에 꿴 케밥처럼 보여요. HTML, CSS 등에서 흔히 볼 수 있으며 URL 패러미터(Parameter) 및 슬러그(Slug)에 많이 쓰여요.* 예: max-width, /infmation-69-20240509 Hungarian Notation 헝가리안 표기법 변수나 함수 이름 앞에 타입 접두사를 붙여 어떤 종류의 데이터를 저장하는지를 가리키는 방식이에요. (정수형을 가리키는 int, 문자열을 가리키는 str, 객체를 가리키는 obj 등...) 1970년대 헝가리 출신의 마이크로소프트 프로그래머 찰스 시모니(Charles Simonyi)가 고안했어요. 지금은 예전만큼 활발히 쓰이지 않는 방식이에요. 예: intPrice, strUserName, objDocument 이러한 네이밍 컨벤션은 프로젝트의 상황이나 채택하는 기술의 특성에 따라 다양하게 혼합되어 쓰이고 있어요. 프로그래밍 언어, 프레임워크 등 기술마다 주로 사용되는 네이밍 컨벤션이 있죠.  공식 문서를 통해 권장하는 컨벤션을 정해 두기도 하고, 해당 기술을 사용하는 커뮤니티에서 여러 개발자들이 특정 컨벤션을 관습처럼 따르기도 합니다. 한편 한 기술 안에서도 식별자 유형마다 추천하는 컨벤션을 구분해 두기도 하는 만큼 수없이 많은 사례가 있다고 볼 수 있어요. 팀 여건이나 외부 API 사용 여부 등 여러 이유로 Node.js 프로젝트에 공식 문서에서 권장하는 카멜 케이스가 아닌 다른 네이밍 컨벤션을 함께 사용하기도 해요. DB 컬럼 이름에 여전히 스네이크 케이스가 쓰이기 때문에, JS/TS 애플리케이션과 함께 쓰는 일부 DB 클라이언트(ORM)에서는 테이블 컬럼의 스네이크 케이스를 자동으로 카멜 케이스로 매핑해주는 기능을 지원하죠. 지원하지 않는 클라이언트에서는 별도 패키지를 사용해서 처리해야 하고요. (함께 읽으면 좋은 글 : "Snake_case or camelCase in node.js", "TypeORM에서 Camelcase 필드를 Snake 컬럼에 매핑하기") 네이밍 컨벤션은 개발자와 협업하는 프로덕트 디자이너에게도 중요한 영역이에요. (인프런 강의 “피그마 배리어블을 활용한 디자인 시스템 구축하기”) URL 슬러그엔 왜 케밥 케이스를 쓸까?* 케밥 케이스는 대시(-)로 단어와 단어를 명확하게 구분하기 때문에 검색 엔진 최적화(SEO)에 유리한 영향을 미칠 수 있다고 해요. 더욱이 가리키는 단어를 명확하게 알 수 있는 만큼 사용자가 URL을 구분하고 파악하기에도 편하죠. (이 페이지의 슬러그도 케밥 케이스를 따라요!) 네이밍 컨벤션, 왜 지켜야 할까? 네이밍 컨벤션은 소스 코드를 읽고 이해하는 데 드는 노력과 부담을 덜어주는 역할을 하는데요. 잘 따르게 되면 이런 장점이 있어요. 높은 가독성 코드를 읽는 사람이 변수, 함수, 클래스 등의 역할을 쉽고 빠르게 이해할 수 있어요. 편리한 유지보수 일관된 규칙을 통해 코드를 이해하고 수정하는 데 드는 시간을 줄여요. 의사소통 효율 향상 협업하는 개발자들 사이에서 코드에 대한 이해를 공유하는 데 도움이 돼요. 뛰어난 재사용성 비슷한 기능을 추가할 때나 다른 프로젝트에 활용할 목적으로 다시 쓰기 편한 코드 형태를 갖출 수 있어요. 코드 충돌 방지  각 요소 이름이 중복되지 않고 고유할 수 있게끔 유의함으로써 코드가 충돌하는 상황을 미연에 방지할 수 있어요. 문서화 이점  네이밍 컨벤션을 잘 따른 프로젝트는 소스 코드 자체로 이해하기 쉽고, 그 자체로 설명서 역할을 할 수 있어요. 특히 대규모 프로젝트에서는 네이밍 컨벤션을 지킴으로써 코드베이스 전체가 일관된 스타일을 갖추는 것이 작업 능률을 높이는 데 무척 중요해요. 모든 팀원이 비슷한 상황에 공유된 스타일을 지킴으로써 혼란을 줄이고 협업을 원활하게 할 수 있기 때문이죠. 그래서 코드 리뷰 과정에서도 네이밍 컨벤션 검토는 중요한 고려 사항 중 하나로 꼽혀요. 물론 여러 사람과 협업하지 않는 1인 프로젝트라고 해도 네이밍 컨벤션을 준수하는 건 바람직한 습관이에요. 이후에 협업을 하거나 오픈 소스로 프로젝트로 공개할 가능성도 있고, 협업을 제외한 여러 장점들이 결국 코드의 질을 높이고 개발 과정을 보다 효율적으로 만들어주기 때문입니다. 좋은 이름 짓기가 어려운 이유 스타일을 넘어서, 이름 ‘잘 짓는’ 원칙 수박을 ‘몽미’라고 부르면 다른 사람이 무엇을 얘기하는 건지 알아듣지 못하는 것처럼, 식별자 이름은 가리키는 대상을 명확하게 알 수 있어야 해요. ⓒ천재교과서 여러 네이밍 컨벤션 유형을 따르기에 앞서, 어떤 단어로 이름을 지을 것인지도 무척 중요합니다. 핵심은 ‘정확한 의미를 알기 쉽게’라는 점인데요. 식별자의 이름은 해당 식별자가 담고 있는 기능과 데이터, 역할 등을 명확히 전달해야 해요. 알아보기 어려운 약어나 은어로 지은 이름은 협업하는 다른 개발자는 물론 처음 이름을 지었던 개발자 본인도 뜻을 단번에 알아보거나 기억해내기 어려울 수 있어요. 간결한 이름만으로도 해당 식별자의 역할을 충분히 설명할 수 있다면 짧은 이름이 좋지만, 지나치게 압축적이라서 이해하기 어렵다면 오히려 독이 될 수 있죠. 프로그래밍을 하다 보면 변수명을 짧게 할지, 길고 자세하게 지을지 고민하게 될 때가 많아요. 과거에 인기를 끌던 헝가리안 표기법이 지금은 쇠퇴한 이유도 코드 가독성과 편의에 따른 변화라고 볼 수 있어요. 헝가리안 표기법이 등장했던 시절엔 코드에서 변수명만 보고도 데이터 타입(Data Type: 자료형)을 바로 추정할 수 있다는 점이 유용하게 작용했죠. 하지만 지금은 IDE(통합 개발 환경)에서 코드 완성 기능, 타입 추론 등 여러 기능을 지원하기 때문에 변수나 함수의 타입을 이름에 명시할 필요가 줄었습니다. 오히려 이름마다 불필요한 정보(타입)가 붙어 코드 가독성이 나빠지고, 개발 도중에 데이터 타입이 바뀐다면 모든 이름을 수정해야 한다는 단점이 두드러졌고요. 의미적인 일관성을 유지하는 것도 중요합니다. 많은 프로젝트에서 한 개념에 대해 다른 네이밍 컨벤션을 사용하면서 여러 이름이 혼재되는 경우가 심심치 않게 발생하는데요. 때문에 동일한 유형으로 구분되는 변수라면 동일한 패턴이나 접두사 등을 써서 일관되게 이름을 지을 필요가 있죠. 따르고자 하는 네이밍 컨벤션의 대소문자 및 연결부호 사용을 지키면서도 오탈자가 생기지 않도록 주의해야 하고요. 프로그램이 실행될 때 에러나 버그가 발생하지 않도록 여러 기술적인 조건도 꼼꼼하게 고려해야겠죠. 다시 말해 가리키는 대상이 뚜렷하면서도 유일한 표현을 사용하고, 일관적이면서도 시간이 지나도 뜻이 변하지 않는 영속성을 지닌 이름이 ‘좋은 이름’이라고 할 수 있어요. IDE인 Visual Studio Code(비주얼 스튜디오 코드)에서 변수명 오타를 잡아주는 익스텐션도 있어요. 카카오페이에서는 사내 해커톤을 통해 변수명을 추천해 주는 ‘너의 변수명은.’ 슬랙(Slack) 챗봇을 개발한 과정을 기술 블로그에 공개하기도 했어요. 끝으로, 협업 과정에서 네이밍 컨벤션을 정할 때 무엇보다 중요한 건 바로 합의 자체에 있다는 점을 생각해야 해요. 여러 네이밍 컨벤션 가운데 가장 적절해 보이는 컨벤션을 선택하는 건 물론 중요한 일이지만, 팀을 둘러싼 제약이나 특수성을 충분히 고려하지 않는다면 오히려 효율이 떨어지거나 문제가 발생할 수도 있기 때문입니다. 그래서 컨벤션마다의 우위를 따지기보다는 어떤 컨벤션을 선택할 것인지에 대해 충분히 논의하고, 그렇게 정한 규칙을 팀 안에서 올바르게 따르는 게 더욱 중요해요. X(트위터)에서 누적 19만 조회수를 기록한 토스페이먼츠 ‘세종대왕 프로젝트’. 작년 7월 X(트위터)에서는 토스페이먼츠의 한글 코딩 컨벤션 ‘세종대왕 프로젝트’가 화제가 되기도 했는데요. 토스페이먼츠에서는 ‘국가지방자치단체 공공단체 금융사 여부’처럼 어려운 도메인 용어를 쉽게 이해할 수 있도록 변수, 상수, 함수, 타입 등을 한글로 표기하고 있다고 합니다.  이러한 컨벤션에 대해 우려를 보내는 시선도 있는데요. 특히 글로벌 서비스를 제공하거나 한국어를 구사하지 않는 개발자가 소속된 팀 등 외부와의 협업 및 기술 연동에 어려움이 발생할 수 있다는 이유 등을 꼽을 수 있죠. 하지만 외부의 관점으로 판단하기보다는 실제로 컨벤션을 따르는 조직 안에서의 합의가 중요하다는 의견도 존재합니다. 결국 네이밍 컨벤션을 고민하는 것도 여러 다양한 방법 가운데 우리 팀에 가장 어울리는 선택(Best Practice)을 찾는 과정이니까요. 인프런과 랠릿을 만드는 인프랩 프론트엔드 파트에서는 코딩 컨벤션에 대해 논의하는 슬랙 채널을 마련해두고 있어요. 오늘도 많은 개발자들이 좋은 이름을 고민합니다. 이름 하나하나가 코드의 만듦새를 결정하고, 팀의 개발 환경을 일궈 나가죠. 그래서 네이밍 컨벤션을 정하고 따르는 과정은 단순히 이름을 붙이는 일 이상의 의미를 가져요. 개발자의 일하는 방식과 고민이 이름 하나하나에 담겨 있다고 해도 과언이 아니죠. 네이밍 컨벤션에 대한 이야기, 어떠셨나요? 여러분이 선호하거나 주로 쓰는 네이밍 컨벤션은 어떤 게 있나요? 네이밍 컨벤션과 코딩 컨벤션에 대한 여러분의 이야기를 들려주세요. 😊 당신의 변수명에 투표하세요! 😉 함께 보면 좋은 강의 add_shortcode('course','329905,328348,327946,330387','card','card1') 나의 성장을 돕는 IT/커리어 콘텐츠, 인프메이션 구독하면 먼저 빨리 알려드려요. 이번 인프메이션 어떠셨나요? 💌 의견 보내기 빠르게 받아보는 새 글 🔔 소식 알림 ON 지난 글이 궁금하다면 📚 인프메이션 모아보기

  🎉 당첨을 축하드립니다! 🎉 [ 배경화면 공유 이벤트 ] 당첨자 총 10명 당첨되신 분들께는 아래 메일 통해 개별 안내드릴 예정입니다.참여해주신 모든 분께 감사드립니다😊 f***n0607@naver.com d***finado12@hotmail.com y***9555@naver.com b***eypark@kakao.com k***ng522@gmail.com h***ung0107_@naver.com m***sion777@gmail.com p***801@naver.com j***05802@naver.com g***6500@gmail.com 봄봄봄~ 봄이 왔네요~♪ 얼마 전 배경화면 인증 이벤트를 진행하며,앞으로 개발자 분들을 위한 배경화면을 제작해배포하겠다고 말씀드린 거 기억하시나요? * 현재 사용 중인 배경화면을 올려달라고 했더니정말 다양한 배경화면을 올려주셨는데요!😆 많은 분들의 배경화면을 통해 분석해본휴먼 AI✨의 결과(!)는 아래와 같았습니다.   💡장시간 모니터를 봐서 어두운 화면 선호 💡잠시의 힐링을 위한 자연 풍경 💡아이콘 배치 및 정렬을 은근히 신경 씀 💡역시 귀여운 게 최고   🖥️ 그래서 첫 번째 배경화면은..?!   많은 고민과 부담이 있었는데요...각설하고 바로 소개합니다! .. (두근두근..) ... . . .     🌟 배경화면 관전 포인트 🌟 ✔️ 귀여운 인프런 마스코트 등장✔️ 칸 별로 아이콘 깔끔하게 정렬 가능✔️ 활용도에 따라 롱 버전 & 숏 버전 다운로드 여기에, + 어?! 대신 오?! 하는 순간이 많길 바라는 마음 한 스푼과버그 없이 행복하시길 바라는 마음 한 스푼을 담았어요.   <롱 버전>   <숏 버전>   👉 배경화면 다운 받기 (클릭) 👈   ✦ 소문내기 이벤트 ✦   인프런의 배경화면 배포 소식을 소문내주시면10명에겐 인프런 포인트 10,000잎을 선물로 드려요!   ※ 참여방법 ※ 본인의 SNS나 활동 커뮤니티, 오픈카톡 등 어디든하단 이벤트 페이지 링크를 복사해 공유해주신 후,해당 게시물 링크 혹은 캡쳐본을 댓글로 달아주시면10분을 추첨하여 선물을 드립니다. 👇 링크 복사하기 👇https://u.inf.run/배경화면소문내기 ㅣ   참여 : 2024년 5월 9일(목) ~ 2024년 5월 19일(토)  ㅣㅣ   당첨자 발표 : 2024년 5월 24일(금)  ㅣ   마치며...   첫 번째 배경화면 어떠셨나요?이벤트 댓글과 별개로,배경화면에 대한 피드백, 의견을자유롭게 남겨주세요! 고객님들의 의견을 반영해(?)더욱 업그레이드 해서 돌아오겠습니다. To be continued! 😎