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