brunch

You can make anything
by writing

C.S.Lewis

by 백명석 Jan 02. 2016

"클린 코드를 다시 읽고"를 읽고

나는 2006년 게시판을 개발해서 2007년부터 5년 정도를 서비스를 하면서 기능을 추가하고 버그를 패치하는 업무를 주로 했다. 그러다 보니 남이 작성한 코드(2주 전에 내가 작성한 코드도 포함)를 많이 봐야만 했고, 또 이를 안전하게 수정하고, 코드를 추가하는 것을 잘 할 수 있는 방법에 대해서 노력을 해야만 했다.

이런 경험 때문에

- Michael Feathers의 "Working Effectively with Legacy Code"를 봤을 때

- Robert C Martin의 clean code 동영상을 봤을 때

정말 놀랐고, 열심히 공부했고, 현업에서 활용하며 큰 도움을 얻었던 기억이 있다(지금도 진행 중이다).

클린 코드는 3번 정도 본 것 같다. 첫 번째는 혼자(책에 줄 그어가면서), 두 번 때는 팀에서 세미나 하면서, 세 번째는 최근 이동된 조직에서 세미나 하면서... 볼 때마다 안 보이던 내용이 보인다. 세 번째 볼 때 이 책에 Emergent Design이라는 말이 있다는 것을 보고 놀랐다. 두 번 볼 때까지는 이해를 못해서 기억이 안 났던 것 같다.

정말 대단한 책이다.

그런데 페이스북에 친구로 연결되어 있는 지인분이 이 책에 대해 작성한 "클린 코드를 다시 읽고"를 봤다.

이분과 내가 개발 경험/성향이 달라서 같은 책을 보고 다르게 생각할 수 있을 것 같다.

그래서 아래와 같이 다르게 생각하는 부분에 대해서 좀 언급하고자 한다.

로버트 마틴은 개발 경력이 40년. 알려진 이력이나 성과가 거의 없다. 15년 전부터는 그냥 애자일 얘기만 하는 거 같다.
애자일/XP 가 인간 중심으로 개발을 고민하려는 노력에 비해 기술적인 고민이나 깊이는 찾아보기가 힘들다.

오픈소스 프로젝트를 하거나 주커버그처럼 서비스로 대박을 내야만 성과가 있는 것인가?

개인적으로 가장 대단한 개발자 중의 한분이라고 생각하는 켄트 벡은 쥬커버그의 직원이다(로버트 마틴도 어머어마한 개발자 중 한분이라고 생각한다).

켄트 벡도 내가 아는 수준에서는 jUnit 말고는 크게 외부적인 성과는 없다. 그저 로버트 마틴처럼 Agile에 기여하고 많은 컨펀런스 등에서 발표를 하고 몇 권의 책을 쓴 것(로버트 마틴이 책은 더 많이 쓴 것 같다) 정도.

켄트 벡은 젊은 개발자들과 어울려 개발에 참여하고 배움을 주고 있는 것에서도 높은 가치를 보여준다.

로버트 마틴은 현업은 아니라도 현업 개발자들에게 도움이 되는 책, 강연, 트레이닝 코스 등으로 시니어 개발자로서의 큰 가치를 보여준다고 생각한다.

로버트 마틴의 책을 다 보고, 클린 코드 비디오를 다 봤다면 "기술적 고민이나 깊이는 찾아보기가 힘들다"는 말은 절대 할 수 없을 것이다.

페이스북을 만든 쥬커버그, 스프링을 만든 로드 존슨, 유겐 헬러... 대단한 분들이다. 하지만 난 개인적으로 켄트 벡, 로버트 마틴, 마틴 파울러에게서 더 많이 배우고 있고, 그런 삶을 살고 싶다.

개발자는 기계를 연구하고 최적화하는 알고리즘을 고민하는 사람

이런 개발자도 있고 비즈니스 애플리케이션(웹서비스를 포함한)을 개발하는 개발자도 있는 것이다. 논문을 공부하고 이를 구현하는 코드만을 작성하는 사람들만 개발자는 아니다.

대부분의 개발자들은 비즈니스 애플리케이션을 개발한다.

인간 중심만을 생각한다면 기획자가 차라리 더 어울린다.
클린 코드 중 일부는 알고리즘이나 전산학에 대한 기초가 탄탄하다면 나오지 않을 얘기들도 있다.

기계 연구 없이 비즈니스 애플리케이션을 작성하는 사람들은 기획자인가? 위험한 말이다.

자신이 아는 것 외에도 다른 것이 있다는 것을 고민할 수 있었으면 한다. 전산학에는 알고리즘, OS 등만 있는 것이 아니라 소프트웨어 공학, 객체지향 등도 포함된다.

가독성의 기준 또한 기계에 대한 이해도에 따라 사람마다 다르다.

도메인, 시스템, 환경 등에 대한 이해가 있어야만 이해할 수 있는 코드를 작성하겠다는 말인가?

석사 때 본 많은 논문 구현 프로그램 소스(주로 C++로 작성된)는 정말 이해하기 어려운 긴 함수로 이뤄진 것이 많았다. 같은 주제로 공부를 했기에 쉽게 이해할 수 있어야 하는데 그렇지 않았다. 지금 생각에는 그 소스들은 사람이 이해할 수 없는, 기계나 이해할 수 있는 코드는 아니었다 싶다. 그 코드를 누가 다시 읽을 필요도 별로 없고, 요구사항 변경을 반영할 필요도 없으니..

신문에 기사를 쓸 때 해당 기사에 대한 백그라운드 지식(전문가 수준)이 있는 사람들만 이해할 수 있도록 요약해서 작성하는 것이 좋은가?

아니면 탑다운으로... 위에는 일반인도 이해할 수 있는 수준... 점점 들어갈수록 구체적으로 되어서 해당 영역에 대한 이해가 필요하도록 작성하는 것이 좋은가?

클린 코드를 익히기 전에 기계에 대한 이해도를 높이는 게 먼저라고 생각한다. 먼저 각자가 일정 수준 이상은 넘어서야 한다는 얘기다.

각자가 일정 수준(개발자로서의) 이상은 되어야 한다는 말은 공감한다. 하지만 그게 클린 코드랑 무슨 상관이 있는지는 모르겠다.

우리는 같은 듯 서로 다른 영역에서 각자의 개발을 하고 있다. 심지어 내가 작성한 다소 복잡한 코드를 2주 후에 보고 다시 이해하기 위해 많은 시간을 소요하기도 한다(나만 그런가 ^^).

2주 후에 다시 볼 때 쉽게 이해할 수 있는 코드를 작성하려면 지금 주제에 나보다 이해가 부족한 사람도 어렵지 않게 이해할 수 있는 수준으로 코드를 작성해야 한다.

객체지향의 대가인 Grady Booch는

잘 쓰여진 산문처럼 읽힐 수 있도록 코드를 작성

해야 한다고 했다. 모든 코드를 많은 책과, 논문을 읽고 나서도 이해하기 어려운 새로운 논문처럼 작성하는 것은 대부분의 경우 옳지 않을 것 같다.

우리는 기계를 연구하는 개발자다.

개발자는 공학자로서 사용자에게 가치를 제공하는 것이 먼저라고 생각한다. 연구하는 것이 주 업무라면 과학자가 더 맞을 것 같다.

소프트웨어의 가치는 요구사항대로 동작하기만 하는 것이 아니라 지속적으로 변화하는 요구사항을 수용하는 능력이다.

사용자들이 사용하고 있는 소프트웨어라면 지속적으로 요구사항 변경이 나온다. 변경이 요구되지 않다면 아마 사용자들에게 외면당해 더 이상 사용되지 않은 죽은 소프트웨어 일 것이다.

이런 가치를 제대로 이루려면 잘 쓰인 산문처럼 읽혀지도록 코드를 작성하는데 필요한 클린 코드는 매우 중요한 기술이다. 코드는 작성해서 동작하는 것으로서 목적이 달성되는 것이 아니라 이후 발생하는 요구사항 변경을 위해 지속적으로 읽혀지고, 변경되는 것이 존재의 이유일 것이다.

"클린 코드를 다시 읽고"를 쓰신 분은 다양한 알고리즘을 공부하고, 시스템 프로그래밍을 많이 하셨을 수 있다. 거기에 내가 이해하지 못한 다른 부분이 있을 수 있다. 다른 것이다... 혹 내 글에서 과한 부분이 있다면 알려주시면 논의를 했으면 한다.