구문 하이라이팅을 도구답게 쓰는 법. 색을 최소화하고 무엇을 강조할지 선택해 읽기와 탐색을 빠르게 만드는 원칙과 예시, 라이트/다크 테마에서의 색 사용, 주석 처리, 배경색 트릭까지 실전 가이드를 담았습니다.
번역들: 러시아어
구문 하이라이팅은 도구다. 코드를 더 빨리 읽고, 더 빨리 찾고, 큰 파일 속에서 방향을 잡는 데 도움을 줄 수 있다.
모든 도구가 그렇듯, 올바르게 쓸 수도, 잘못 쓸 수도 있다. 구문 하이라이팅을 일을 돕게 쓰는 법을 살펴보자.
대부분의 컬러 테마는 사실상 모든 것에 독특하고 밝은 색을 부여한다. 변수 하나, 언어 키워드 하나, 상수 하나, 구두점 하나, 함수, 클래스, 호출, 주석 등등.
가끔은 너무 심해서 기본 텍스트 색이 보이지 않을 정도다. 모든 게 하이라이트되어 있다. 여기서 기본 텍스트 색은 뭐지?
문제는, 모든 게 하이라이트되면 아무 것도 두드러지지 않는다는 것이다. 눈이 거기에 적응해 그걸 새로운 기준으로 받아들인다. 전부가 밝고 번쩍거려서, 분리되기는커녕 전부가 뒤섞여 보인다.
간단한 테스트. 여기서 함수 정의를 찾아보라:
그리고 여기서는:
무슨 말인지 알겠는가?
그러니까, 불행히도 모든 것을 하이라이트할 수는 없다. 결정을 내려야 한다. 무엇이 더 중요하고, 무엇이 덜 중요한지. 무엇을 돋보이게 하고, 무엇은 그렇지 않게 둘지.
모든 것에 하이라이트를 주는 건 Linear에서 모든 태스크에 “최우선”을 부여하는 것과 같다. 대부분의 태스크가 더 낮은 우선순위를 가질 때만 작동한다.
모든 것이 하이라이트되면, 아무 것도 하이라이트되지 않은 것이다.
컬러 테마가 해결해야 하는 주된 사용 사례는 두 가지다:
1은 정방향 색인 조회다: 색 → 대상의 종류.
2는 역방향 조회다: 대상의 종류 → 색.
사실은, 대부분의 사람은 이런 조회를 전혀 하지 않는다. 한다고 생각할지 몰라도, 실제로는 하지 않는다.
예를 들어 보자. 전/후 비교:
이후:
보이겠는가? 내가 return을 retunr로 잘못 쳐서 색이 빨강에서 보라로 바뀌었다.
난 못 보겠다.
또 다른 테스트. 눈을 감고(아직은 말고! 이 문장을 다 읽은 뒤에) 당신 테마에서 클래스 이름이 무슨 색인지 기억해 보라.
기억나는가?
두 질문 모두 답이 “아니오”라면, 당신의 컬러 테마는 기능적이지 않다. 편안함은 줄 수 있다(즉—안심되는 느낌. 하이라이트되어 있으니 아마 코드겠지). 하지만 도구로 쓸 수는 없다. 당신을 돕지 못한다.
해결책은? 색을 절대 최소한으로 줄여라. 전부를 한 번에 머릿속에 넣고 기억할 수 있을 정도로. 예를 들어 내 컬러 테마 Alabaster는 네 가지만 쓴다:
끝! 그리고 난 이것들을 다 암기한 채로 타이핑할 수 있다. 이런 미니멀리즘 덕분에 실제로 조회를 할 수 있다. 문자열을 찾고 있다면 초록을 보면 된다. 노란 걸 보고 있다면 그건 주석이다.
서로 다른 색의 수를 당신이 기억할 수 있는 만큼으로 제한하라.
내 에디터에서 초록과 보라를 바꿔치기하면 재앙이다. 당신 테마에서 누가 색을 바꿔놔도, 눈치나 챌까?
많지 않은 것. 기억하라—우리는 하이라이트가 두드러지길 원한다. 그래서 나는 변수나 함수 호출을 하이라이트하지 않는다—이것들은 어디에나 있고, 당신 코드의 75%는 아마 변수 이름과 함수 호출일 것이다.
나는 상수(숫자, 문자열)는 하이라이트한다. 보통 더 드물게 쓰이고, 종종 기준점 역할을 한다—많은 논리의 시작점은 상수에서 출발한다.
최상위 정의를 강조하는 것도 좋은 생각이다. 구조를 빠르게 파악할 수 있다.
구두점: 이름과 문법을 약간 분리하는 데 도움이 되고, 특히 코드를 훑어볼 때는 이름이 먼저 중요하다.
제발, 제발 언어 키워드는 하이라이트하지 마라. class, function, if, else 같은 것들. 그런 걸 찾는 경우는 드물다. “그 if 어디에 있지” 같은 질문은 타당하지만, 그때 보는 건 if 키워드가 아니라 그 뒤의 조건일 것이다. 중요한, 구분되는 부분은 조건이다. 키워드는 아니다.
이름과 상수를 하이라이트하라. 구두점은 옅게 하라. 언어 키워드는 하이라이트하지 마라.
주석을 회색으로 쓰는 전통은 사람들이 줄 수로 돈을 받던 시절에서 왔다. 만약 다음과 같은 게 있다면
물론 회색으로 죽이고 싶을 것이다! 아무 것도 더하지 않는 헛소리 텍스트이며, 무시되라고 쓰인 것이다.
하지만 좋은 주석에는 정반대다. 좋은 주석은 코드에 더한다. 직접 표현할 수 없던 것을 설명한다. 중요하다.
그래서 또 하나의 논쟁적인 아이디어:
주석은 숨기지 말고, 하이라이트해야 한다.
진한 색을 쓰고, 주의를 끌어라. 주저하지 마라. 누군가 시간을 들여 무언가를 알려주었다면, 당신은 그것을 읽고 싶을 것이다.
아무도 말하지 않는 비밀이 또 있다. 주석에는 두 종류가 있다:
대부분의 언어는 둘을 구분하지 않으므로, 문법 차원에서 할 수 있는 게 많지 않다. 가끔 관례가 있다(예: SQL에서 -- vs /* */). 그렇다면 그걸 활용하라!
다음은 Clojure 코드베이스에서 두 종류의 주석을 완벽히 활용한 실제 예다:
비활성화된 코드는 회색, 설명은 밝은 노란색
통계에 따르면, 개발자의 70%는 다크 테마를 선호한다. 나는 나머지 30%에 속하는데, 늘 궁금했다. 왜일까?
이제 답을 알 것 같다. 전형적인 다크 테마는 이렇다:
그리고 라이트 테마는 이렇다:
후자에서는 색이 훨씬 덜 선명하다. 내가 골라내 보았다:
색이 얼마나 많은지 보라. 저만큼을 기억할 수 있는 사람은 없다.
이는 일반적으로 어두운 색이 덜 구분되고 더 탁하게 보이기 때문이다. 밝기를 낮추며 색상(Hue) 스케일을 보라:
요컨대, 스펙트럼의 어두운 쪽에서는 가지고 놀 수 있는 색의 수가 줄어든다. “어두운 노란색”이나 보기 좋은 “어두운 청록”은 사실상 없다.
여기서 할 수 있는 건 없다. 하얀 배경에서 대비도 좋고 동시에 보기에도 좋은 마법의 색 따위는 어딘가에 숨어 있지 않다. 라이트 테마를 선택하는 순간, 매우 제한되고, 보기 안 좋고, 거의 구분되지 않는 어두운 색 세트를 떠안게 된다.
그래서 이해가 된다. 다크 테마가 더 좋아 보인다. 아니, 정확히는: 라이트 테마는 잘 보일 수가 없다. 과학이 그렇다 ¯_(ツ)_/¯
하지만!
하지만.
내가 자주 보지 못한, 쓸 수 있는 요령이 하나 있다. 배경색을 써라! 비교해 보자:
첫 번째는 색은 좋지만 대비가 너무 낮아 글자가 읽기 어렵다.
두 번째는 대비는 좋지만 색이 거의 보이지 않는다.
마지막은 둘 다 있다: 높은 대비와 깨끗하고 선명한 색. 밝은 색도 면적을 더 크게 채우면 흰 배경에서도 읽기 좋다. 텍스트의 밝기는 두 번째 예와 같지만, 색이 더 또렷하게 보이는 인상을 준다. 사실상 이점뿐이다.
UI 디자이너들은 이 요령을 오래전부터 알고 있었지만, 코드 에디터에서는 거의 보지 못했다:
에디터가 배경색 선택을 지원한다면, 시도해 보라. 라이트 테마의 가능성이 열릴지 모른다.
쓰지 마라. 이것도 색을 너무 많이 쓰는 문제와 같은 부류다. 하이라이트 방식이 하나 더 늘어나는 것뿐이고, 너무 많이 가질 필요가 없다. 모든 것을 하이라이트할 수는 없기 때문이다.
이론적으로는, 색을 타이포그래피로 대체해 볼 수도 있다. 그게 통할까? 모르겠다. 그런 예시는 본 적이 없다.
색 대신 이탤릭과 볼드를 사용한 사례
일부 테마는 과학적으로 균일해 보이는 데 과도한 신경을 쓴다. 모든 색이 완전히 같은 명도이고, 색상은 원 위에 고르게 분포하는 식으로.
이게 멋질 수는 있다(만약 당신이 OCR이라면), 하지만 실제로는 생각만큼 잘 작동하지 않는다:
OkLab l=0.7473 c=0.1253 h=0, 45, 90, 135, 180, 225, 270, 315
하이라이트의 목적은 것들을 돋보이게 만드는 것이다. 모든 색의 명도와 채도를 같게 만들면 서로 매우 비슷해 보여 구분하기 어려워진다.
우리 눈은 색 차이보다 명도 차이에 훨씬 더 민감하므로, 그 점을 활용해야지 거스르려 들면 안 된다.
이 원칙들을 단계별로 적용해 어디로 가는지 보자. 이 글 맨 앞의 테마에서 시작한다:
먼저, 언어 키워드에서 하이라이트를 제거하고 기본 텍스트 색을 되살린다:
다음으로, 변수 사용부에서 색을 제거한다:
그리고 함수/메서드 호출에서도 제거한다:
생각은 이렇다. 당신 코드의 대부분은 변수 참조와 메서드 호출이다. 그것들을 하이라이트하면, 코드의 75% 이상을 하이라이트해야 한다.
변수 선언은 유지한 것에 주목하라. 이것들은 그렇게 흔하지 않고, 흔한 질문—“이건 어디서 왔지?”—에 빠르게 답하는 데 도움이 된다.
다음으로, 구두점을 톤다운한다:
나는 약간 어둡게 두는 편을 선호한다. 그러면 이름이 더 돋보인다. 이름만 봐도 무슨 일이 일어나는지 대략 감이 오고, 괄호 배치 같은 정확한 구성은 보통 그만큼 중요하지 않다.
물론 기본색 구두점으로도 갈 수 있다:
좋다, 거의 다 왔다. 주석을 하이라이트하자:
여기서 빨강은 쓰지 않는다. 보통 물결 밑줄이나 오류 표시용으로 필요하기 때문이다.
아직 색이 하나 너무 많으니, 숫자와 문자열을 통일해 둘 다 초록을 쓰자:
마지막으로, 색을 조금 회전시킨다. 중첩 구조의 논리를 존중하려면, 함수 선언이 변수 선언보다 더 밝아야 한다(변수는 파랑, 함수는 노랑).
우리가 어디서 시작했는지와 비교하라:
내 생각엔 훨씬 더 실용적인 컬러 테마를 얻었다. 눈이 덜 피곤하고, 원하는 것을 더 빨리 찾게 도와준다.
나는 이 원칙들을 약 8년째 적용해 오고 있다.
이 테마를 Alabaster라고 부르고, 내가 쓰는 에디터들에 몇 번 만들어 넣었다:
다른 많은 에디터와 터미널로도 포팅되었고, 가장 완전한 목록은 아마 여기에 있다. 당신의 에디터가 목록에 없다면, 이름으로 검색해 보라—이미 기본 내장되어 있을지도 모른다! 예전엔 이런 컬러 테마들이 어디서 오는지 궁금했는데, 이제는 내가 그중 하나의 저자가 되었다(여전히 잘 모른다).
이 글에서 말한 원칙들로 직접 테마를 만들거나, 그냥 Alabaster를 그대로 써도 좋다—둘 다 상관없다.
원칙들 자체는 내게 아주 훌륭히 작동했다. 돌아가고 싶은 적이 없고, 이제는 ‘전통적인’ 컬러 테마는 보기만 해도 겁이 난다.
아마 우리가 더 절제된 컬러 테마를 보지 못하는 유일한 이유는, 사람들이 정말로 생각해 본 적이 없기 때문일 것이다. 자, 이것이 당신의 웨이크업 콜이다. 더 의도적으로 색을 쓰고, 기본적으로 컬러 테마를 만들고 사용하는 방식을 바꾸는 데 영감을 주었으면 한다.
