Startup 에서 개발하면서 느낀 Refactoring

1년 6개월동안 스타트업에서 서버 개발자로 일하면서 느낀  

Refactoring 경험에 대한 이야기

흔히 얘기하는  SI 에서 5년정도를 일하다 스타트업을 하게 된 한국의 흔한 개발자입니다.




흔히 스타트업에서 "리팩토링 한 50,000번 한다고 생각하세요" 우스갯소리(사실 진담일 확률이..90%)처럼 하는 말들인데..

1년 6개월이 지난 시점에서 생각해보니 저말은 50,000번을 채운사람들의 진심이 담긴 말이 맞는거 같네요.




다른 사람이 짠 소스를 보고는 뭐 이렇게 짰어? 구조적으로 왜 이렇게 지저분하게 짠거야..라고 말하긴 쉬운데

그 소스가 내가 짠 소스라면 다 그때는 그만한 이유가 있었을겁니다.




 - 급한 에러 수정이라 바로 deploy해야되서..

 - 너무 지쳐서 구조적인 설계보다 기능우선이 되야했기 때문에..




변명 혹은 해명일수도 있는데.. 

그럼 처음부터 그걸 고려 해서 하면 되지 않나요??? (만약 이런 생각을 하셨다면 수만명의 개발자의 원성을 사실지도...)

완벽한 설계 탄탄한 구조를 하기 위해선 시간과 사전 조사 제품 출시 기간이 오래 걸릴 수 밖에 없죠. 

물론 이렇게 시간을 많이 들이고 테스트와 검증을 많이 한다고 해도 완벽할 순 없습니다. 




지난 1주일동안 미루고 미뤘던 API-Server 전체 리팩토링을 5번을 했습니다.. 

처음부터 5번 할계획은 물론 없었어요..

처음에 리팩토링 우선순위를 정하고 리팩토링 스케쥴을 세우고 일부 리팩토링을 하고난후에 눈에 밟히는 코드들이 보이고 그 코드를 수정하니.. 

반드시 그렇게 했어야 했나 하는 생각이 들어서 리서칭을 하고 다른 방법을 찾다보니..




스마트 하지 않는 어제의 내모습을 지우고 싶어서 끝난 리팩토링을 또 다시.. 

해야하나 퇴근하는 버스안에서 고민해보고...




"미루면 나중에 후회한다" 는 깨달음으로 또 다시 리팩토링.. 







한국에서 활동하는 대부분의 SI 프로젝트에선 리팩토링이라는 단어 조차 생소합니다.




대부분의 프로젝트는 

 - 기획-> 개발-> 테스트 -> 오픈 

으로 진행되고

개발기간은 밤새우거나 야근을 하지 않고서는 일정을 맞추기가 쉽지 않죠..

(SI 에서 일해보시거나 일하는 분들은 너무나 잘 아실거라 설명은 하지 않겠습니다)

물론 오픈 1주일전(하루전에도...)에 기획이 바뀌는 경우는 다반사이다. 개발이 된 화면을 캡쳐해서 기획서를 수정하기도 한다..




오픈후에는 ?? 운영하는 팀으로 코드를 이행하니 이 프로젝트 소스는 운영팀이 리팩토링에 대한 열망을 가지고 있지 않는한..

리팩토링 될 가능성은 아주 희박하다...




5년동안 리팩토링을 해본적은 한두번 밖에 되지 않는다.. 프로그램 언어를 바꾸는 프로젝트만 리팩토링(개인프로젝트는 제외)







개인적인 시간에 Refactoring(Martin Flower), Clean Code,TDD 같은 리팩토링 관련 서적도 읽으면서 부족한 내 코드들이 부끄럽게 느껴졌지만 

실제로 프로젝트 전체를 리팩토링 해본 경험은 없어서 어떻게 해야되는지 어떤 코드를 수정해야되는지 

얼마나 해야하는지, 얼마나 걸릴지 감이 오지 않았다.. 해본결과 무엇을 상상하든 그 이상이라는 결론을 얻었다..




겨우 2만줄에 가까운 코드인데도 리팩토링하는데 전체를 다하는데는 짧게는 3일에서 길게는 5일이상이 걸리더라..

그리고 그 리팩토링은 때로는 수시로 때로는 2~3주마다 다시 해야되는 작업이기도했다..




스타트업에서 맘편히 리팩토링만 하는 시간은 주어지지 않는다..




대부분 개발을 진행하면서 리팩토링도 해야하고 운영에서 일어나는 수정사항, 버그들도 해결해야하면서 같이 해야된다.




 1. A(기존) 프로젝트 B(신규) 프로젝트 branch로 copy

 2. B 프로젝트 리팩토링 진행

 3. A 프로젝트 추가 개발진행, 수정사항, 버그 해결 ,DEPLOY

 4. B 프로젝트 리팩토링완료.

 5. A 프로젝트 변경사항 -> B 프로젝트에 반영 & 리팩토링 구조 적용

 6. B 프로젝트 Test

 7. Stage 반영 & Test

 8. Product 반영 & Test




이정도가 한 스코프라고 볼 수 있겠다. 




대부분의 서버 개발자들이 하는 일처럼 

 - 로그 모니터링 운영이슈 대응

 - 기획프로세스 검증 / 체크

 - 개발팀 인원 충원 

 - 팀 스프린트 관리

 - Cloud Service(AWS, Asure) 

는 베이스로 하는 일이라 따로 기술하지는 않았다.




저렇게 리팩토링 하면 만족스럽냐고 물어볼수도 있겠는데..




답변은.. yes 반, no 반이다. 




경험상 리팩토링은 Scrum에서 해당하는 하나의 Task에 불과하다

리팩토링의 끝??은 없다 자기 코드에 만족하면서 이 코드는 절대 수정,개선될 일말의 여지도 없다..라고 느끼는 코드가 있지는 않다.




모든 코드는 더 개선될 여지가 있고 몇 주씩이나 리팩토링만 할 수는 없다..




단지 리팩토링을 하다가 깨달은 개선점이나 문제점들을 발견하고 task에 등록하고 다음 리팩토링할 시기를 기다릴뿐이다.




language 버전업, framework 버전업 하는 시점또한 같이 고려해야된다. 그외 Third-Part Service 들의 api, lib 버전업도 모두 대상이다..




많은 밤들을 지새우면서 좀 더 나은 세상과 코드를 위해서 일하는 스타트업 & 개발자 분들 화이팅하세요.

Welcome to the Startup!