미니멀리즘 프로그래머: 복잡함을 버리는 개발자의 자세
목차
프롤로그
어느덧 개발 실무 경력이 5년 차에 접어들며, 시니어의 단계로 나아가고 있다.
우리 팀 PL(Project Leader)님이 긴 휴가로 자리를 비우게 되면서, 그 공백을 채우기 위해 나에게 '부 PL'이라는 역할이 부여되었다.
솔직히 부담이 컸다. 기존의 개발 업무를 병행하면서 회의를 정리하고, 발생하는 이슈들을 파악해 팀원들에게 적절히 분배하는 리딩 업무까지 수행해야 했기 때문이다. 개발에만 몰입하던 때와 달리 프로젝트 전반에 대한 이해도를 높여야 했고, 팀원들과의 커뮤니케이션 등 고려해야 할 요소가 훨씬 많아졌다.
(부족한 부분을 많은 분들이 도와주셨지만) 그렇게 일주일 정도를 PL의 역할로 보냈다. 이제는 다시 보조하는 역할로 돌아가겠지만, 이번 경험은 나에게 큰 자극이 되었다. 언젠가 정말 PL로서 팀을 책임져야 하는 순간이 왔을 때 더 잘 해내고 싶다는 욕심이 생겼고, 동시에 개발자로 어떻게 해야 살아남을 수 있을지 찾아보아야 했다.
복잡한 상황 속에서도 본질적인 가치를 찾아내고 효율성을 극대화하는 법을 배우고 싶었다. 그런 고민 끝에 마주한 이 책은, AI 시대에 개발자가 지향해야 할 미니멀리즘의 원칙을 담고 있었다. 급변하는 환경 속에서 개발자로서의 생존 전략을 어떻게 구축해야 할지, 그 실마리를 《미니멀리즘 프로그래머》 를 통해 찾아보려 한다.
단순화 하기
이 책의 핵심은 단순화다. 단순화는 크게 두 방향으로 접근할 수 있다. 하나는 외부에서 들어오는 복잡성을 줄이는 것, 다른 하나는 내가 만드는 것 자체를 단순하게 만드는 것이다. 아래에서 다루는 내용들도 이 두 축을 중심으로 정리해보았다.
단순화의 첫 번째 축은 외부에서 들어오는 복잡성을 다루는 것이다. 쓰지 않을 라이브러리, 추가하지 않을 기능, 변경될 API가 모두 잠재적 복잡성이다. 의존성을 어떻게 다루고, 코드를 얼마나 남길지 결정하는 것부터 단순화가 시작된다.
의존성 줄이기
의존성을 추가하면 애플리케이션의 통제권 일부를 포기한다는 뜻이다.
간단한 경우에는 라이브러리를 찾기보다 코드를 작성하는 편이 빠를 수도 있다. 코드의 일부를 라이브러리 작성자에게 위임하면서 당장의 문제는 해결될지라도 동시에 이 코드를 유지보수할 미래의 나에게는 위험과 유지보수 측면에서 복합적 복잡성이 더해진다.
만약 필요한 경우 오픈소스이고 라이브러리가 허용된다면, 해당 라이브러리의 소스를 프로젝트 요구사항에 맞게 수정해서 넣는 방법도 있다.
의존성을 끌어오는 것만이 문제는 아니다. 이미 쓰고 있는 의존성이 갑자기 바뀌면 전체 코드가 흔들릴 수 있다. 그래서 의존성을 프로젝트 안에 어떻게 배치하느냐도 중요하다.
의존성 격리
광범위하게 사용되는 경우 갑자기 API가 변경이 되면 여러 파일에 걸쳐 코드를 수정해야 할 수 있다.
어떤 의존성을 프로젝트 전반에서 많이 사용한다면, 간단한 래퍼 함수로 감싸서 사용하는 방법으로 API가 변경이 되더라도 래퍼 함수만 업데이트하는 식으로 대응할 수 있다.
의존성을 다루는 관점에서 한발 더 나아가면, 코드 자체를 만들 때도 필요한 것만 만들어야 한다는 원칙이 자연스럽게 따라온다.
필요 주도 개발
기능을 줄여 필요한 것만 더 빨리 제공할 수 있다. 기능은 나중에 언제든지 추가할 수 있으니까 아무도 요청하지 않은 코드는 작성하지 말자.
코드 안의 복잡성을 줄이는 방법도 중요하지만, 업무 환경 자체가 복잡하면 생산성은 여전히 떨어진다. 다음으로는 주변 환경을 단순화하는 방법을 살펴본다.
회의 줄이기
회의는 대게 불공평하고 방해요소이다. 직급이 높거나 지식이 풍부한 참석자에게 쉽게 지배당한다. 또한, 회의에 참석하려면 하던 일을 모두 멈춰야한다. 회의가 끝난 뒤 하던 일의 맥락을 다시 파악하고 흐름을 복구해야하는 속도는 보통 15~30분이다.
회의시간을 절반으로만 줄여도 개발자 한 명 근무 시간의 80%에 해당하는 여유 시간이 생긴다. 꼭 필요한 사람만 참여하는 최소한의 회의를 해야 한다.
회의를 단순화하는 가장 좋은 방법은 자료를 미리 공유하고 참석자를 정교하게 거르는 것이다. 준비 과정에서 스스로의 오해를 바로잡아 불필요한 모임을 방지할 수 있을 뿐만 아니라, 꼭 필요한 소수 인원만 모였을 때 비로소 깊이 있는 토론과 빠른 의사결정이 가능해지기 때문이다.
작업 공간 정리
개발 환경이 복잡해지면 생산성이 떨어진다. 창과 작업 공간을 관리하는 도구를 활용해 불필요한 요소를 줄이고, 단순한 환경을 유지해보자.
또한, 개인 머신이 고장 났을 때 생산적인 일을 바로 시작하기까지 환경을 복구하는 데 얼마나 걸리는지 시간을 한번 기록해보자. 예상보다 오래 걸린다면, 복구 과정을 자동화하거나 단순화할 방법을 찾아야 한다.
주석 달지 않기
주석은 코드가 변경될 때마다 함께 갱신해야 하는 부담을 만든다. 코드를 수정하면 관련 주석도 반드시 업데이트해야 하므로, 변경 사항 하나의 작업량이 두 배로 늘어난다. 결국 시간이 지나면 주석은 실제 코드와 동떨어지고, 오히려 독이 되어 개발자를 혼란스럽게 한다.
줄을 맞춰 정렬하기
사람의 뇌는 패턴 인식에 뛰어나다. 변수나 값을 일렬로 정렬하면 틀어진 하나가 쉽게 눈에 띈다. 단순히 띄어쓰기로 표 형태를 만들기만 해도, 오타나 불일치 같은 단순 실수를 의외로 많이 찾아낼 수 있다.
아래는 두가지 오류가 존재하는 코드이다.
weight = containerContents.weight
size = containerContent.size
items = contaierContent.items
아래와 같이 한다면 쉽게 금방 찾을 수 있다.
weight = containerContents.weight
size = containerContent.size
items = contaierContent.items
나는 무조건적으로 프리티어 같은 포매터를 사용하자는 주의였지만, 주변에 더러 좋아하지 않는 개발자들도 있었다. 이제서야 그분들이 이해가 가기 시작했다.
코드를 표 형태로 정렬하는 단순한 습관 하나로도 눈에 안 띄던 오류가 드러난다는 점은 꽤 인상 깊었다. 에디터에 적용할 수 있는 정렬 플러그인을 한 번 찾아봐야겠다.
정리
PL 경험을 통해 느낀 것은, 리더가 된다는 것은 단순히 기술력이 좋아지는 것이 아니라 불필요한 것을 걷어내고 팀 전체의 집중력을 살리는 것이라는 점이다.
이 책이 말하는 미니멀리즘은 코드를 최소화하는 기술만이 아니라, 개발자가 지속 가능한 상태로 일할 수 있는 환경을 만드는 철학이다.
AI가 코드를 생성하는 시대가 오면서 단순 코딩의 가치는 점차 떨어지고 있다. 하지만 무엇을 만들지, 어떤 코드를 남길지, 어떻게 팀을 이끌지에 대한 판단은 여전히 개발자의 몫이다. 복잡함 속에서 본질을 찾아내는 능력, 그것이 앞으로 개발자가 가져야 할 핵심 역량이 아닐까..?