<div id="readability-page-1" class="page"><section itemprop="text">
        
          
        
        <p>최근 들어 TDD, 클린 코드, 클린 아키텍처, MSA, 디자인 패턴, 애자일 방법론 등 다양한 개발 방법론에 대한 논쟁을 접하면서 느낀 바가 있어 오랜만에 내 생각에 대한 글을 적어본다. 이러한 논쟁에서 어떤 견해가 옳고 그르다고 말하기는 어렵다. 따라서 각자의 기준을 가지고 개발 방법론에 대한 의견을 수용하는 것이 중요하고 본다.</p>

<h2 id="개발-방법론에-대한-회의적-시각의-배경">개발 방법론에 대한 회의적 시각의 배경</h2>

<p>인터넷에서는 “TDD는 죽었다.”, “테스트 코드 꼭 필요한가?”, “클린 코드는 좋지 않은 책이다.”, “디자인 패턴은 복잡함을 유발한다.”, “애자일은 이상적이다”는 의 내용을 가진 글을 쉽게 접할 수 있다.</p>

<p>이런 글을 접할 때면, 나는 그들이 왜 이런 주장을 하게 되었는지 짐작이 간다.</p>

<p>테스트 커버리지 100%를 달성하기 위해 수많은 시간과 노력 그리고 운영 코드를 변경하는 사람, 클린 코드를 추구한다고 코드 리뷰를 며칠씩 낭비하는 사람, MSA가 무조건 좋다고 서버들을 만들어내지만 정작 각 서버를 어떻게 유지 보수할지 계획은 없고 트랜잭션 관리에도 안중에 없는 사람, Event-Driven Development의 장점만 보고 섣불리 도입했으나 이벤트 관리가 되지 않아 특정 기능의 변경에도 여기저기 오류가 발생하여 높은 유지 보수비용을 감당하는 팀, 이상적인 스크럼을 수행한다고 작업자들이 실무에 집중할 수 없을 정도로 작업관리와 프로세스관리를 요구하는 스크럼 마스터 등 하나하나 나열하기에도 벅찰 만큼 다양한 사례들이 있기 때문이다.</p>

<p>이와 같은 경험을 지속적으로 겪다 보면, 해당 개발 방법론들이 부정적으로 받아들여지는 것은 당연한 반응일 수 있다. 해당 글을 쓴 사람뿐만 아니라 많은 사람이 그 글에 공감하는 것을 보면 얼마나 많은 이가 부정적인 경험을 겪었는지 알 수 있다.</p>

<h2 id="개발-방법론에-대한-나의-생각">개발 방법론에 대한 나의 생각</h2>

<p>먼저 나는 TDD 신봉자도, 엉클 밥 팬도, MSA 이상론자도, 애자일 찬양론자도 아님을 밝히고 시작하겠다.</p>

<h3 id="tdd">TDD</h3>

<p><a href="https://martinfowler.com/articles/is-tdd-dead/" target="\_blank">Is TDD Dead?</a>의 회의록에서 보면 Kent Beck은 아래와 같이 이야기하고 있다.</p>

<blockquote>
  <p>프로그래머들은 그들이 작성한 코드가 잘 동작하는 것에 확신을 가져야 마땅하며, TDD가 그렇게 만드는 방법 중 하나(유일하지는 않은)이다.</p>
</blockquote>

<p>즉, TDD는 개발자가 유익하다고 생각하는 여러 가지 방법 중 하나이지 유일한 방법은 아니라는 것이다.</p>

<p>어떤 개발자는 TDD 방법론이 무척 마음에 들어 TDD로 개발하지 않으면 마치 잘못 개발하고 있는 것처럼 이야기하기도 한다. 이것은 그 사람의 잘못된 생각에서 비롯된 것이지 TDD 방법론이 다른 방법론을 깎아내릴 만큼 완전한 방법은 아니라는 게 나의 생각이다.</p>

<h3 id="테스트코드">테스트코드</h3>

<p>“개발할 때 테스트 코드를 반드시 작성해야 하나요?”라는 질문은 이제 식상하리만큼 많은 사람이 했던 질문이다. 나는 아래와 같이 답변하고 싶다.</p>

<blockquote>
  <p>상황에 따라 테스트 코드를 작성하지 않아도 된다.</p>
</blockquote>

<p>무조건 테스트 코드를 작성해야 한다는 것은 실용적이지 않다고 본다. 한 번만 사용하고 버릴 코드나 단순한 스크립트의 경우, 테스트하기 상당히 어려운 코드들 같은 경우에는 과감하게 테스트코드 작성을 포기하고 좀 더 중요한 것에 집중해도 된다고 본다.</p>

<p>반대로 내가 작성하는 코드가 지속적으로 유지 보수되어야 하고 나를 포함해서 누군가가 향후에도 변경할 가능성이 있는 코드라면 테스트 코드를 작성하는 것이 좋다고 생각한다.</p>

<h3 id="클린-코드">클린 코드</h3>

<p>말도 많고 탈도 많은 클린코드이다. 어떡하다 이렇게까지 긍정적으로 쓰여야 할 단어가 부정적인 인식이 씌었을까 싶다.</p>

<p>읽기 쉽게 변수나 함수명을 작성하는 것, 불필요한 코드를 과감하게 지우거나 불필요한 주석을 사용하지 않는 것이 무엇이 나쁜가 싶다. 물론 클린 코드에서 주장하는 것 중 현실과 괴리가 있거나 억지스러운 것들이 있을 수도 있다. 그것은 견해의 차이지, 그것이 무조건 나쁘다고 할 수는 없다.</p>

<p>그러나 혹자는 클린 코드는 좋지 않은 책이니 주니어 개발자가 읽으면 좋지 않다고 말한다. 나는 그렇게 생각하지 않는다. 그들도 여러 가지 개발 방법론에 대한 견해를 습득하는 것이 좋으며, 나중에도 이야기할 그들 나름의 “원칙”을 정립할 양분으로 클린코드는 좋은 양분이라 생각한다.</p>

<h3 id="애자일">애자일</h3>

<p>개인적인 생각으로 여러 팀에서 애자일 방법을 도입하였으나 실패하는 이유는 목적보다는 수단에 집중해서라고 생각한다. <a href="https://agilemanifesto.org/" target="\_blank">Agile Manifesto</a>와 <a href="https://en.wikipedia.org/wiki/Extreme_programming_practices" target="\_blank">XP 실천법</a>을 모두 지키는 것만이 애자일 방법론을 따른다고 볼 수 없다고 본다. 오히려 팀의 상황에 맞지 않는 실천법은 구성원들의 거부감과 생산성 하락을 야기할 뿐이다.</p>

<p>반면 애자일 방법론을 부정적으로 바라봐야 할까? 하나하나 뜯어보면 당연하다고 생각할 만큼 맞는 말들이고 우리가 100%는 지키지 못하더라도 우리 팀만의 좀 더 나은 개발 문화를 위해 충분히 도움이 될 만한 실천법들이 많이 있다. 그러니 무조건 이상적인 애자일 방법론을 따를 게 아니라 우리 팀의 상황에 맞게 실용적으로 적용하면서 수단보다는 목적에 집중해서 자신들만의 개발 문화를 정립하는 게 좋아 보인다.</p>

<h3 id="기타-방법론">기타 방법론</h3>

<p>클린 아키텍처, MSA, Event-Driven Development, 이벤트 소싱, CQRS 등도 마찬가지다. 모든 개발 방법은 목적을 가지고 생겨났으며, 그 목적을 해결하기 위한 좋은 프랙티스를 제공한다. 특정 목적을 해결하기 위한 방법론은 반대급부로 다른 장점을 저해하거나 단점으로 작용할 수도 있다. 우리는 이러한 점을 숙지하여 자신의 상황에 맞게 방법론을 도입해야 할 것이다.</p>

<h2 id="자신의-원칙을-세우자">자신의 원칙을 세우자</h2>

<p>직장 동료 중 이런 글들을 보고 이런 말을 한 적이 있다.</p>

<blockquote>
  <p>결국 제품이 중요하다.</p>
</blockquote>

<p>이 말을 나름대로 해석하자면, 고객에게 가치를 제공하는 제품을 위한 더 나은 방법을 고민해야지, 제품의 가치 전달보다 특정 개발 방법론과 같은 수단에 집중하여 제품의 가치 전달이 뒷순위로 밀려나는 경우는 좋지 않다는 것이다.</p>

<p>나도 이 의견에 많이 공감한다. 하지만 “제품을 위한다”라는 말 또한 사람마다 기준이 다를 수 있다. 누군가는 테스트 커버리지 100%가 제품을 위한 것일 수도 있고, 누군가는 변경의 용이성을 위해 향후 10년 뒤에 변경될 수 있는 요구사항까지 수용해야 한다고 할 수 있다.</p>

<p>그래서 나는 더 나아가 “자신만의 원칙”을 세워야 한다고 생각한다. 테스트 코드는 불필요하다는 내용의 글을 보았다고 “나는 앞으로 테스트 코드는 작성하지 말아야지”라고 생각하거나 반대로 테스트 코드를 작성하지 않는 것은 장인정신에 어긋난다는 내용의 글을 보았다고 “테스트 커버리지 100%를 달성하지 않으면 좋지 않은 코드다”라고 말하는 등의 갈팡질팡하는 모습을 보이지 않아야 한다는 것이다.</p>

<p>그렇다면 그 “원칙”은 무엇일까? 나도 철학을 논할 만큼 깊이 있는 견해를 가졌다고 말할 수 없지만 내가 생각하는 원칙은 “개발자로서 소프트웨어 개발에 대한 자신만의 기준으로써 더 나은 제품을 만들기 위한 다양한 노력에 대한 기준점”이라고 볼 수 있을 것 같다.</p>

<h2 id="결론">결론</h2>

<p>이전에 여행 관련 개발 회사에 다닐 때 개발실의 제1원칙이 있었다. 바로 “여행 상품 검색 속도는 0.3초를 넘기지 않아야 한다”는 것이다. 제품을 만들 때 이 원칙을 위반하면 그 어떤 좋은 기능이라도 반려되었고, 그 결과 해당 서비스는 여행 상품의 검색이라는 아이덴티티를 계속해서 유지할 수 있었다.</p>

<p>나는 개발자라면 제품을 개발하는 데 이러한 “원칙” 하나쯤은 가지고 있으면 좋겠다고 생각한다. 앞서 말한 대로 개발방법론에는 은탄환은 없는 경우가 많다. 그렇기 때문에 특정 방법론에 매몰되기보다 우리만의 제품의 원칙을 세우고, 우리가 보다 나은 코드로 가치를 전달하기 위한 가장 합리적인 방법론을 선택하고 실용적으로 적용하는 그런 자세 말이다.</p>

        
      </section></div>

Veluexer’s Blog

최근 들어 TDD, 클린 코드, 클린 아키텍처, MSA, 디자인 패턴, 애자일 방법론 등 다양한 개발 방법론에 대한 논쟁을 접하면서 느낀 바가 있어 오랜만에 내 생각에 대한 글을 적어본다. 이러한 논쟁에서 어떤 견해가 옳고 그르다고 말하기는 어렵다. 따라서 각자의 기준을 가지고 개발 방법론에 대한 의견을 수용하는 것이 중요하고 본다.
개발 방법론에 대한 회의적 시각의 배경
인터넷에서는 “TDD는 죽었다.”, “테스트 코드 꼭 필요한가?”, “클린 코드는 좋지 않은 책이다.”, “디자인 패턴은 복잡함을 유발한다.”, “애자일은 이상적이다”는 의 내용을 가진 글을 쉽게 접할 수 있다.
이런 글을 접할 때면, 나는 그들이 왜 이런 주장을 하게 되었는지 짐작이 간다.
테스트 커버리지 100%를 달성하기 위해 수많은 시간과 노력 그리고 운영 코드를 변경하는 사람, 클린 코드를 추구한다고 코드 리뷰를 며칠씩 낭비하는 사람, MSA가 무조건 좋다고 서버들을 만들어내지만 정작 각 서버를 어떻게 유지 보수할지 계획은 없고 트랜잭션 관리에도 안중에 없는 사람, Event-Driven Development의 장점만 보고 섣불리 도입했으나 이벤트 관리가 되지 않아 특정 기능의 변경에도 여기저기 오류가 발생하여 높은 유지 보수비용을 감당하는 팀, 이상적인 스크럼을 수행한다고 작업자들이 실무에 집중할 수 없을 정도로 작업관리와 프로세스관리를 요구하는 스크럼 마스터 등 하나하나 나열하기에도 벅찰 만큼 다양한 사례들이 있기 때문이다.
이와 같은 경험을 지속적으로 겪다 보면, 해당 개발 방법론들이 부정적으로 받아들여지는 것은 당연한 반응일 수 있다. 해당 글을 쓴 사람뿐만 아니라 많은 사람이 그 글에 공감하는 것을 보면 얼마나 많은 이가 부정적인 경험을 겪었는지 알 수 있다.
개발 방법론에 대한 나의 생각
먼저 나는 TDD 신봉자도, 엉클 밥 팬도, MSA 이상론자도, 애자일 찬양론자도 아님을 밝히고 시작하겠다.
TDD
Is TDD Dead?의 회의록에서 보면 Kent Beck은 아래와 같이 이야기하고 있다.
프로그래머들은 그들이 작성한 코드가 잘 동작하는 것에 확신을 가져야 마땅하며, TDD가 그렇게 만드는 방법 중 하나(유일하지는 않은)이다.
즉, TDD는 개발자가 유익하다고 생각하는 여러 가지 방법 중 하나이지 유일한 방법은 아니라는 것이다.
어떤 개발자는 TDD 방법론이 무척 마음에 들어 TDD로 개발하지 않으면 마치 잘못 개발하고 있는 것처럼 이야기하기도 한다. 이것은 그 사람의 잘못된 생각에서 비롯된 것이지 TDD 방법론이 다른 방법론을 깎아내릴 만큼 완전한 방법은 아니라는 게 나의 생각이다.
테스트코드
“개발할 때 테스트 코드를 반드시 작성해야 하나요?”라는 질문은 이제 식상하리만큼 많은 사람이 했던 질문이다. 나는 아래와 같이 답변하고 싶다.
상황에 따라 테스트 코드를 작성하지 않아도 된다.
무조건 테스트 코드를 작성해야 한다는 것은 실용적이지 않다고 본다. 한 번만 사용하고 버릴 코드나 단순한 스크립트의 경우, 테스트하기 상당히 어려운 코드들 같은 경우에는 과감하게 테스트코드 작성을 포기하고 좀 더 중요한 것에 집중해도 된다고 본다.
반대로 내가 작성하는 코드가 지속적으로 유지 보수되어야 하고 나를 포함해서 누군가가 향후에도 변경할 가능성이 있는 코드라면 테스트 코드를 작성하는 것이 좋다고 생각한다.
클린 코드
말도 많고 탈도 많은 클린코드이다. 어떡하다 이렇게까지 긍정적으로 쓰여야 할 단어가 부정적인 인식이 씌었을까 싶다.
읽기 쉽게 변수나 함수명을 작성하는 것, 불필요한 코드를 과감하게 지우거나 불필요한 주석을 사용하지 않는 것이 무엇이 나쁜가 싶다. 물론 클린 코드에서 주장하는 것 중 현실과 괴리가 있거나 억지스러운 것들이 있을 수도 있다. 그것은 견해의 차이지, 그것이 무조건 나쁘다고 할 수는 없다.
그러나 혹자는 클린 코드는 좋지 않은 책이니 주니어 개발자가 읽으면 좋지 않다고 말한다. 나는 그렇게 생각하지 않는다. 그들도 여러 가지 개발 방법론에 대한 견해를 습득하는 것이 좋으며, 나중에도 이야기할 그들 나름의 “원칙”을 정립할 양분으로 클린코드는 좋은 양분이라 생각한다.
애자일
개인적인 생각으로 여러 팀에서 애자일 방법을 도입하였으나 실패하는 이유는 목적보다는 수단에 집중해서라고 생각한다. Agile Manifesto와 XP 실천법을 모두 지키는 것만이 애자일 방법론을 따른다고 볼 수 없다고 본다. 오히려 팀의 상황에 맞지 않는 실천법은 구성원들의 거부감과 생산성 하락을 야기할 뿐이다.
반면 애자일 방법론을 부정적으로 바라봐야 할까? 하나하나 뜯어보면 당연하다고 생각할 만큼 맞는 말들이고 우리가 100%는 지키지 못하더라도 우리 팀만의 좀 더 나은 개발 문화를 위해 충분히 도움이 될 만한 실천법들이 많이 있다. 그러니 무조건 이상적인 애자일 방법론을 따를 게 아니라 우리 팀의 상황에 맞게 실용적으로 적용하면서 수단보다는 목적에 집중해서 자신들만의 개발 문화를 정립하는 게 좋아 보인다.
기타 방법론
클린 아키텍처, MSA, Event-Driven Development, 이벤트 소싱, CQRS 등도 마찬가지다. 모든 개발 방법은 목적을 가지고 생겨났으며, 그 목적을 해결하기 위한 좋은 프랙티스를 제공한다. 특정 목적을 해결하기 위한 방법론은 반대급부로 다른 장점을 저해하거나 단점으로 작용할 수도 있다. 우리는 이러한 점을 숙지하여 자신의 상황에 맞게 방법론을 도입해야 할 것이다.
자신의 원칙을 세우자
직장 동료 중 이런 글들을 보고 이런 말을 한 적이 있다.
결국 제품이 중요하다.
이 말을 나름대로 해석하자면, 고객에게 가치를 제공하는 제품을 위한 더 나은 방법을 고민해야지, 제품의 가치 전달보다 특정 개발 방법론과 같은 수단에 집중하여 제품의 가치 전달이 뒷순위로 밀려나는 경우는 좋지 않다는 것이다.
나도 이 의견에 많이 공감한다. 하지만 “제품을 위한다”라는 말 또한 사람마다 기준이 다를 수 있다. 누군가는 테스트 커버리지 100%가 제품을 위한 것일 수도 있고, 누군가는 변경의 용이성을 위해 향후 10년 뒤에 변경될 수 있는 요구사항까지 수용해야 한다고 할 수 있다.
그래서 나는 더 나아가 “자신만의 원칙”을 세워야 한다고 생각한다. 테스트 코드는 불필요하다는 내용의 글을 보았다고 “나는 앞으로 테스트 코드는 작성하지 말아야지”라고 생각하거나 반대로 테스트 코드를 작성하지 않는 것은 장인정신에 어긋난다는 내용의 글을 보았다고 “테스트 커버리지 100%를 달성하지 않으면 좋지 않은 코드다”라고 말하는 등의 갈팡질팡하는 모습을 보이지 않아야 한다는 것이다.
그렇다면 그 “원칙”은 무엇일까? 나도 철학을 논할 만큼 깊이 있는 견해를 가졌다고 말할 수 없지만 내가 생각하는 원칙은 “개발자로서 소프트웨어 개발에 대한 자신만의 기준으로써 더 나은 제품을 만들기 위한 다양한 노력에 대한 기준점”이라고 볼 수 있을 것 같다.
결론
이전에 여행 관련 개발 회사에 다닐 때 개발실의 제1원칙이 있었다. 바로 “여행 상품 검색 속도는 0.3초를 넘기지 않아야 한다”는 것이다. 제품을 만들 때 이 원칙을 위반하면 그 어떤 좋은 기능이라도 반려되었고, 그 결과 해당 서비스는 여행 상품의 검색이라는 아이덴티티를 계속해서 유지할 수 있었다.
나는 개발자라면 제품을 개발하는 데 이러한 “원칙” 하나쯤은 가지고 있으면 좋겠다고 생각한다. 앞서 말한 대로 개발방법론에는 은탄환은 없는 경우가 많다. 그렇기 때문에 특정 방법론에 매몰되기보다 우리만의 제품의 원칙을 세우고, 우리가 보다 나은 코드로 가치를 전달하기 위한 가장 합리적인 방법론을 선택하고 실용적으로 적용하는 그런 자세 말이다.

개발 방법론에 대한 나만의 원칙 세우기

댓글