디자인 패턴에 대한 스타트업 주니어의 생각

Outline

스타트업의 주니어 개발자로서 개발을 하다가 느낀점을 요약한다.

미래에 이 글을 봤을 때, 얼마나 바뀔지를 확인해본다.

 

Contents

현재의 나는 스타트업에서 백엔드 개발의 업무를 주로 맡고 있다. 인원이 부족하기 때문에, 사실상 나 혼자 개발하고 있기 때문에, 개발팀 내부에서의 협업과는 거리가 먼 상태이다. (프론트엔드 1명, 백엔드 1명)

 

디자인 패턴에 대해서는, 많이 듣기도 했고, 나름 학생때부터 신경 써왔다고 생각했기 때문에, 미래의 우리팀에 합류할 팀원들을 대비하여, 코드를 정리할 필요가 있다고 느꼈다. 적어도 그 사람들이 내가 작성한 코드를 보고, 난해하다를 느끼게 하고 싶지 않았다.

 

회사에서 업무를 하면서 느낀점은, 적절한 이유가 없이, 새로운 기술이여서, 인기가 있어서, 경험해보고 싶어서의 이유로 접근하기 시작하면 오히려 기술 부채로 더 개발이 느려지고, 이로 인해 비즈니스에 차질이 생길 수 있다는 것을 미리 알고 있었다.

 

나는 이를 명심하고 있었다. 회사에는 급박한 일정이 많았고, 실제로 설계와 기능을 구현하는데에 많은 시간을 쓰게 되면서, 테스트 코드 작성은 미루고 있었다. 새로 만든 기능, 수정된 기능으로 인해서 수동으로 테스트 하는 시간이 늘어나기 시작했고, 어느 시점 부터는 이 시간이 너무 아까워서 자동화 된 테스트가 필요하다고 느꼈다.

 

자동화된 테스트를 작성하게 될 것 이라고 생각했고, 테스트를 대비 하고 싶었기 때문에, 회사의 서브 서비스에는 repository pattern을 도입하였다. 

그러나 회사의 급박한 일정들이 닥치면서, 본 서비스에 서브 서비스의 코드를 옮기는 일이 생겼고, 백엔드 코드에 여러가지 디자인 패턴이 섞이면서, 나 이외의 사람이 알아보기 힘들게 되었고, 일정을 맞추기 위해 괴물이 되어가는 코드를 외면하였다.

그리고 이 과정에서 아직 발생하지는 않았지만, 치명적인 문제를 발견했는데, 현재 복잡한 계산을 위해서 모든 연산 코드는 DB에 일임을 한 상태였다.(Raw query로 복잡한 기능을 작성) 그러다 보니, 미래에 테스트를 도입한다면, query에 문제가 없는지 통합 테스트를 기준으로 테스트를 진행해야하는데, Mocking은 테스트를 신뢰 할 수 있을까? repository pattern을 통해서 in-memory 코드를 작성하고, 테스트 해야한다...? 너무 오버 엔지니어링이라고 생각했다.

 

"소프트웨어 장인 정신", "육각형 개발자" 책을 읽게 되면서, 더 늦기 전에 리팩토링을 해야겠다고 생각했다. 그리고, 간단한 수정이더라도 개발 시간이 늘어나기 시작하면서, 자동화된 테스트의 필요성을 느끼게 되었다.

 

기존에 섞여있는 디자인 패턴을 풀고자 했고, 규모가 작은 스타트업의 코드에서는 디자인 패턴의 필요성이 없다고 판단했다. 그래서 최소한의 일관성을 위해, model service view로만 분리를 하여 모든 소스코드를 분리했다. 또한, raw query의 결과에 대해서 model을 전부다 작성하여, type을 확실하게 보장하게 했고, 이로 인해서 swagger도 변하게 하여, front-end 개발자와 협업하기 더 편하게 바꿨다.

 

코드가 한결 보기 편해졌고, service 계층만 통합 테스트를 하더라도, 보다 빠르게 개발을 할 수 있을 거라고 생각했다.

 

 

end

본론이 길었지만, 정리하자면 규모가 작은 극초기의 스타트업에서의 개발에는 거창한 디자인 패턴이 필요없다고 생각한다. 오히려 디자인 패턴을 맞추는데 많은 시간이 들고, 복잡도가 늘어난다고 보았다. 특히 주니어인 나한테는 디자인 패턴에 대한 심도 깊은 이해가 없었기 때문에 더 독이 되지 않았을 까?

 

정말 필요에 따라서 적용하는게 중요한 것 같다. 방법을 고민해봤다면, 그 방법이 정말 그 문제를 해결하는데 도움이 되는지 다시 한번 생각해봐야 한다.