과거 개발자로 일했다. 하지만 최근에는 책을 쓰고 있다. 요즘 프로그램을 만드는 것과 책을 만드는 것이 같다는 생각이 자주 든다. 독자 입장에서 코드를 읽는 것은 책을 읽는 것과 같다. 이 글에서는 코드와 책의 구조에서 구체적으로 대응되는 요소들을 살펴보겠다.
주변 코드를 짜는 IT 개발자들과 이야기하면 늘 주제로 나오는 이야기가 있다. 클린 코드에 관한 이야기다. 클린 코드에 대해 고민을 많이 하시는 것 같다. 클린 코드의 기준 중 가독성이라는 성질이 있는데, 가독성 좋은 코드는 동료 개발자들이 쉽게 이해할 수 있는 코드를 쓰는 것이다. 이 가독성이 왜 좋은 코드의 기준일까?
첫째, 동료 시간들을 아껴준다.
IT 회사를 다니는 개발자라면 코드를 쓰는 시간보다 코드를 읽는 시간이 많다는 사실을 잘 안다. 내가 다녔던 소규모 회사도 코드가 수십 개 파일에 수백, 수천 줄이었는데 대기업은 오죽할까? 마이크로아키텍처라도 말이다. 만약 에러가 발생하면 프로그램 어느 부분에서 에러가 발생했는지 코드 속을 헤매며 디버깅한다. 다행히 읽기 쉬운 코드라면 쉽지만, 읽기조차 난해하다면 힘들지 않을까?
둘째, 나의 시간도 아껴준다.
혼자서 코드를 짜기 때문에 가독성을 신경 쓰지 않아도 된다고 주장하는 사람도 있다. 단도직입적으로 말하면 당신이 컴퓨터로부터 에러를 받는 순간 어제의 당신이 미워질 것이다. 당신이 하나의 프로그램만 짜는 것은 아니지 않은가? 회사에서 A프로젝트, B프로젝트 등 그 순간 코드가 읽기 쉽지 않다면 어느 코드가 어느 프로그램인지 곧바로 파악되기 어려울 것이다. 할 수 있겠지만 당신의 뇌는 맥락을 찾느라 무척 괴로울 것이다.
이렇게 좋은 장점이 많기 때문에 시중에는 가독성 좋은 코드를 위한 책들이 많다. 클린코드, 리팩토링2, 읽기 쉬운 코드가 좋은 코드다 등. 이 책에서는 변수, 함수, 클래스, 모듈 등 다양한 수준과 측면(컴퓨터의 관점, 사람의 관점)에서 정의가 있다. 가독성이라는 기준에서 무수히 좋은 책들이 많다. 꼭 읽어보시길 추천한다.
그렇다면 읽기 쉬운 코드 구조는 어떨까? 분명 한국에 있는 개발자나 미국 개발자, 전 세계 개발자가 협업한다면 인류를 공통으로 묶어주는 구조가 있을 것이다. 질문을 바꿔보자. 인류가 남긴 문화 중 어떤 구조와 닮았을까? 우리는 알게 모르게 삶에서 같은 구조를 활용한다. 바로 모든 사람의 집에 한 권씩 있는 책이다. 그래서 이 글은 책과 프로그램의 구조를 비교하는 것에 관한 글이다.
1. 책의 목차 Vs 디렉토리 구조
책의 목차는 프로그램의 Repository 디렉토리 구조와 대응된다. 목차는 책의 주요 Section들을 나열해 독자가 책의 구조를 한눈에 파악할 수 있게 돕는다. 이는 프로그램에서 디렉토리 구조와 역할이 비슷하다. 디렉토리 구조는 여기서 코드 파일까지 포함한다고 정의하자. 이때 폴더와 파일명은 전체 프로그램에서 이 내용물의 목적과 구성, 역할을 명시하는 것이다. 마치 큰 그림에서 전체와 부분 같다.
1.1 책 목차
독서의 기술이란 책에서 발췌한 목차다. 이는 독서의 기술 내용을 어떤 구조로 설명하는지 안내한다.
1.2 코드베이스의 디렉토리 구조
디렉토리 구조는 코드의 내용물이 어떻게 구성되어 있는지 설명하고 있다.
2. 책의 서문 Vs 코드베이스의 README.md, Config File
서문은 책의 목적, 배경, 저자의 의도 등을 소개한다. 이는 프로그램의 README 파일이나 초기 설정 코드(Config)와 대응될 수 있다. 프로젝트의 루트 디렉토리에 위치한 README 파일은 프로젝트의 목적, 사용 방법, 설치 방법, 라이선스 정보 등을 제공한다. 이는 서문이 책에 대한 도입부를 제공하는 것과 유사하다. 또한 프로그램이 시작할 때 실행되는 초기 설정 코드(예: 설정 파일을 읽어오는 코드, 전역 변수를 초기화하는 코드 등)는 프로그램의 작동 방식과 구성을 설정한다.
2.1 책의 서문
- 예상 독자
- 책을 쓰게 된 배경
- 책의 주제
- 독자가 얻게 될 이익
- 다른 책과의 차별점
- 책의 구성 및 활용
2.2 README.md
- 프로젝트 구성
- 프로젝트 프로그램 설치방법
- 프로젝트 프로그램 사용법
- 저작권 및 사용권 정보
- 프로그래머 정보
- 버그 및 디버그
- 참고 및 출처
- 버전 및 업데이트 정보
- FAQ
3. 책 전체에서 사용할 용어 정의 vs 전역 변수
책 전체에서 사용할 용어를 독자에게 알리는 것이 서문에서 해야 할 일이라면, 전역변수는 프로그램 시작할 때 설정으로 주입하거나 전역 변수로 선언하는 것이다. 다음 예시를 보자.
3.1 책에서 사용할 용어 정의
김주환 작가의 내면 소통이라는 책에서 서문을 발췌했다. 이 책 전체에서 사용할 용어인 경험자아, 기억자아, 배경자아를 서문에서 정의한다.
3.2 전역 변수
tailwind.config.js에서 사용할 전역변수들을 선언한다. 아래 예시는 요소의 기본 단위를 rem 대신 px 단위로 설정하는 코드다.
4. 특정 단락에서 사용할 용어 vs 지역 변수
각 Section마다 사용할 단어를 각 장의 첫 단락에서 선언하는 것과 지역변수는 대응된다. 특히 지역적(Regional) 용어는 Section이나 단락과 가장 가까운 곳에서 선언하는 것처럼 지역변수도 사용하는 곳에서 최대한 가까운 곳에 선언하는 것이 권장된다.
4.1 책의 특정 단락에서 사용할 용어
마찬가지로 김주환 작가의 내면 소통이라는 책에서 해당 부분을 발췌했다. 실천적 명상을 안내하는 Section 시작 지점에서 사용할 명상 용어인 사띠를 정의한다.
4.2 코드의 지역 변수
사용할 변수/함수는 사용하는 곳 가까이에서 선언한다.
5. 책 Section 내의 소제목 vs 코드의 함수명
소제목과 함수명 모두 해당 부분의 내용이나 기능을 명확하게 반영해야 한다는 공통점으로 묶을 수 있다. 이를 통해 개발자와 독자는 해당 부분이 무엇에 관한 것인지 쉽게 이해할 수 있다.
5.1 책의 소제목
사고의 본질이란 책에서 발췌한 소제목이다. 단어보다 훨씬 많은 범주라는 것, 결국 한 단어가 맥락에 따라 여러 범주에 속할 수 있다는 것을 예상해볼 수 있다.
5.2 코드의 함수명
isLoggedInUserButton이라는 컴포넌트로, 로그인 상태에 따라 나눈 버튼 컴포넌트다.
6. 다른 문헌 인용 vs 라이브러리 의존성
프로그램 개발을 접하면 외부 라이브러리 의존성 주입이라는 말이 있다. 이는 자신이 만들 프로그램에서 사용할 다른 사람의 라이브러리를 명시하는 것이다. 이처럼 책에도 참고 문헌이 있다. 다른 사람이 만든 라이브러리를 사용하는 것은 책에서 다른 문헌을 인용하는 것과 대응된다. 이를 통해 기존의 작업에 기반하여 더 나은 결과를 도출할 수 있다는 공통점이 있다. 이들은 각각의 분야에서 재사용 가능한 요소를 활용하는 방법이다. 실제 예시를 보자.
6.1 다른 문헌 인용
내면 소통이란 책에서, 사용할 외부 패키지인 자유에너지 최소화 법칙을 인용한다.
6.2 라이브러리 의존
프로그램이 사용할 외부 패키지의 특정 변수, 함수, 모듈을 가져온다(import).
혹시 차이점이라면?
단지 차이라면 프로그램은 컴퓨터에게 일을 시키기 위함이기 때문에 명령 내리는 규칙을 따라야 하는 것이다. 사실 이것 또한 어릴 때 백일장에 썼던 원고지의 문법을 생각한다면 비슷하다.
결론
누구든지 처음 코드를 접하고 시작하는 시절이 있다. 나는 처음 코드를 봤을 때 마치 외계어를 읽는 듯한 느낌이 들었다. 내가 느낀 것처럼 누구나 처음부터 가독성 좋은 코드를 짜지 못한다. 나 역시 좋은 코드를 작성하지 못했던 시절이 있었고, 시간이 지나 프로그래밍이 쉬워졌다고 오만해진 적도 있다. 그래서 이 글은 독자뿐만 아니라 나를 위한 글이다.
당신이 만약 개발자라면 책을 읽고 글을 쓰는 습관을 들이면 코드 짜는 데도 도움 될 것이라 믿는다. 또 당신이 만약 글 쓰는 사람이라면 개발자로 직무 전환을 시도할 때 당신이 썼던 글들이 도움 될 것이라 믿어도 된다. 구조의 연관성을 파악하는 데 이 글이 도움이 되었으면 한다.
또한 글의 구조를 잘 파악한다고 해서 글을 잘 쓰는 것이 아닌것처럼 코드의 구조를 잘 이해한다고 해서 프로그램을 잘 만드는 것을 의미하지 않는다. 좋은 예술 작품이 창작자의 고통을 수반하듯, 좋은 프로그램도 마찬가지다. 좋은 작품은 꼼꼼하고 철저한 관점을 수반한다. 좋은 글이 쉽게 쓰이지 않듯, 좋은 프로그램도 쉽게 만들어지지 않는다.
특히 아직 개발자가 아니지만 개발자가 되고 싶고 좋은 코드를 짜고 싶다면, 그전에 먼저 좋은 책과 글을 많이 읽고 써보길 추천한다. 좋은 글이 쉽게 나오지 않듯, 좋은 프로그램도 쉽게 만들어지지 않기 때문이다.