좋은 코드의 근원
좋은 코드, 좋은 설계, 좋은 개발자
좋은 코드란 무엇일까?
나를 비롯한 모든 개발자들은 좋은 코드를 추구한다. 좋은 코드의 구체적인 정의는 개발자마다 다르겠지만 일반적으로 통용되는 규칙이 있다.
- 쉽게 읽힐 것
- 팀의 코드 스타일 패턴을 지킬 것
- 주석이 필요 없을 정도로 명확하거나 적절한 주석을 달 것
- 사이드 이팩트가 발생하지 않거나 적절히 대응할 것
…
그 밖에도 수많은 기준이 있겠지만 개발자가 좋은 코드를 쓴다고 해도 바꿀 수 없는 게 있다. 바로 설계다. 설계가 잘못된 프로젝트는 코드를 아무리 잘 쓰더라도 제대로 작동되지 않거나 여러 기능 상의 한계에 봉착하게 된다. 잘못된 설계를 바탕으로 프로젝트가 계속 진행된다면 최적화와는 무관하게 시스템이 멈추게 될 수도 있고, 그동안 쓴 수많은 코드를 지우고 밑바닥서부터 다시 만들어야 하는 상황이 온다. 즉 좋은 코드는 좋은 설계 위에서 빛이 날 뿐 엉망인 설계에서는 좋은 코드란 존재하기 힘들다.
그렇다면 좋은 설계란 무엇일까?
개발자라면 코드를 넘어 설계의 단계에 대해 고민할 수 있어야 한다. 가령 리액트를 사용한다면 상태 관리에 리덕스를 쓸지 MobX를 쓸지, Context와 Props, state 수준으로 끝낼지, 리코일을 쓸지 선택을 해야 한다. 그전에 리액트가 최선인지도 고민해봐야 한다. 리액트보다 나은 선택지는 없는가? SSR을 위해 Next.js를 써야 하진 않을까 또는 이 프로젝트는 Vue.js를 쓰는 게 더 빠르게 완료되지 않을까? 등등 생각할 여지는 수 없이 많다. 그러나 개발자가 모든 스택을 균등하게 잘할 수는 없기에 자신이 가진 기술 안에서 최선의 선택을 하게 되고, 그것이 설령 최선의 도구가 아닐지라도 밀어붙이곤 한다.
여기서 개발자의 태도나 회사의 태도를 알 수 있다. 많은 신생 기업들은 최신 프레임워크와 라이브러리를 적극적으로 사용해 현시점에 이슈가 되는 문제들에 대해 해결할 방법을 고민한다. 반면 과거에 머무른 개발자나 회사는 자신이 가진 패 안에서만 답을 찾기 때문에 기존에 사용하던 것을 어떻게든 발전시켜서 답을 찾으려고 하는 경향이 강하다. 그러나 과거 기술이 과거 기술로 불리는 데는 이유가 있다. 과거 기술이 가진 문제점을 해결하기 위해 그다음 세대의 기술이 등장한 것이며, 새로운 기술이 가진 단점들(프로덕션 레벨에서 리스크나 미성숙한 커뮤니티)을 고려했음에도 과거 기술을 밀어냈다는 건 이미 신기술의 장점이 단점을 상쇄하고도 남기 때문에 변화가 발생한다.
좋은 설계를 하기 위해선 새로운 설계를 해야 한다. 물론 새로 작성된 설계에는 기존의 설계에서 해결하기 힘든 문제를 하나 이상 해결할 수 있어야 하며 잠재적인 위험도 고려해야 할 것이다.
나는 절대적으로 옳은 코드나 신이 내린 코드 따위는 없다고 믿는다. 또한 완벽한 설계도 절대 존재할 수 없을 것이다. 우리가 가능한 건 언제나 어제보다 조금 더 나은 코드를 쓰는 것과 조금 더 넓게 완성된 설계를 조망해 기존의 문제점이 무엇이었는지 찾는 것이다. 그래서 좋은 코드를 쓸 수 있는 사람은, 좋은 설계를 하는 사람은 다음의 특징을 가진다.
자신의 코드의 문제점을 발견하고 개선한다.
자신의 프로젝트의 한계점, 위험성을 발견하고 개선한다.
드라마틱한 개선을 위해 다른 개발자들이 제작한 라이브러리들이나 개발 패턴을 학습한다.
개발의 매력은 바로 이곳에 있다. 모두가 완성된 사람이 아니고, 모두가 완벽한 코드를 쓸 수 없다. 어제 보다 조금 더 나은 코드를 쓰는 사람들만 있을 뿐이다.
