실무에서 서비스 리팩토링, 지금 계신 회사는 어떠신가요?

Question

안녕하세요 저는 대략 8년 정도 연차(13년 사회 생활 시작)로 작년에 한 스타트업에서 입사하여 모바일 앱 개발을 맡고 있습니다.입사해서 코드를 열어 봤을 때... 뭔가 좀 난감하더라고요...이건 왜 이렇게 짰지?... 아니 대체 왜?... 투성이었습니다.작년 한 해는 입사 초기 열정?이 있어서 신규 기능, 기존 기능 수정 등 개발하면서 기존 코드들의 이상한 부분, 이해가 가지 않는 그런 부분들을 열심히 리팩토링했습니다. 뭐 제가 완벽히 이해하지 못한 비즈니스때문에 regression 이슈도 많이 터졌죠.. 그러고는 좀 리팩토링을... 내가 완벽히 코드 레벨에서 이해가 되지 않는 이상은 가급적 건드리지 않고 있긴 합니다.그런데 좀 의문인게.... 서비스 전체 사양을 잘 정리한 문서가 보통 원래 있지 않나요? 이전 회사에서는 사양을 잘 정리한 문서가 있었고, 그 사양문서를 관리하는 담당자, 사양팀이 있었습니다.그런데 여기 오니까 그런게 없더라고요... 문서도.. 스프린트/프로젝트 단위로 사양 문서가 있긴 한데, 그게 끝입니다. 서비스 전체적으로 한눈에 볼 수 있는 문서가 없어요.. 문서가 프로젝트 단위로 끊어서 파편화되다 보니... 기존에 나간 기능을 수정하는 경우에는 하나의 기능에 대해 2개의 사양이 존재하게 됩니다. 최신 사양 문서가 아닌 이전 사양 문서를 보게 되면... 잘못된 사양을 이해할 수 있게 되죠...리팩토링하는데 regression 이슈가 많이 났던 이유는... 제가 사양을 완벽히 이해하지 못한 것이고, 사양을 완벽히 이해하지 못한건... 코드가 이미 스파게티라 코드 레벨로 이해하는 것은 한계가 있었기 때문입니다. 그렇다면 만약 내가 리팩토링하고자 하는 기능에 대해 잘 정리된 사양문서가 있다면, 차라리 새로 구현하는 것도 가능했을 것도 같습니다. 새로 구현하고 정의된 사양에 대해 테스트 코드를 작성해 넣으면 참 좋은 개발 환경이 되겠지요..그런데 현실은 사양 문서는 파편화되어 있고, 코드 레벨로 이해하는 건 한계가 있고, 테스트 코드도 없고...그래서 윗선에 계속 의견을 개진했습니다. 하나의 서비스를 운영하는 회사에서 사양 문서가 없는건 말도 안된다고요...몇개월 이야기를 하다 보니 받아들여져서 사양문서를 한번 정리하려고 하는 것 같습니다. 그런데 하면서 리팩토링도 프로젝트로 꾸려서 진행을 하려나 봅니다.하반기 4Q에 PM, 개발자들 모아 리팩토링 일정을 잡고 진행하려고 하는 것 같은데... 이건 좀 아닌 것 같은데...제가 생각하는 리팩토링은... 마치 식사하고 설겆이, 양치질하는 것과 같아서... 평소에 해둬야지.. 몰아서 일정잡고 요이땅해서 하는 건 아니라고 생각이 듭니다. 그럼 또 일회성으로 끝날 것 같아서... 제가 원하는 건 평소에도 리팩토링을 할 수 있는 버퍼 시간을 개발자들에게 주어서 리팩토링 문화가 내부 프로세스로 자리를 잡는건데... 윗분들의 생각은 저와는 많이 다르네요.. ㅠ개발 문화가 성숙?한 곳의 얘기를 들어보면 한 스프린트 기간 동안 기능 구현해서 릴리즈를 하면, 바로 다음 스프린트가 시작되는게 아니라 회고 시간을 갖고 리팩토링을 하기도 한다고 들었습니다아마도... 현실은 제가 처한 것과 크게 다르지 않을 거고.. 이런 개발 문화가 성숙한 곳은 별로 없을 것 같단 생각이 듭니다.그래도... 들어 보고 싶습니다. 다들 어떠신가요..?

준호 · Answer

방법론적으로는 말씀하신 게 맞다고 생각이 되는데.. 지금 산출물도 없고 스파게티 소스에 테스트 케이스도 없는 상황에서 특정 시점에 코드를 한번 정리하지 않는 이상은 방법이 없지 않나요? 보통 그런 요건들이 모여서 신규 프로젝트를 띄우죠

gandhi · Answer

지금 다니고 있는 회사도 크게 다르지 않습니다회사 임원들은 소스가 스파게티든 짜장면이든 상관없이운영이 문제없이 돌아가는게 당연한거 아니냐는 생각입니다문제 생기면 그때부터 책임소재 때문에 신경쓰는척? 왜 제대로 안했냐 라고 책임전가를 하죠나중에 책임은 다 개발자에게 전가됩니다.기술부채라던가, 나중에 손도 못된다, 사고 터진다 라는 식의 협박?으로 필요하다라는걸(자기에게도 피해가 온다) 인식 시켜야 됩니다.

Aaron · Answer

준호그렇겠네요...근데 하.. 13만 라인을 리팩토링할 자신이... ㅠ

엡실론 · Answer

전체 사양을 잘 정리한 문서라는게 가능한가요? 서비스 운영하다 보면 수많은 기능이 추가되고, 삭제되고, 수정될텐데요. 전체 사양 문서는 폭포수 모델에서는 잘 맞는데, 애자일과는 맞지 않는 듯 합니다. 그리고 애자일이 나온 배경이 끊임없이 변화하는 소프트웨어에 대응하기 위해서라는 걸 생각해보면, 서비스와 전체 사양 문서는 맞지 않을 것 같습니다.지금은 리팩토링이 문제가 아니라 테스트 코드가 없는 게 더 큰 문제입니다. 테스트 코드가 없이는 잠깐 짬을 내서 하는 리팩토링은 불가능합니다. 이 상황에서는 차라리 프로젝트로 잡아서 하는 게 맞습니다. 경험하셧듯, 이 상황에서 리팩토링은 리그레션의 위험이 너무 큽니다. 충분한 테스트 코드가 만들어지고 나면 그다음에는 생각하신 것처럼 틈틈이 할 수 있죠.

Mambo · Answer

https://www.youtube.com/watch?v&#61;jdlBu2vFv58 이상과 현실은 다를 수 있어요.제가 일하고 있는 회사도 중요성은 알지만 의지가 부족합니다.

cookker · Answer

회사나 팀의 정책도 중요하지만, 개발자들의 개선의지도 중요합니다.그래서 저라면 이렇게 해볼거 같은데요. 1. 코드리뷰 문화를 만듭니다.> 새로운 코드를 작성할때 좋은코드만 생성되도록 하고, 기존의 코드를 수정하여 개발하는 건은 스카우트 원칙을 따르도록 합니다. 2. 테스트코드를 짜도록 독려합니다.> 리팩토링을 하기전에 잘 돌던 코드가 리팩토링 이후 돌지 않는다면 이후에 무서워서 리팩토링을 하지 못합니다.테스트코드를 짜서 코드가 잘 도는 것을 확인하고, 인풋 아웃풋은 그대로 둔체 코드를 개선합니다.코드 개선 이후에도 테스트코드가 잘 돈다면 리팩토링은 성공한 것이고아쉽지만 리아키텍처링은 많은 코드가 정리된 이후에 진행하기로 합니다. 3. 테스트코드가 없으면 PR을 하지 못하도록 합니다.(약간의 강제성) 1번부터 시간을 두고 차근차근 해 보시는건 어떠실까요.

실무에서 서비스 리팩토링, 지금 계신 회사는 어떠신가요?

6개의 답변

#refactoring 목록