대학원 연구실에 처음 들어가서 구현 되어 있는 소스코드를 보며 들었던 자괴감이 아직도 기억납니다. ‘아… 왜 아무리 봐도 이해가 안되지?’ 그 당시에는 제가 부족해서 그런 줄 알았습니다. 그 때부터 10년이 넘는 시간이 지났습니다. 이제야 알게 됐습니다. 내가 문제가 아니라 코드가 문제였구나.
많은 개발자들이 코드라는 이름의 암호를 작성하며 ‘일단 돌아가야 해!’라고 외치고 있습니다. 하지만 그 코드들은 머지 않아 옥죄는 목줄이 되어 나에게로 돌아옵니다. 빠른 구현을 위해 컨벤션을 맞추지 않고 구현한 코드와 남발한 주석은 코드를 읽는데 혼란을 야기하고, 큰 생각 없이 만들어 놓은 인터페이스는 나중에는 어떤 데이터를 주고 받기 위함인지 조차 희미해집니다. 이렇게 짜여진 코드들은 시간이 지남에 따라 잘못된 결과 값이 발산하는 것처럼 아무도 읽을 수 없는 코드가 되어갑니다. 심지어는 그 코드를 작성한 본인도 코드를 보지 않고 일주일 지나면 그 암호를 디버깅이라는 코드북을 펴놓고 해석해야만 합니다.
우리는 소스코드를 언어라고 부릅니다. 언어는 어떤 존재와 대화하기 위해 존재하는 것입니다. 여기서 많은 사람들은 그 어떤 존재를 컴퓨터라고 생각합니다. 이 착각으로 부터 야기되는 코드라고 부르는 많은 암호들이 생겨나는 것이겠죠.(코드의 뜻이 암호라는 것이 재미있지 않나요?) 하지만 앞서 이야기한 대로, 코드는 컴퓨터가 읽는 것이 아니라, 우리가 읽는 것입니다. 그렇기에 소스코드를 작성하는 것은 글짓기와도 같습니다. 그 중에서도 기술 문서를 작성하는 것과 비슷합니다. 간결하고 명확하게 사람이 이해할 수 있게 코드를 작성해야하는 것이죠. 이렇게 작성된 코드는 언제 누가 보아도 편하게 읽고 이해할 수 있습니다. 불행하게도 제가 겪어온 현업에서는 그런 사소하고 자잘한 것을 고려해서 구현할 시간이 없다고 합니다. 하지만 제가 느낀 것은 ‘시간이 없어서 못하는 것’이 아닌 ‘할 수 없어서 못하는 것’이였습니다.
사람이 읽기에 좋은 코드(readable_code)는 대부분의 경우 컴퓨터가 읽기에도 좋습니다. 불필요한 변수, 함수, 변환 및 프로세스를 구현하지 않기 때문이죠. 또한 이것은 협업과 코드 유지 관리의 퍼포먼스를 비약적으로 상승시켜줍니다. 실제적으로 저는 제가 있던 회사에서 기존의 프레임웍을 버리고 새로운 프레임웍을 설계하여 구현하였고, 기존 프레임웍에서 2주가 걸려서도 진행하기 어려웠던 코드 통합작업을 3일만에 가능하게 단축시켰습니다. 또한 기존 프레임웍에서 3달정도 걸렸을 모듈 구현이 1달도 안걸리는 시간에 가능하게 되었죠. 이렇게 사람이 읽기에 좋은 코드는 구현을 못해서 문제인 것이지, 할 수만 있다면 안할 이유가 없는, 말도 안되게 개발 효율을 향상시킬 수 있는 놀라운 것이죠.
아직까지는 성숙한 개발문화와 협업, 사람이 읽기에 좋은 코드는 많은 경우 있으면 좋은 것, 없어도 큰 상관 없는 것 정도로 치부되는 경우가 많은 것 같습니다. 하지만 저는 사람이 읽기에 좋은 코드의 능력을 보았고 그것의 실제를 경험했습니다. 제가 이것을 지협적으로 제가 있는 회사와 팀에 적용 할 수 있겠지만, 저는 그 정도로 만족하고 싶지 않습니다. 한국의 SW 생산성 자체를 키우고 싶습니다. 엔지니어분들이 더 좋은 환경에서 개발을 하기를 원합니다. 좋은 개발 문화가 한국의 회사들 안에 자리잡기를 원합니다. 저는 이제부터 제가 가졌던 경험, 성공과 실패, 그 과정을 통해 알게된 모든 노하우들을 여러분과 함께 나누려고 합니다. 이것들은 매우 소중한 것이며, 여러분께서 갈 그 길에 탄탄한 기반이 되어줄 것입니다. 함께 하시겠습니까?(y/n) …-y