[개발일기] 체계적으로 개발을 왜 해야할까?

목차

 

"비체계적인 개발 프로세스란 무엇이고 이것을 따를 때 어떤 문제가 발생할까? "

비체계적인 개발 프로세스란 API 설계, 객체 지향 설계, 아키텍처 설계, 디자인 패턴 부재, 테스트 코드 미작성, PR 또는 MR 생략, 코드 리뷰 부재, 이슈 관리 부재, 컨벤션 부재 등 이러한 체계들을 고려하지 않고 개발하는 경우를 말한다.

이렇게 개발하면 개발 속도는 빨라 보일지 몰라도 장기적인 관점에서는 생산성 저하와 품질 저하로 이어진다.

더 자세히 들여다보자

1. 코드 일관성 부족
 - 개발자마다 다른 코딩 스타일을 사용하게 되어 코드의 일관성이 사라진다. 이로 인해 코드 가독성이 떨어지고, 새로운 기능을 추가하거나 버그를 수정할 때 코드를 이해하는 데 많은 시간이 소요된다.

2. 협업 어려움
 - 협업 중에 서로 다른 스타일의 코드를 맞춰야 하므로, 팀 내 소통 비용이 증가한다. 특정 개발자가 작성한 코드를 다른 사람이 쉽게 이해하지 못해 문제가 발생할 수 있고, 작업 속도가 느려진다.

3. 유지보수 비용 증가
 - 시간이 지날수록 점점 유지보수 비용이 급격히 증가한다. 특히 장기적으로 코드베이스가 커지고 복잡해질수록 오류 수정이나 새로운 요구사항 반영이 어려워진다.

4. 버그 발생 가능성 증가
 - 중복 코드나 비효율적인 코드가 발생할 수 있고, 각기 다른 스타일로 작성된 코드 간의 의도하지 않은 충돌이 발생할 수 있다. 이 때문에 점점 많은 버그가 발생한다.

5. 테스트 코드 작성 어려움
 - 일관성 없는 코드 구조는 테스트 코드를 작성하기 어렵게 만든다. 테스트를 표준화된 방식으로 작성하지 않으면, 자동화된 테스트나 CI/CD 파이프라인에서 문제를 일으킬 가능성이 높다.

6. 코드 리뷰 및 PR/MR 비효율
 - 코드 리뷰 과정에서 서로 다른 코딩 스타일이나 관례를 지키지 않는 코드가 많으면 리뷰 시간이 길어지고, 코드 퀄리티에 대한 논의 대신 스타일 문제로 시간을 낭비하게 된다. 이는 생산성을 떨어뜨리고 PR/MR 승인 과정에서 갈등을 유발할 수 있다.

7. 새로운 팀원 온보딩 어려움
 - 새로 합류한 개발자가 기존 코드를 이해하는 데 어려움을 겪는다. 컨벤션이 없으면 개발자가 각기 다른 스타일을 모두 파악해야 하기 때문에, 온보딩 속도가 느려지고, 프로젝트 기여도가 낮아질 수 있다.

8. 재사용성 저하
 - 일관되지 않은 코딩 스타일로 인해 코드 재사용성이 떨어진다. 재사용을 염두에 두고 작성된 코드라도, 스타일이나 구조가 일관되지 않으면 다른 개발자가 이를 활용하는 데 어려움을 겪을 수 있다.

9. 기술 부채 증가
초기에는 빠르게 개발하는 것처럼 보일 수 있지만, 나중에는 기술 부채로 쌓인다. 그러면 유지보수나 기능 추가 시 큰 장애물이 되어 결국 프로젝트 진행 속도와 비용에 악영향을 끼친다.

10. 확장성 문제
 - 시스템의 확장성이 떨어진다. 시스템 확장 시 코드 구조가 통일되지 않아 기능 추가나 아키텍처 변경이 어려워진다.

 

"튼튼한 조직은 PER가 높아야 한다."

PER(Price-to-Earnings Ratio)란 주식의 주당 시가를 주당순이익(EPS)로 나눈 수치이다. PER는 주식시장에서 회사 가치를 측정하는데 주로 활용된다. 예를 들면, 10억 버는 기업의 시가총액이 200억이라면 PER은 20이다. 즉 PER가 높으면 회사의 가치가 고평가이고 앞으로 성장이 기대되고 지속적 사업 가능성이 높아 미리 높은 가격에 판매하고 있다는 뜻이다.

'돈의 속성' 책에서 김승호 작가는 이것을 조직에도 적용할 수 있다고 했다. PER가 높은 조직은 지속적으로 퍼포먼스를 낼 수 있는 조직을 뜻한다. 예를 들어, 동일하게 억대 순이익을 내는 두 식당이 있다. 실력 있는 요리사 한 명으로 인해 억대 순이익을 내는 식당 A가 있고 레시피에 따라 누구나 만들 수 있는 음식을 가진 식당 B가 있다.

두 식당 중 어느 식당이 PER가 높은 식당일까?

바로 B식당이다. A식당은 실력있는 요리사가 일을 하지 않으면 식당은 크게 매출에 영향이 끼친다. 그러나 B식당은 누구나 레시피를 보고 요리를 할 수 있기 때문에 매출에 영향을 끼치지 않을 것이다. 쉽게 말해 지속적으로 퍼포먼스를 낼 수 있는 레시피를 가진 B식당이 가치가 높은 식당이라는 것이다.

이 때문에 개발도 체계적인 개발 프로세스를 따라야 하는 것이다. 체계적인 개발 프로세스를 따른다면 멤버가 바뀌거나 새로 투입 됐을 때 빠르게 적응하여 개발할 수 있다.

 

"코드는 창고 정리와 비슷한 면이 있다."

코드를 관리하는 것은 마치 창고를 정리하는 것과 비슷한 점이 많다. 창고를 깔끔하게 정리하고, 물건을 체계적으로 분류해 놓으면 필요한 물건을 찾을 때 빠르고 쉽게 꺼낼 수 있다. 하지만 만약 창고가 정리되지 않고, 물건이 무작위로 쌓여 있다면, 나중에 필요한 물건을 찾기 위해 창고를 뒤지고, 많은 시간을 허비하게 될 것이다.

코드도 마찬가지다. 체계적으로 작성된 코드는 가독성이 높아, 다른 개발자나 본인이 나중에 수정하거나 확장할 때 쉽게 이해하고 작업할 수 있다. 반면, 비체계적으로 작성된 코드는 그 구조가 복잡하거나 일관성이 없어, 새로운 기능을 추가하거나 버그를 수정할 때 많은 시간을 들여 코드를 분석해야 한다.

또한, 창고에 물건을 잘못 정리해 놓으면 다른 물건에 영향을 주듯, 코드 역시 비효율적으로 작성된 부분이 있으면 시스템 전체의 성능에 영향을 줄 수 있다. 코드를 체계적으로 관리하고, 정리하는 습관을 들이면 유지보수가 용이해지고, 코드의 재사용성도 높아지며, 오류 발생 가능성도 줄어든다.

창고 정리를 잘해두면 예상치 못한 상황에서도 빠르게 대처할 수 있듯이, 체계적인 코드 관리 역시 프로젝트의 장기적인 성공을 보장하는 중요한 요소다.

 

"어떤 게 체계적인 개발 프로세스일까?"

브레인스토밍 → 요구사항 분석 → 기획 → 아키텍처 설계 → API 설계 → 코드 설계 → 구현 → 테스트 → 형상 관리 → 이슈 관리 → PR(Pull Request) → 코드 리뷰 → 승인 → 배포 → 모니터링 → 유지보수

이러한 개발 라이프사이클을 따르는 것이 체계적으로 개발하는 과정이다.

또 API 설계, 객체 지향 설계, 아키텍처 설계, 디자인 패턴, 코드 컨벤션 등 설계 원칙을 정하고 따르는 것이 바로 지속적인 퍼포먼스를 낼 수 있는 레시피를 만드는 과정이고 이것이 체계적인 개발 프로세스인 것이다.

"포스팅을 마무리하며"

많은 개발팀에서 비체계적인 개발 프로세스를 선택하여 개발하는 경우가 많다. 이유는 업무 부담이 높아진다고 생각하기 때문이다. 그러나 단기적으로는 부담을 줄이는 것처럼 보일 수 있지만, 장기적으로는 더 큰 업무 부담을 초래하기 때문에 내가 소속한 기업에서 개발하고 있는 프로젝트가 지속적으로 꼭 필요한 것이라면 체계적인 개발 프로세스를 따르는 것이 어떨까?