담백한 웹 개발 이야기

HSL 휘색(Hue) 휘색은 색상의 종류를 나타내는 각도로 표현되며, 휘색은 빨강, 노랑, 초록, 파랑, 남색, 보라 등의 기본적인 색상을 나타냅니다. 0도부터 360도까지의 값을 가질 수 있습니다. 예를 들어, 빨간색은 0도, 노란색은 60도, 초록색은 120도, 파란색은 240도 등으로 표현됩니다. 채도(Saturation) 채도는 색상의 순수도를 나타냅니다. 채도 값은 0%에서 100% 사이의 값을 가집니다. 100%일 때 색상은 최대 순수도를 가지게 되고, 0%일 때 색상은 회색으로 표현됩니다. 밝기(Lightness) 밝기는 색상의 밝기를 나타냅니다. 밝기 값은 0%에서 100% 사이의 값을 가집니다. 0%일 때 색상은 완전한 검은색으로 표현되고, 100%일 때 색상은 완전한 흰색으로 표현됩니다..

먼셀의 색체계(Munsell color theory) 미국의 화가이자 색채 교육자 앨버트 헨리 먼셀(Albert Henry Munsell)은 색의 세 가지 속성인 색상(Hue), 명도(Value), 채도(Chroma)에 따라서 색상을 배치했다. 1927년 'The Munsell Book of color'을 발간하여 색체계를 확립하였고, 1940년 먼셀의 색체계는 감각적인 척도의 불규칙성으로 인해 미국 광학회(OAS)에 의해 'Munsell renotation'으로 수정되었다. 먼셀의 색체계 특징 지각적인 통보에 따른 감각적 색체계를 구성 빨강, 노랑, 초록, 파랑, 보라로 각각 다른 명도를 부여하여 인간의 시감 밝기에 따라 가장 높은 채도의 색을 각각 다른 명도로 부여함 먼셀의 색체계 세가지 속성 색상(..

인증은 영어로 Authentication이고, 인가는 영어로 Authorization이다. 로그인이나 권한 관리 쪽을 개발자가 아니면 자주 사용되지 않은 용어이고, 한글과 영어로 표기와 의미도 비슷하기 때문에 간혹 혼동하기도 한다. 동료들과 협업을 할 때 커뮤니케이션 미스가 발생되지 않도록 단어 풀이를 통해 명확히 의미를 이해해 보자. 인증 인증은 한자로 認(알 인) + 證(증거 증)을 조합으로 만들어졌다. 풀이로는 "어떤 행위가 정당한 절차로 이루어졌는 것을 기관을 통해서 증명했다"라는 의미이다. 인증은 영어로 Authentication이다. Authentication은 "인증된"이라는 의미의 Authentic의 명사인데, Authentic를 풀어쓰면 Auto(스스로) + hen(무언가를 해서) + t..

카카오 i 오픈 빌더 서비스의 프런트 엔드 개발자로 있을 때, 디자인 설계팀에서 서비스 사용 후 사용성 개선사항을 피드백해 주신 내용을 정리했습니다. 기능에 대한 가이드 부족 1) 초기 접근 시 무엇/어떻게 하면 챗봇을 만들 수 있는지 제공이 필요 2) 기본 기능의 역할/활용 방법을 파악하기 쉽게 해야 함 3) 계층 관계가 있는 데이터의 하위 데이터를 표시할 때 상위 데이터 표기 필요 4) 해당 위치에 맞는 툴팁이 필요함 기능 파악이 어려움 1) 기능이 활성화되기 전에 가이드 영역이 활성화되므로 기본으로 노출 필요 2) 동일한 기능이 워딩이 같게 해야 함 3) 다른 동작의 기능은 각자 다른 아이콘을 사용해야 함 사용자 액션에 대한 피드백이 부족 1) 버튼을 클릭하더라도 피드백이 없을 때 오류라고 느낄 수..

규칙을 전부 마스터하면 뭐든지 할 수 있다. 심지어 규칙을 파괴할 수도 있다. 그런데 체계가 아예 없으면 시작조차 할 수 없다. 에드워드 펠라 (Edward Fella, 현 미국 칼아츠의 디자인교수, 디지털 그래픽 디자인의 선구자) ​ 디자인을 주간적인 감각이 뛰어난 사람만 잘 할 수 있다는 의견들을 많이 들었습니다. 하지만 디자인은 단순히 감각적으로 하는 것이 아닌 객관적인 근거를 바탕으로 디자인을 하는 것입니다. 이 글에서는 디자인 요소들을 작업할 때는 각 요소별로 심리학적으로 접근하는 방법과 통계적으로 접근하는 방법을 설명합니다. ​ ​ 개요 ​ 레이아웃 색상 타이포그래피 사진편집 UI 컴포넌트 강조하기 ​ ​ 레이아웃 전체는 단순히 부분의 합이 아니다 Kurt Koffka 쿠르트 코프카(독일 심리..

서비스를 개발하면서 많은 코드를 작성한다. 그 코드들 속에 중복적인 요소 또는 로직은 항상 존재하며 추상화를 통해 반복적인 작업을 줄일 수 있다. 추상화를 하는 과정은 중복적인 요소 또는 로직을 공통화하고, 결과적으로 재사용성을 높인다. 추상화는 요구사항 수정 시, 수정 범위를 최소화하기 때문에 구조 설계에 있어서 필수적인 과정이라고 할 수 있다. 추상화는 일반화와 단순화로 설명된다. 아래에서 자세히 알아보자. 일반화일반화는 우리가 작성하는 코드에서 중복적인 요소 또는 로직을 찾아 공통화하는 것을 의미한다. 이 말대로 하면 두가지 과정으로 일반화가 이뤄진다. 1. 중복적인 요소 또는 로직을 파악한다. 2. 중복적인 요소를 성격에 따라 공통화 한다. 공통화여기서 공통화는 중복적인 요소의 성격에 따라 다르게..

글의 목적프로라면 어떤도구를 사용하든 기능 요구사항은 당연히 구현가능해야 된다고 생각한다. 문서로는 소프트웨어를 완변하게 설계했지만, 소프트웨어가 의도한 데로 동작하지 않다면 문서를 작성한 노력과 소프트웨어 개발한 노력은 인정받기 힘들다. 소프트웨어의 품질을 높이기 위해서는 비기능 요구사항이 충족해야 한다. 비기능 요구사항은 개발이나 유지보수, 운영, 컴퓨터 리소스의 효율적 활용에 커다란 영향을 미친다. 배포 후 운영 시 발생하는 장애의 대부분 비기능적인 특성에 기인한다. 그만큼 중요한 사항임에도 비기능은 기능에 비해 경시되고 있으며 이를 별도로 주목하지 않고 뒤로 미루려는 경향이 있다. 비기능 요구사항의 관점들이 무엇이 있는 지 정리하기 위해 작성된 포스트다. 비기능 요구사항비기능 요구사항이란 기능 외..

웹 접근성 월드 와이드 웹을 창시한 팀 버너스리는 웹이란 장애에 구애 없이 모든 사람이 손쉽게 정보를 공유할 수 있는 공간이라고 정의하였으며, 웹 콘텐츠를 제작할 때에는 장애에 구애됨이 없이 누구나 접근할 수 있도록 제작하여야 한다고 하였다. 이는 모든 사용자가 신체적, 환경적 조건과 관계없이 웹에 접근하여 이용할 수 있도록 보장하는 것을 뜻한다. 여기서 신체적 조건이란 일반 사용자는 물론, 장애를 가진 사람, 고령자 등을 의미하고 환경적 조건이란 다양한 기기, OS, 웹 브라우저를 의미한다. 접근성이란 보다 많은 사람이 이용할 수 있는 보편적 접근의 정도를 의미하며 장애인뿐만 아니라 모든 사람이 정보통신 기기나 서비스를 손쉽게 활용할 수 있게 하는 것을 의미한다. 장애인 차별 금지법(이하 장차법) 20..

이 포스트는 컴파일러 개념과 문법이 어떻게 만들어지는 학습하고자 정리한 자료다. ​ 우선 컴파일러는 밑바닥부터 구현하는 경우는 드물다. 보통 토큰화 모듈이나 문법 분석기를 만들 때, Flex(어휘분석기)와 bison(파서 생성기)같은 컴파일러 생성기 도구들을 이용해서 만든다. 이 도구들은 문맥 자유 문법를 입력하면, 그 문법으로 작성된 프로그램을 토큰화하고 분석하는 문법 분석 코드를 출력한다. 그리고 컴파일 조건에 맞춰 생성 코드를 수정할 수 있다. ​ 컴파일러 개념​​ 컴파일러는 원본 언어에서 대상 언어로 번역하는 프로그램이다. 컴파일러는 번역 과정을 개념적으로 문법 분석과 코드 생성이라는 두 단계로 나뉜다. ​ 문법 분석(Syntax Analysis) 원본 언어의 문법을 이해하고, 원본 언어를 추상 ..

들어가며 2019년 9월부터 회사 내부에서 사용하는 신규 서비스를 담당하게 되었습니다. 서비스는 회사 내부에서만 사용되기 때문에 정식 명칭을 사용하지 않고, 신규 서비스라는 명칭을 사용하겠습니다. 이직 후 신규 서비스를 혼자 담당하는 것은 처음이라 지금까지 서비스를 운영하면서 쌓았던 경험에 신규 서비스를 하면서 쌓은 경험을 더하여 공유하고자 이 글을 정리하게 되었습니다. 정리한 글은 지금까지 제가 경험했던 내용을 정리한 내용이라 정답이 아닐 수 있습니다. 하지만 신규 서비스를 개발할 예정이거나 하는 분들에게 소소한 정보가 되었으면 합니다. 이 글의 순서는 이렇게 정리했습니다. 글의 순서 꼼꼼하게 요구사항 분석 하기 구현 전에 구조 설계하기 코딩룰 정하기 의미 있었던 코딩 가이드라인 5가지 꼼꼼하게 요구사..

경험정리에서는 10년간 20개 이상의 프로젝트에서 경험한 지식과 생각을 담았습니다. 서비스를 개발하면서 뭔가 명확한 기준을 세워서 개발하는 것을 좋아합니다. 내 스스로가 왜 이렇게 했는지 납득할 수 있어야 하고 동료들에게 왜 이렇게 했는지 설명하기 위해서 명확한 기준을 세우는 것을 중요하다고 생각합니다. 개발자로 있으면서 경험은 되게 중요합니다. 책이나 사이트의 글을 보고 지식을 쌓은 것은 단순히 정보에 불과합니다. 그 정보를 서비스에 적용하거나 동료들과 논의해서 새로운 정보를 만들어 본인의 경험을 만드는것이 더욱 좋습니다. 그리고 경험은 머리속에서만 있으면 기억에 의존하기때문에 잘못된 기억을 되집기도 합니다. 코딩을 하면서 문법이나 동작을 보고 이게 왜 이렇게 동작하는지 호기심이 생기곤합니다. 호기심은..