⚒️ 리팩토링은 비즈니스에 어떤 영향을 줄까요? (feat. 리팩토링은 적인가 아군인가...)

 

1. 리팩토링은 저~엉말 꼭 필요할까요?

개발을 하다보면 리팩토링은 필연적인 과정이 되곤 합니다. 불과 3개월 전 코드도 리팩토링의 대상이 되기도 하니까요. 그럼 그 이유는 무엇일까요? 🤔

제가 개발자가 아닌 다른 직군의 생각을 감히 대변해보자면 이럴 것 같습니다.

기능 추가나 업데이트도 바쁜데, 리팩토링은 왜 하는 거지?
애초에 처음부터 잘 만들면 되지 않나?
몇 개월 전에 만든 건데 왜 갈아엎는 거지?
지금 굳이 리팩토링 해야 하는 건가?

괜히 찔려서 이렇게 생각하게 됨 ㅋㅋㅋ

이에 대한 답변은 그때그때 마다 상황과 맥락에 따라 다를 수 있다고 생각해요. 그런데 개발자가 느끼기에 리팩토링이 필요한 경우는 대부분 (개발자 입장에서) 정말 필요한 경우이기 때문이에요.

리팩토링을 하려는 개발자는 코드를 보다 보면 정말 필요하다고 느끼기 때문에 리팩토링 욕구를 느낍니다. 오늘 짠 코드는 어제의 레거시라는 말이 괜히 있는 게 아니거든요.

개발자의 입장을 대변해 보자면 대부분 이럴 것 같아요.

이 코드는 현재 우리 개발팀의 컨벤션과 맞지 않아.
앞으로 벌어질 비즈니스 상황을 봤을 때, 여기는 무조건 수정해야 돼. (그땐 맞지만, 지금은 틀린 코드)
하.. 이때 왜 이렇게 짰지? 여기 뭐 추가할 때마다 너무 번거롭네.
최근 코드리뷰 때 피드백받았던 것 여기다가도 적용해야겠다.
앞으로 기능 업데이트를 속도감 있게 하려면 여기는 무조건 수정해야 돼.

뭐.. 제 생각엔 개발자나 다른 직군이나 양측의 입장은 모두 맞는 것 같아요.

개발자 입장에서는 리팩토링이 정말 필요한 게 맞고, 다른 직군의 입장에서는 지금 바로 수정하지 않고 (해당 직군 입장에서) 중요한 일 먼저 하는 게 맞다고 생각하기에, 즉, 서로의 업무 속 맥락에서 가장 중요한 게 다르기 때문에 발생하는 차이라고 생각해요.

 

2. 그럼 어떻게 결정해야 할까요?

리팩토링을 할지 말지 그럼 어떻게 결정해야 할까요?

모든 답은 현재 회사의 비즈니스 상황에 달려있다고 생각합니다.

리팩토링을 하는 경우는 작게는 지금 당장 할 일이 없을 때, 일 경우도 있겠지만, 이건 다른 직군과 의견차이가 날 일이 별로 없기 때문에 논외로 하고요 ㅎㅎ

리팩토링을 진짜 해야 하는 경우는, 해당하는 기능이 현재 비즈니스에 가장 중요한 부분인데, 현재의 코드를 리팩토링 없이 이어갈 때, 도저히 속도적인 측면이 안 나오거나 오히려 버그의 위험성이 높은 코드라고 판단될 때라고 생각해요. 그리고 그 판단은 오로지 개발자의 몫이에요. (이 판단을 할 수 있는지가 결국 개발자의 몸값이겠죠.)

 

3. 그럼에도 불구하고 리팩토링을 하지 않으면 안 될 때는 어떡할까요?

현재 기능을 리팩토링 없이 바로 이어서 개발해야 하는데, 리팩토링 없이 개발한다면 유지보수에 있어서 치명적인 결함이 될 것이라고 판단되는 경우도 분명 있어요. 이런 경우에는 이해관계자들에게 분명하게 공지를 해야 합니다.

“이 부분에 있어서 리팩토링이 없다면 오히려 개발 속도가 얼마큼 느려질 수 있고, 어떤 위험이 있다.”라는 걸 분명히 하고 그래도 비즈니스 적시성을 따져봤을 때, 지금 당장 필요한 작업이라면 비즈니스 결정권자와 책임을 나누는 게 중요하다고 생각해요.(나눈다고 쓰고 전가라고 읽는다.)

이게 왜 중요하냐면 단순히 안 좋은 상황 발생 시, 책임 떠넘기기를 위해 중요한 게 아니라, 하나의 팀 안에서 발생할 수 있는 리스크를 충분히 공유하는 측면에서 중요한 것 같아요. 비즈니스 적시성에 있어서 이 정도 리스크는 일단 감수하겠다.

그랬을 때, 얻을 수 있는 이득은 어느 정도이고, 리스크를 따져봤을 때, 얼마큼의 손실을 감당할지 비즈니스 결정권자도 함께 따져봐야 하기 때문이죠.

단순 리팩토링 하나 가지고 너무 많이 간 게 아니냐 싶을 수도 있지만, 좋은 개발자라면 팀으로서의 커뮤니케이션과 비즈니스를 함께 생각해야 하기에 너무나 당연한 생각의 흐름이라고 생각해요.

 

4. 필요하다면 이해관계자들을 어떻게 설득할 수 있을까요?

그럼에도 불구하고~ 또 그럼에도 불구하고 이건 도저히 안된다 했을 때, 그땐 설득해야 하겠죠..!

이 코드 품질로는 어떤 기능의 품질도 보장할 수 없을 것 같다. 그리고 명확하게 리팩토링을 했을 때 가져올 수 있는 이득에 대해서 설명을 하는 게 좋아요. 안 그러면 … 단지 자기의 사심을 채우려는 개발자로 밖에 안보일 수도 있습니다. 예를 들어, 팀보다 자기 커리어만 생각하는 개발자일 수도 있고, 비즈니스보다 단지 좋은 코드로 구현해서 받을 수 있는 자기만족일 뿐일 수도 있겠죠.

그렇게 보이지 않기 위해서는 리팩토링을 했을 때, 우리가 어떤 비즈니스적 이점을 가질 수 있는지를 명확하게 다른 직군과 소통할 필요가 있습니다. 가장 중요한 건 팀과 함께하는 일이고, 비즈니 스니까요.

 

5. 힘든 결정(리팩토링을 포기해야 할 때)

리팩토링을 포기해야 한다면?! 개발자로서는 너무나 아쉬운 결정이죠 ㅠㅠ 더 나은 코드도 만들고 비즈니스에도 더 빠르고 좋은 품질로 기여할 수 있을 거라 생각했는데, 그게 안 됐을 때 좌절감 ㅠㅠ.

만약… 리팩토링을 너무 하고 싶은데 도저히 일정이 안된다면, 저는 이런 방법을 추천드려요. 설계를 짬짬이 하고, 리팩토링 설계를 바탕으로 코드를 미리 쭉 구현을 해놓습니다. 그리고 이후 시간이 되는 때가 오면, 구현한 코드를 바탕으로 일정을 잡고 보완하면서 리팩토링을 마무리하는 단계로 하는 게 좋을 것 같아요.

음.. 결국엔 정말 정말 욕심이 있다면 뭐.. 야근하는 거죠 ㅠㅠ 그러나 개발자들에게 있어서 코드 구현은 야근일 수도 있고, 자기계발일 수도 있기에 이런 상황이 오면 저는 자기계발한다 생각하고 개발을 하곤 한답니다 ㅎㅎ

 

6. 리팩토링을 하고 나서

어렵게 어렵게 리팩토링을 하고 나면.. 끝일까요?

그렇다면 리팩터링 한 코드를 배포하고 나서 리팩토링 한 코드에서 발견된 버그는 온전히 내 책임일까요?

당연하게도 QA를 해야 합니다!! 물론 정식 QA프로세스가 없다면 이해관계자들이 다 같이 모여서 한 번씩이라도 기능 테스트를 해봐야 해요!!

보통 리팩토링을 진행하게 되면 개발자가 의견을 내고 진행하는 경우가 많은 것 같은데요.. 그러면 뜬금없이 다른 직군 사람들 같이 QA 해달라고 하기 좀 미안하지 않나요? 싶을 때도 있을 겁니다. 근데 무조건 해야 돼요!! 시간을 내서라도 부탁해서라도 하는 게 좋다고 생각합니다. 리팩토링 하고 QA를 안 해서 이슈가 발생하면.. 아니면 더 늦게 발견되면 히스토리 파악에도 어려움이 있고, 더 좋은 품질로 만든다고 했던 게 그게 아니게 되는 거예요. 리팩토링이 품질 관리의 하나의 측면인데, QA가 없으면 반쪽짜리 품질 관리라고 생각해요. 리팩토링 하고 나면 반드시 개발자는 책임감을 가지고 QA를 수행하는 게 좋다고 생각해요.

 

---

 

이렇게 오랜만에 글을 써봤는데요. 최근에 저도 리팩토링을 진행해서 관련된 글을 써봤어요. ㅎㅎ

저도 회사에서 개발을 하면서 리팩터링 할 일이 앞으로도 종종 생길 텐데, 항상 이 글을 보며 어떻게 하면 더 좋은 커뮤니케이션을 하고 회사 비즈니스에 올바른 결정을 하게 될지에 대해 고민을 하며 리팩토링을 하는 습관을 해야겠다고 다짐을 해봅니다😆