기술 선택과 좋은 구현에 대한 이야기

feat. 딜레마

개발하면서 좋은 구현이란 무엇일까? 앞으로의 이야기는 당연한 소리일 수 있고 아닐 수도 있지만 가끔 질문을 받아서 한번 글을 써본다.

좋은 구현이란?

필자가 생각하는 좋은 구현이란 코드의 가독성이 좋아야 하며, 변경에 유연하고, 테스트 코드 작성이 쉬운 것이라 생각한다. 근데 과연 이것뿐일까? 이 세가지도 중요하지만 정말 중요한 것은 비즈니스 가치를 명확히 충족시켜야 한다. 가끔 개발자 중에 오로지 기술에 대해서만 집중하고 기술적 성취에 대해서만 관심을 가지는 분들이 있다. 필자는 이런 분들께 우린가 좀 더 좋은 기술, 더 나은 기술을 찾는 이유는 비즈니스 목표 달성이란 것을 말하고 싶다. 기술은 비즈니스 가치를 만들어낼 수 있어야 그 존재의 가치가 있다고 생각한다. 기술 선택의 기준이 내가 하고 싶어서, 유행하는 거라서, 멋있어 보인다는 이유로 선택하는 건 아닌지 다시 생각해보자. 기술 선택은 현재와 가까운 미래의 비즈니스를 고려한 것 이어야 한다.

클린코드와 리팩터링

필자의 다른글을 보면 알겠지만 필자는 클린코드와 리팩터링을 중요하게 생각한다. 비즈니스의 가치를 지속하고 향상시키기위해서는 클린코드와 리팩터링이 필요하다고 생각한다. 그럼에도 필자는 깔끔한데 동작 안 하는 코드보다 더럽더라도 동작하는 코드가 낫다고 생각한다. 물론 처음부터 깔끔하고 빠르게 피쳐에 맞는 구현 하면 좋다. 그렇지만 어디 모든 게 사람 마음처럼 되겠는가.. 그게 되지 않는다면 처음부터 깔끔하게 만들려고 하지 말자. 우선 기능이 되게끔 구현한 후에 리팩터링을 하자. 리팩터링을 당장 할 시간이 없는가? 그렇다고 더러운 코드를 그래도 두고 리팩터링 안 하면 안 된다. 나중에 리팩터링 해야지 하고 하지 않은 적이 많은가? 그럴 수 있다. 그래서 돌아가게끔 구현하고 당장 바로 리팩터링 하는 것이 좋다. 그렇지만 모든 상황에서 이 방법이 가능하지 않을 수 있으니 괜찮다. 중요한것은 관심이다. 우리는 최대한 지속적으로 관심을 가지고 리팩터링 해야 한다. 이후에 반드시 리팩터링 하자!

그리고 이 과정에서 테스트 코드를 만들자. 테스트 코드는 코드와 나를 지키는 길이다. 요구사항은 수시로 변경되고 리팩터링을 해야 하고 이럴 때마다 우리는 예상하지 못한 버그가 발생하지 않을까 하는 막연한 두려움이 있다. 이를 막을 수 있는 좋은 방법은 테스트 코드 작성이다. 테스트 코드는 지속적인 피쳐 릴리즈와 리팩터링을 가능하게 해주는 안전장치이다. 게다가 테스트 코드 작성이 쉽다면 대체적으로 코드 품질이 좋은 편일 확률이 높다. 코드가 테스트 코드 작성하기 쉬운 지도 함께 분석해보자. 만약 TDD를 통해 개발했다면 이미 테스트 코드는 존재할 것이다. 필자의 글에서도 소개했지만 TDD의 아이러니는 TDD가 테스트기술이 아니라는 점이다. TDD는 분석 기술이며, 설계 기술이기도 하다. 그리고 의사결정과 피드백 사이의 간극을 의식하고 이를 제어하는 기술이다. TDD사이클을 따르다 보면 리팩터링도 가능하다(물론 그럼에도 일정 시점마다 리팩터링이 필요할 수 있다).

'구현 -> 리팩터링' 사이클을 반복하면 처음에 생각하지 못했던 여러 요소를 발견하게 되고 도메인 지식도 더 깊어진다. 그러면서 과거와는 다른 시각으로 코드를 바라볼 수 있게 되며 더 나은 설계, 더 나은 코드가 나오게 된다.

균형

코드 구현과 비즈니스는 둘 다 중요하다. 정해진 시점에 기능이 릴리즈 되는 것은 중요하다. 상황을 맞추기 위해 중복 코드와 하드 코딩이 필요하다면 어떠한 선택을 할 것인가? 필자를 포함한 많은 개발자들이 딜레마에 빠지게 되는 상황이다. 필자는 최대한 정석을 따르려고 한다. 하지만 정말 그 상황이 여의치 않다면 중복 코드나 하드코딩을 해서라도 비즈니스 속도를 맞춰야 한다고 생각한다. 다만! 이런 구현은 반드시 정리하고 리팩터링 해야 한다! 비즈니스의 가치를 지속하고 향상하기 위해서는 최대한 깔끔하고 유연한 코드를 유지해야 한다.

두 줄 요약

- 기술로 비즈니스의 성공을 도울 수 있는 개발자가 되자.

- 기술 선택은 현재와 가까운 미래의 비즈니스를 고려하자