사내강사로 여러 교육을 진행했지만, 저 스스로에게도 도움이 되었던 강의는 클린코드 확산 교육이었습니다. 이는 작년에 클린코드 교육을 진행하면서 느꼈던 점을 적어본 글입니다.
기술적 부채
Technical Debt라는 용어가 있습니다. 기술적인 부채, 즉 기술적인 '빚’입니다. 개발하면서 빚을 질 수 있을까요? 네, 우리는 개발을 하면서 빚을 지고 있습니다. 이 빚은 당장은 편하지만 이자가 점점 붙어서 나중에 감당하기 어려운 수준까지 늘어날 수 있습니다. 바로 소프트웨어의 품질에 관련된 빚입니다.
이 빚은 개발 프로세스의 압박, 테스트 코드와 문서의 부재, 오너쉽과 협업의 부재 등 개발 과정에서 전반적으로 나타날 수 있는 문제들입니다. 현실에서도 적당한 부채는 도움이 되듯이, 프로젝트 상 자원의 한계 때문에 어느 정도의 빚은 가지고 가게 됩니다. 하지만 과도한 빚으로 인해 SW의 품질이 낮아지고 이는 개발 당시에는 큰 문제가 없어보이지만 향후 운영 과정에서 눈덩이처럼 불어나 닥쳐오는 빚이 됩니다.
이 모든 것이 코딩에서만 비롯되는 문제는 아니지만, 클린코드와 리팩토링은 코드에 관련된 내용입니다. 사실 클린코드는 이미 수년전부터 너무나 많이 회자되었고, 대부분 많이 들어보셨을 내용입니다. 하지만 그럼에도 불구하고 지금까지 클린코드와 코드 품질에 대해 이야기가 나오는 것은 SW 개발의 특성 상 코드의 품질을 정의하거나 측정하고 관리하는 것이 쉽지 않기 때문일겁니다.
클린하지 않을 이유
클린 코드는 다음과 같이 간단하게 정의해볼 수 있습니다.
- 사용자의 요구사항을 잘 반영한 코드
- 쉽게 변경이 가능해서 유지보수가 쉬운 코드
- 읽기 좋아서 담당자가 바뀌더라도 쉽게 볼 수 있는 코드
클린코드에 대해서 이야기할 때, 현업에서 들리는 가장 많은 이야기는 이겁니다.
“누가 좋은 줄 모르나요? 할 여력이 없어서 그렇지…”
맞습니다. 개발이든, 운영이든 시간과 자원의 압박에서 자유로울 수 없고, 그리고 같은 코드를 짜도 시간을 더 들여서 클린하게 짠다고 해서 위에서는 관심도 없고 주변에서 알아주는 사람도 없습니다. SI 같은 경우는 ‘내가 운영할 것도 아닌데, 뭐’ 라는 마인드로 대충 짜는 경우도 있었습니다. 그래서 코드 리뷰를 점차 도입하고, 장인정신(SW Craftsmanship)을 강조하며, 코드에 대한 오너십을 강화하기 위해 코드실명제를 도입한다는 이야기도 들립니다.
코드 품질에 관련한 툴을 사용하기도 합니다. PMD 나 Fortify 등 코드 품질 관련 도구를 자동화된 빌드 과정에 넣어 개발자들에게 이메일이 수시로 날아가기도 합니다. 이 모든 것들이 개발자에겐 스트레스로 다가옵니다. ‘바빠 죽겠는데 뭘 또 고치란 말이야?’.
개발자의 마인드, 그리고 스킬
그렇다면 코드의 품질을 높이기 위해서 가장 중요한 것은 무엇일까요? 저는 실제 코드를 짜는 개발자들의 의식 변화와 스킬 훈련이 가장 중요하다고 생각합니다.
물론 개발자들이 코드를 클린하게 짤 수 없는 이유는 충분합니다. 하지만 개발자 스스로의 변화가 우선시되어야 하는 이유는, 여건이 안되더라도 개발자가 능력이 있다면 주어진 여건 하에서 코드 품질을 올릴 것이고 이는 결국 수정을 해야 하는 개발자 자신에게 득이 되는 일입니다. 반대로 개발자가 코드 품질에 대한 이해와 스킬이 부족하다면 여건이 갖춰지더라도 코드 품질은 오를리가 만무합니다. 따라서 개발자들이 변화의 중심에 서야 합니다.
위에서부터 클린코딩을 강요하면 웃지 못할 해프팅이 벌어지기도 합니다. 어떤 개발팀에서는 테스트 커버리지를 100% 채우기 위해 의미없는 VO 클래스를 테스트하기도 하고, assert 문을 넣지 않고 통과시켜 버리기도 한다고 합니다. 정말 그 자체로 의미 없는 일입니다.
클린 코드를 중요하게 생각하는 개발자가 늘어나면 위에서부터의 변화가 아니라 아래서부터의 변화가 생겨나고 문화를 만들어질 것입니다. 쉽지는 않겠지만 이것이 옳은 변화라고 생각합니다. 이를 뒷받침하기 위해 위에서도 강요가 아니라 코드 품질을 높이는 활동을 중요하게 인식하고 장려해야겠죠.
교육 후 개발자들의 마인드는 처음과 조금 바뀌었습니다. ‘꼭 해야할까?’ 에서 ‘해보니 좋네’, ‘해볼만 하다’ 라는 마인드로 바뀐 개발자들이 많았습니다. 정말 긍정적인 변화입니다. 하지만 실제 현업에 적용하려면 계속해서 연습하는 숙달의 과정이 필요합니다. 이를 뒷받침할 수 있는 여러 교육 과정과 지원, 그리고 개발자 스스로의 노력이 필요하겠죠. 저 또한 마찬가지입니다.
