이름에도 규칙이 있다? 알고 쓰는 네이밍 컨벤션 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 지난 글이 궁금하다면 📚 인프메이션 모아보기

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

정부 누리집에서 피그마(Figma)로 된 디자인 리소스를 제공한다고? 프로덕트 디자인시스템 UX/UI 웹접근성 국내 전자행정 시스템은 수십 년에 걸쳐 빠르게 발전해 왔지만, 정부 및 공공기관에서 제공하는 여러 공공 웹·앱의 사용자 경험(UX) 및 인터페이스(UI)가 좋은지에 대해서는 고개를 갸웃하는 분들이 많죠. 민간 서비스의 편리함에 미치지 못한다는 의견이 더러 있고요. 올 봄, 대한민국 행정안전부(장관 이상민, 이하 행안부)에서 디지털 정부서비스 웹·앱을 대상으로 디자인 지침 및 세부 사항을 제시하는 ‘디지털 정부서비스 UI/UX 가이드라인’을 배포했습니다. 공개된 결과물에 쏟아지는 국내 프로덕트 개발 · 디자인 업계의 관심이 뜨거운데요. 인프메이션 #68에서는 이번 디지털 정부서비스 UI/UX 가이드라인을 살펴봅니다.  이번 UI/UX 가이드라인이 왜 만들어졌는지, 눈여겨보면 좋을 점은 어떤 것들이 있는지 함께 알아보아요! 인프메이션 #68 🌿 프로덕트 디자이너, 기획자, 개발자까지 이번 가이드라인에 주목하는 이유! 디지털 정부서비스 UI/UX 가이드라인, 어떻게 만들어졌을까? 📢 디자인 시스템에 대한 기본적인 이야기가 궁금하다면, 이 글을 먼저 읽어주세요. (인프메이션 #64) 디지털 정부서비스 UI/UX 가이드라인 누리집(웹사이트). 최상단에 대한민국 공식 전자정부 누리집이라는 배너가 붙어 있어요.  지난 1월, 행안부는 사용자 중심의 공공 웹·앱 UI/UX 혁신을 위한 개선 사업을 추진한다고 밝혔습니다. 이 사업은 사용자 불편 사항을 개선하기 위한 공통 가이드를 개발한 다음, 주요 웹 사이트를 중심으로 가이드에 해당하는 내용을 적용해나가는 것이 요점이에요. 주된 내용은 이렇습니다. 공공 웹·앱의 복잡함을 사용자가 많이 쓰는 기능 중심으로 간소화 안내 영역 강화 불필요하거나 반복되는 절차 최소화 필요한 정보(사전 준비사항, 신청 완료 여부)의 명확한 제공 고령자를 고려해 글자 크기를 확대(통상 13~15px → 17px)하고 명확한 글꼴로 제공 및 글자 크기 확대 버튼 등을 지원 검색, 로그인, 서비스 신청 등 공통적인 부분을 비슷한 방식으로 사용할 수 있게 함 이번 디지털 정부서비스 UI/UX 가이드라인이 바로 해당 사업에서 가리키는 ‘공통 가이드’예요. 공통가이드 공개 전, 1월 12일 행안부 보도자료를 통해 가이드를 적용한 프로토타입 예시가 공개되기도 했어요. 이 가이드라인은 지난해 실시된 사용자 데이터 분석 및 국민평가를 바탕으로 분야별 전문가 협력, 실제 디지털 정부서비스 운영자·개발자의 의견 수렴을 거쳐 만들어졌어요. ‘누구나 쉽고 편리하게 이용할 수 있는 공공 서비스 개발 및 개선’을 골자로 하죠. 디지털 정부서비스 기획·구축·운영·관리에 참여하는 사람(운영자, 관리자, 기획자, UI/UX 디자이너, 웹 퍼블리셔, 개발자 등)이라면 누구나 가이드라인을 참고할 수 있어요. 디지털 정부서비스 UI/UX 가이드라인의 목적 사용자 경험의 제고와 이용자 만족도 향상 사용자가 편리하고 효과적으로 서비스를 이용하기 위한 UI/UX의 일관적인 기준 사용자 경험 향상을 위한 접근 방법과 지침 제시 좋은 사용자 경험에 대한 방향성 제시 및 기준을 따르기 위한 방법 안내 UI/UX 개발 관리에 투입되는 비용 절약 소통 및 의사결정, 잘못된 설계로 인한 수정 및 보완에 드는 비용 및 노력을 줄임 이번 디지털 정부서비스 UI/UX 가이드라인은 지금까지 국내 공공·정부기관 주도로 만든 UX/UI 디자인 가이드 중 가장 고도화된 형태의 규준과 리소스를 제공해요. 이전에도 행안부에서는 이미 ‘모바일 전자정부 서비스 사용자 인터페이스 설계 지침(2011)’ 및 ‘전자정부 웹사이트 UI·UX 가이드라인(2019)’을 배포한 바 있어요. 하지만 영국(GOV.UK Design System), 미국(U.S. Web Design System), 싱가포르(Singapore Goverment Design System), 브라질(Design System Government Brazil) 등 해외 여러 국가에서 공공·정부 주도로 배포한 디자인 가이드에 비하면 PDF 및 HWP 문서 형태로만 만들어져 있어 편의성 및 활용성이 떨어졌죠. 작년 9월에는 미국 연방정부용 디자인 시스템인 미국 웹 디자인 시스템(USWDS) 버전 3.0이 업데이트됐어요. USWDS에서는 버전 2.0 출시 당시 디지털 전환에 맞춰 가독성을 고려해 개발한 오픈 소스 폰트 Public Sans를 공개하기도 했죠. 지난해엔 공정거래위원회에서 온라인 다크패턴* 자율관리 가이드라인을 제정하기도 했지만, 전자상거래 사업자들이 소비자 친화적 인터페이스를 마련하라는 취지의 자율 권고이기 때문에 강제성이 없는데다 공공 웹·앱과는 무관한 발표였고요. 반면 이번 UI/UX 가이드라인은 공공 웹·앱을 위해 마련한 디자인 시스템이라는 정체성을 뚜렷하게 드러내고 있어요. PDF 문서와 함께 스티키 테이블* 형태로 목차를 구분해둔 웹 페이지를 공개할 뿐만 아니라, 피그마(Figma) 파일로 된 컴포넌트 및 패턴 등 디자인 리소스까지 제공합니다. 다크 패턴(Dark Pattern)* 소비자의 착각, 실수, 비합리적 지출 등을 유도할 의도로 설계된 온라인 화면 배치. 사업자가 이득을 취하기 위해 속임수 질문을 넣거나, 결제 마지막 단계에서 예상하지 못한 요금이 추가로 나타나거나, 클릭 피로감을 유발하는 등 알아채기 어렵거나 사용자 행동을 의도적으로 방해하는 등의 인터페이스를 도입하는 것을 가리켜요. 스티키 테이블(Sticky Table)* 표(Table)의 헤더를 특정 위치에 고정해 둔 것. 위키 등 문서 형태의 웹 페이지에 스티키 테이블 헤더를 추가하면 문서의 목차(Index)가 글 한켠에 함께 띄워져 있어 원하는 내용을 바로 찾아보기 좋아요. 더욱이 가이드라인의 공식 명칭은 ‘디지털 정부서비스 UI/UX 가이드라인’이지만, 페이지 상단 로고 및 하단 푸터에 카피라이트를 표기한 ‘KRDS’라는 명칭에서도 ‘Korean Design System’의 약어임을 유추할 수 있어요. 즉 공공 웹·앱 사용자 편의를 고려해 제작된, 보다 실효성있는 형태의 디자인 시스템이 드디어 국내에도 선을 보인 셈이죠. IT 업계의 이목이 쏠리는 이유도 여기에 있고요! UI 디자인 · 프로토타이핑 툴 피그마(Figma)로 만든 컴포넌트, 패턴 등 다양한 디자인 리소스를 전용 파일(.fig)로 내려받을 수 있어요. KRDS 가이드라인 톺아보기 스티키 테이블로 목차를 잘 정리해 둔 KRDS 가이드라인. 이번 UI/UX 가이드라인을 좀 더 자세히 살펴볼까요? 해외 공공 웹·앱 디자인 시스템은 물론, 민간 기업에서 공개하는 디자인 시스템 못지 않은 수준으로 정리되어 있는데요. 가이드라인을 구성하는 5가지 수준 가운데, ‘원칙’을 뺀 나머지 4가지 수준은 UI/UX를 구성하는 세부 구성 요소에 해당해요. 원칙 : 디지털 정부서비스 UI/UX의 방향성과 설계 기준이 되는 상위 원칙 스타일 : 컴포넌트, 기본 패턴을 시각적으로 일관성 있게 표현하기 위한 규칙 컴포넌트 : 사용자 인터페이스의 가장 작은 단위로 과업에 상관 없이 일관성 있게 사용되는 공통 요소에 대한 가이드 기본 패턴 : 컴포넌트 요소들이 조합되어 핵심 과업을 수행하는 데 반복적으로 함께 사용되는 사용자 인터페이스 집합에 대한 가이드 서비스 패턴 : 디지털 정부서비스에서 제공하는 핵심 과업에 대한 사용자 여정 기반의 사용자 경험 설계 가이드 각 UI/UX 세부 구성 요소 역시 ‘사용자 중심의 서비스’, ‘모든 사용자를 포용하는 서비스’, ‘쉽게 이용하고 사용할 수 있는 서비스’ 등 총 7가지 디자인 원칙에 따라 정리되어 있어요. 스타일 가이드 역시 디자인 원칙을 따라 일관성(Consistency), 접근성(Accessibility) 그리고 효율성(Efficiency)을 핵심 방향성으로 제시하고 있습니다. 가령 접근성의 경우, 누구나 정보에 접근하는 데 불편함이 없도록 W3C 웹 콘텐츠 접근성 지침(WCAG) 레벨 AA 이상의 원칙을 따르고 있어요. WCAG에 따르면 색각 이상 등 장애 여부와 무관하게 사용자가 인지할 수 있고 탐색이 편리하며 안정적으로 해석될 수 있도록 적절한 색상과 대비, 글꼴 등을 선택해야 하죠. 정부 청색, 정부 회색, 정부 적색을 중심으로 UI 컬러 팔레트를 구성한 ‘색상(Color)’ 스타일 가이드. 서체(Typography) 관련 내용도 화제가 되었는데요. 중앙행정기관 사이트에서는 기본 글꼴로 구글 본고딕(Noto Sans KR) 기반으로 디자이너 길형진이 다듬어 제작한 Pretendard(프리텐다드) GOV를 채택하였다고 해요. 텍스트 계층 정의(Hierarchy)나 폰트 두께(Weight), 행간(Line height) 뿐만 아니라 반응형에 대응하기 위해 폰트 규격을 rem 값으로 정하되 개발 편의를 고려해 px 환산 기준값을 고지한 내용도 찾아볼 수 있죠. 이밖에 형태·배치·아이콘 등의 스타일도 가이드에 정의되어 있어요.  인프런 서비스에서도 웹폰트로 사용하고 있는 Pretendard. Pretendard GOV는 기존 Pretendard를 공공 서비스에 적합한 웹폰트로 최적화한 버전입니다. 정부 상징 로고를 사용하는 중앙 기관은 ‘아이콘(System Icon)’ 스타일 가이드를 통해 모서리 둥글기(Corner Radius)를 일반 공공 기관보다 엄격하게 제한함으로써 정적이고 신뢰감 있는 이미지를 부여하고 있어요. 대한민국 디지털 정부서비스임을 알리는 배너, 푸터, 식별자 등의 아이덴티티부터 탐색, 레이아웃 및 표현, 액션, 선택, 피드백, 도움, 입력 등 기능별로 필요한 다양한 컴포넌트 요소의 형태와 사용성 정의도 하나하나 확인할 수 있어요. 특정 단축키를 입력할 때 반응하는 상호작용 가이드라인, 스크린 리더 사용자를 고려해 웹 표준을 준수하기 위한 접근성 가이드라인 및 마크업 예시와 코드 등도 함께 명시되어 있죠. 사용자가 여러 옵션 중 한 개의 값을 선택할 때 쓰는 라디오 버튼(Radio) 컴포넌트의 접근성 가이드라인 및 마크업 예시. 웹 표준을 준수함으로써 장애나 연령, 기기 및 사양 등 다양한 환경과 조건에 구애받지 않는 웹 접근성을 모든 사용자에게 보장할 수 있어요. 각 컴포넌트 가이드에는 모범 사례와 피해야 할 사례가 함께 소개돼요. 텍스트 입력 필드(Text input)에는 플레이스홀더(Placeholder)를 도움말 대체 목적으로 쓰는 것을 지양한다고 되어 있어요. 적합한 컴포넌트를 조합해 마련한 UI 패턴(UI Pattern)을 기본 패턴과 서비스 패턴으로 구분한 점도 눈에 띄는데요. 기본적인 동작, 형태 및 용례를 정의하는 수준을 넘어서 설계 단계에서 사용자 여정 및 유저 상호작용을 서비스 관점으로도 면밀하게 살피려는 의도가 느껴지는 부분입니다. 가령 ‘신청’이라는 하나의 행동 안에도 제출, 조회, 발급, 예약 등 성격이 다른 여러 가지 요청이 모두 포함될 수 있는데요. 디지털 정부서비스 UI/UX 가이드라인은 사용자의 목적에 맞는 복잡한 행동을 유저 플로우(User Flow: 유저 여정)으로 자세히 정의해두고 있어요. 여러모로 실무자와 사용자를 고려해 세심하게 신경을 쓴 듯한 인상이 느껴지죠. ‘개인 식별 정보 입력’ 기본 패턴에는 사용자의 생년월일을 입력하기 위한 UI 요소로 날짜 선택기가 적합하지 않다고 적혀 있어요. ‘신청 - 유의 사항/자격 확인’ 서비스 패턴. 서식을 작성하기에 앞서 유의사항 및 자격을 확인하는 사용자 플로우를 상세히 명시해두었죠. 민원 등 신청을 제출한 뒤 내역을 조회할 수 있도록 하는 ‘신청 결과 확인’ 서비스 패턴. ‘모두를 위한 디자인’을 고민한다는 것  시작점을 만드는 일 디지털 정부서비스 UI/UX 가이드라인은 공개된 지 얼마 지나지 않아 IT 커뮤니티를 중심으로 화제에 오르고 있습니다. 완성도에 대한 칭찬과 비판, 앞으로에 대한 기대와 우려까지 다양한 의견이 들려오는 요즘이죠.  먼저 직관적이고 일관성 있는 UI/UX를 통해 디지털 행정서비스 사용 경험을 보완하려는 움직임 자체에 대해서는 여러 관심이 모이고 있습니다. 많은 공공 웹·앱이 기관 및 부서별로 각각 개발, 운영되면서 일관적인 UI/UX를 지켜 만들기 어렵기 때문이죠. 때문에 이번 가이드라인이 효율적인 UI/UX 개발 체계를 마련하기 위한 첫걸음이 될 거라는 기대의 목소리가 나오고 있어요. 물론 아쉽거나 우려되는 점도 있습니다. 발표 이후 신규 제작되거나 리뉴얼이 이루어질 웹·앱을 대상으로 한 가이드라인인 만큼 많은 웹·앱 프로덕트에 적용이 이루어지기까지는 적지 않은 시간이 걸릴 것으로 예상돼요. 더욱이 나라장터 입찰을 통해 개발 업체를 선정하는 공공 소프트웨어 사업 환경을 고려한다면 인력, 비용 등 여러 제약으로 인해 가이드라인을 충분히 적용하기 어려울 수도 있고요. 서비스마다의 다양성과 목적을 고려할 때 막상 가이드라인 적용이 적합하지 않은 부분이 있거나 도전적일 수도 있습니다. 지속적인 유지보수와 지원이 이뤄지지 않는다면 프로젝트의 실효성이 사라질 수밖에 없으니까요. 실제로 2018년 출시된 호주 정부 디자인 시스템은 프로젝트 지원이 점차 줄어들다 2021년 경 완전히 중단됐어요. 이후 오픈 소스 커뮤니티에서는 포크(Fork)를 통해 GOLD 디자인 시스템이라는 이름으로 명맥을 이어가려 했지만, 실질적으로 운영을 지속하지는 않고 있어요. 장애나 연령 등 사용자의 여건이 제약이 되지 않도록 웹 접근성을 고려하고, 실무에서 선호하는 UI 요소를 고심한 부분이 느껴지는 한편 용례로 구현한 코드나 각 패턴에 선택한 컴포넌트 요소 및 지원 범위 등에서 아쉬움이 있다는 비판도 있죠. 개인이 개발해, 자발적인 기여가 모여 만들어진 오픈소스 글꼴(Pretendard)을 웹 폰트로 채택한 점에 대해서도 우려 섞인 시선이 있고요. 이번 UI/UX 가이드라인은 네이티브 모바일 앱에 특화된 인터페이스는 고려하지 않았어요. ‘가이드라인 소개 - 가이드라인의 활용 방법 - 모바일 서비스의 UI/UX 개선’을 참고해 상황에 맞게 활용하면 된다고 고지되어 있죠. 다만 국내에도 디자인 시스템이라고 부를 만한 정부발(發) 기준이 처음으로, 그리고 대대적으로 마련되었다는 점은 무척 반갑게 느껴집니다. 공공 서비스에서 사용자 경험을 중요한 문제로 이해하고 개선하고자 하는 움직임이 구체적인 형태로 제시되었으니까요. 때문에 이번 가이드라인의 실효성을 위해서는 정부 및 공공기관에서의 적절한 계획, 꾸준한 지원, 지속적인 유지보수 및 평가와 개선이 이루어져야 하는 상황입니다. 뿐만 아니라 민간에서도 관심을 기울이고 목소리를 모아야 더욱 개선된 공공 웹·앱 사용 환경을 만들어갈 수 있겠죠. 디지털 정부서비스 UI/UX 가이드라인 PDF 문서에 부록으로 실린 용어집. 디자인 시스템은 프로덕트의 목적에 맞는 디자인을 일관성 있게 적용할 수 있도록 정의한 규칙이에요. ‘모두를 위한’ 공공 서비스에 맞는 디자인을 고민한다는 것, 그럼으로써 프로덕트를 더욱 편리하고 효율적인 방식으로 만들어나가기 위한 밑바탕을 마련하는 일의 의의와 목적을 함께 생각해 보면 좋을 것 같습니다. 이번 ‘디지털 정부서비스 UI/UX 가이드’, 여러분은 어떻게 보고 계신가요? 함께 보면 좋을 사례나 나누고 싶은 이야기가 있나요? 여러분의 의견을 댓글로 함께 들려주세요. 😊 함께 보면 좋은 강의 add_shortcode('course','332289,330677,329506,332865,332523,332808,331185,325638,326063','card','card1') 나의 성장을 돕는 IT/커리어 콘텐츠, 인프메이션 구독하면 먼저 빨리 알려드려요. 이번 인프메이션 어떠셨나요? 💌 의견 보내기 빠르게 받아보는 새 글 🔔 소식 알림 ON 지난 글이 궁금하다면 📚 인프메이션 모아보기