똑같이 동작한다고 해서, 다같은 코드는 아닙니다. 코드도 품질이 있습니다. 좋은 품질의 코드는 가독성이 좋고, 유연하며, 응집도가 높고, 결합도가 낮습니다. 이런 좋은 품질의 코드를 작성하기 위해서는 기준과 방법을 공부할 필요가 있습니다. 이 글을 시작으로 앞으로 클린코드에 대해서 정리해보겠습니다.
목차
- 코드도 품질이 있다
- 발목 잡는 기술부채
- 뒤늦은 조치
- 좋은 품질의 코드란
- 클린코드를 살펴보다
- 마무리
코드도 품질이 있다
개발자가 아닌 이상, 대부분
🤷♀️ "어떤 코드든 기능이 돌아가기만 하면 됐지 뭐.."
라는 식의 사고를 많이 합니다. 저도 대학생시절 대외활동에서 기획자 역할을 맡았을 시 결과물만 나오면 된다는 생각으로 임했던 것 같습니다. 하지만 눈으로 보이는 게 다가 아닙니다. 눈으로 보이는 동작은 같더라도 코드에는 품질이 있습니다.
아마 개발자가 아닌 이상 코드 품질에 대해서는 관심이 없을 겁니다. 코드야 어떻건 동작은 하니깐요. 하지만 의식을 해야할 겁니다.
안 좋은 코드는 점점 개발팀의 생산성을 떨어트립니다. 개발하는데 1일 걸릴 기능을 2-3배 걸리게 만듭니다. 결국 이는 경영비용에 까지 영향을 미칩니다.
발목 잡는 기술 부채
품질이 낮은 코드가 쌓이고 쌓여서 큰 덩어리가 되면, 손 쓰기가 힘든 코드 덩어리가 만들어 집니다. 이걸 고급진 용어로 '기술 부채'라고 합니다. 이 '기술부채'는 앞서 잠깐 언급했듯이 기업 경영에 영향을 미치게 됩니다.
개발자라면
이미 작성된 쓰레기 코드로 인해 고생한 경험이 있을 겁니다.
🤷♂️ 개발자 A
"코드가 너무 엉망이라 프로젝트 진도가 계획대로 안나가요"
🤦🏻♂️ 개발자 B
"A를 고쳤을 뿐인데, 생전 처음 보는 B, C, D에서 오류가 터지고 있어요"
이처럼 '기술 부채'는 개발 속도를 크게 떨어뜨립니다. 코드 품질을 중요하게 여기지 않거나, 주로 시간에 쫓겨 어쩔 수 없이 저품질 코드에서 타협을 하는 경우 '기술 부채'가 서서히 쌓여 갈 것입니다. 이렇게 되면 초반에는 개발 속도가 번개처럼 빠르다가, 1-2년 만에 간단한 기능이라도 현저히 개발 속도가 떨어집니다.
설사 빠르게 개발을 완료했다 해도, 여기저기서 오류가 터질 것입니다. 코드가 뒤엉켜 있으니 한 곳을 고쳐도 그곳과 관련된 다른 코드들이 문제를 일으킵니다. 이를 사이드 이펙트라고 합니다.(오해하진 마세요. 사이드 이펙트는 더 큰 의미를 가지고 있습니다)
돌고 도는 악순환
안타깝게도 운영진에게 이 문제는 크게 중요하지 않습니다.
지금 당장 서비스를 출시하거나 새로운 기능을 추가하는 것이 더 가치 있는 것이라고 생각합니다. 운영진은 과거처럼 업무량을 만들어 냅니다. 지금까지 10개를 해왔다면, 10개를 준비해서 스프린트 계획을 합니다. 하지만 개발팀은 예전 같지 않습니다. 10개를 하는 게 점점 버거워집니다. 시간은 촉박하고 나쁜 코드는 계속해서 쌓여갑니다. 결국 팀 생산성은 0에 수렴하게 됩니다.
생산성이 떨어지면 그제야 운영진은 해결방법을 모색하고자 합니다. 그래서 그때부터 새 인력을 충원하기 시작합니다. 인력이 늘어나면 생산성이 늘고 더 많은 기능을 추가할 수 있을 것이라 기대합니다.
하지만 새 인력은 현재 코드에 대해 조예가 깊지 않고, 이에 익숙해지는대도 꽤 시간이 걸립니다.
때론 새 인력이 기존의 한계점에 새로운 기운을 불어주기도 합니다. 하지만 곧 좌절되는 순간이 옵니다. 생산성에 대한 압박을 받기 때문입니다. 결국 다시 나쁜 코드가 양산되고 이번엔 사람이 늘어난 만큼 '기술 부채'가 기하급수적으로 쌓여갑니다.
어느 순간 답답한 운영진이 이런 질문을 던질지도 모릅니다.
😠 CEO
"아니!, 사람을 계속 뽑고 있는데, 왜 개발 속도는 그대로예요?!"
이런 이야기나 생각을 한 번이라도 들어봤거나, 해본 적이 있다면 여러분들은 이미 '기술 부채'를 이미 경험해 보셨습니다. 개발자는 코드를 짜는 시간 비율보다 코드를 읽는 대 더 많은 시간을 들입니다. 기존 코드를 이해하고 새로운 코드를 짜야 버그나 오류를 최소화할 수 있기 때문입니다. 그런데 기존의 코드가 읽기가 힘들다면, 제 아무리 숙련자라도 놓치는 부분이 생기기 마련입니다. 작업 시간도 1일 걸릴 거 3일 걸리고 하겠죠.
뒤늦은 조치
마침내 참다 참다 개발팀이 강력주장하게 되고, 운영진도 문제의 심각성을 인식하게 됩니다. 이를 개선하기 위한 TF 팀이 꾸려집니다. 문제는 코드 개선은 개선대로, 새 기능은 새 기능대로 또 만들어집니다. 아마 코드 개선만 하는데 그대로 두지 않을 겁니다. 새로운 기능을 계속 개발해서 투자를 받아와야 하거든요.
기능 개선하는 TF팀은
- 기존 코드도 개선하랴
- 새로운 기능들도 따라잡으랴
정신없는 나날을 보냅니다. 때로는 이 기간이 점점 길어지기도 합니다.
임무수행이 100% 완료가 될 때쯤 기존 TF팀원을 절반 이상이 나갑니다.
그리고 새롭게 다시 채워진 인원은 처음에 기획했던 개선 방향을 다시 설계해야 한다고 반기를 듭니다. 이유는 시스템이 너무 엉망이라서..
결국 '기술 부채'를 뒤로 미루는 것은 기업의 비용을 증가시키기만 할 뿐입니다. 가장 유일한 해결책은 지속적으로 코드품질을 관리해 가는 것입니다. 그러려면 개발자만 노력한다고 되는 게 아니라 전사적인 인지가 필요합니다. 생각해 보세요. 개선을 지속적으로 하기 위해서는 10에서 2~4할은 개선을 위한 리소스로 빼야 합니다. 그러려면 작업 시간, 인력, 환경 등등이 모두 재고려가 되어야 하는 거죠.
좋은 품질의 코드란
우리가 거대한 '기술부채'를 마주하지 않고, 안정적으로 개발팀을 운영해 가기 위해서는 코드 품질을 일정 수준 이상으로 계속 유지해 가는 게 좋습니다. 하지만 좋은 품질의 코드란 무엇일까요? 우리는 좋은 코드에 대한 기준이 필요합니다.
저는 그 해답을 클린코드라는 도서에서 찾고자 했습니다.
- 깨끗한 코드는 한가지에 집중한다
- 깨끗한 코드는 잘 쓴 문장처럼 잘 읽힌다.
- 깨끗한 코드는 다른 사람이 고치기 쉽다.
- 모든 테스트를 통과한다.
- 중복이 없다.
- 간단한 추상화가 고려되어 있다.
하나씩 살펴보면
잘 쓰인 코드
읽기 쉽고, 고치기 쉬운 코드 여야합니다. 이것은 이해하기에는 쉽지만 실현해 내기 힘든 일입니다.
우선 팀원 모두가 읽기 좋은 코드가 되려면, 최소한의 컨벤션이 있어야 하며, 이름에도 규칙이 있어야 합니다. 또한 고치기 쉬운 코드가 되려면 코드의 응집도가 높고 결합도가 낮아야 합니다. 좀 더 덧붙이자면 코드가 역할별로 잘게 쪼개져 있을수록 좋은 코드라고 볼 수 있습니다. 물론 이에 대해서는 의견이 분분합니다. 너무 잘게 쪼개면 코드 파악하기가 어려워지기도 합니다.
테스트 코드를 통과한 코드
좋은 코드와 테스트 코드는 관련성이 있습니다. 대부분 테스트 코드를 테스트 용도로만 생각하시는 분이 많습니다.
하지만 테스트 코드는 좋은 코드를 설계하는데 유용한 도구로 보는 것이 더 올바른 접근법입니다. 테스트 코드를 작성하다 보면, 내가 만들어야 할 기능의 설명서가 곧 테스트 코드가 됩니다. 굳이 기능을 설명하기 위해 주석을 달 필요가 없어지는 거죠.
게다가 테스트 코드가 작성되려면, 기존 코드가 테스트에 친화적인 코드여야 합니다. 테스트 친화적이다라는 건 테스트하기가 쉬운 코드라는 말과 같습니다. 여기서 테스트 코드의 힘이 발휘되는데, 테스트하기 쉽게 코드를 짜려다 보면 결국 좋은 코드를 만들게 됩니다. 이유가 있는데요.
테스트가 쉬운 코드는
- 다른 코드에 덜 영향을 받는 코드
- 역할이 분명한 코드
- 잘개 쪼개진 코드
라고 볼 수 있습니다. 모두 다 좋은 코드가 되기 위한 조건인 거죠. 물론 테스트를 통해 코드의 안정성을 확보하는 것은 덤입니다. 더불에 자신의 코드에 자신감도 붙게 되죠.
클린코드를 살펴보다
다음부터는 본격적인 좋은 코드를 작성하는 방법에 대해 알아가고자 하는데요. 클린코드라는 도서를 바탕으로 한번 살펴보겠습니다. 근데 이 책은 꽤 분량이 큽니다. 저는 여기서 제가 보고 싶은 내용들만 쏙쏙 뽑아서 보겠습니다.
- 함수
- 객체와 자료구조
- 오류처리
- 클래스
- 동시성
- 의미 있는 이름
"의미 있는 이름"은 클린코드 책에서 2장부터 시작합니다. 그럼에도 가장 뒤에 넣은 이유는 너무 지겹도록 들었던 내용이기 때문입니다. 지겹도록 들었던 걸 처음부터 읽어서 지루함을 느끼느니 뒤로 빼겠다는 생각을 했습니다.
이제 다음 글부터 하나하나씩 정리해 가 보겠습니다. 💪🏻
마무리
코드의 품질을 유지하는 건 쉽지 않습니다. 회사는 개발자가 좋은 품질을 만들 수 있는 시간을 잘 주지 않습니다.
- 개발자가 아닌 이상 관심이 없을 수도 있습니다. 🤷♀️
- 론칭 시기를 맞춰야 할 수도 있습니다. ⌚️
- 투자자들의 눈치를 보고 있을 수도 있고요. 🙇
- 지켜야 할 계약 일정이 있을 수도 있습니다. 📅
- 시장 반응에 빠르게 맞춰가야 할 수도 있죠. 🏃🏻
어떤 상황이든 개발자는 개발 코드 품질을 챙겨가야 합니다. 그러기 위해서는 개발 틈틈이 코드 품질을 챙겨가야겠지만, 무엇보다 코트품질의 중요성을 인지하고 품질을 향상하기 위한 조직적인 공감대와 함께 시스템을 구축해야 한다고 생각합니다. 코드리뷰, 테스트코드 관리 등등 개발자가 좋은 품질을 양산할 수 있는 기반이 있어야 하겠습니다.
하지만 이것도 회사의 상황에 따라 다를 겁니다. 회사 상황이야 어찌 되었던, 개인으로써는 코드품질을 챙기는 조직에서 활동하거나, 시스템을 적용을 해볼 수 있다면 값진 경험이 될 것입니다.
우리는 우선 안목부터 키워보죠!
'Dev.' 카테고리의 다른 글
| E2E 테스트 도구(tool)들 분류하기 (0) | 2023.05.27 |
|---|---|
| 내부에 개발자가 필요한 이유, 리팩터링 (0) | 2023.05.27 |
| [실전] 프론트 기존 컴포넌트를 개선한 경험 공유 (0) | 2023.05.27 |
| TDD 는 코드 설계를 위한 도구이다. (0) | 2023.05.27 |
| 리팩터링 할려고? 그래.. 테스트코드는 있고? (0) | 2023.05.27 |
