블라인드에 올라온 코드 팩토링 관련 좋은 글.

이 문제는 비난할 것이 아니라, 도와줘야 하는 문제라고 생각합니다.

특정 방법론, 원칙에 얽매이는 분들은 본래 높은 생산성을 유지하기 어렵습니다.

 

우리가 워드로 소설을 쓴다고 가정해봅시다. 일단 간단한 플롯이 나왔으면 글을 써야 합니다.

 

중간에 오타가 나거나, 주인공 이름을 촌스럽게 지었거나, 해당 페이지 편집 디자인이 이쁘지 않아도 일단 내용을 먼저 채워넣어야죠.

 

내용이 영 별로라고 판단되면, 그때가서 몇 번이고 다시 갈아엎는 과정을 거쳐 내용을 가다듬어야 합니다.

 

그리고나서, 나중에 오타, 촌스러운 주인공 이름, 우스꽝스러운 페이지 디자인을 고치면 됩니다.

 

그러나, 방법론, 원칙에 얽매이는 분들은 이런 시행 착오의 시간이 무의미한 시간 낭비이며, 실수를 저지르는 과정이라고 보기 때문에 반드시 피해야 할 상황이라고 생각하는 경향이 있습니다.

 

그리고, 해당 방법론, 원칙이 한번에 완벽한 코드를 짤 수 있게 도와주어, 시간 낭비를 줄인다고 오해하는 경향이 있죠.

 

하지만, 개발은 어려운 부분이 많고 신경써야할 부분이 많습니다. 안그래도 심리적 부담이 큰데, 방법론/원칙이라는 심리적 부담까지 지게 되면... 머리가 매우 복잡해지죠.

 

더구나, 처음 한번에 완벽한 코드를 짠다는 건 심리적 부담이 매우 큽니다.

 

결국, 그런 심리적 부담은 사람을 궁지로 몰아넣기 때문에... 코드가 안나옵니다.

 

이런 상황이 남들이 보기에는

“완벽한 코드를 짜기 전에는 아예 코드를 안짤래”

라고 고집을 부리는 것처럼 보이지만, 실제로는

 

지켜야할 방법론, 원칙 등 다양한 지식이 주는 심리적 부담에 압도되어... 코드를 짤 엄두를 못내고 있는 것입니다.

 

등산에 비유하자면, 보통 사람들이 등산 가방 하나만 매고 산을 오른다면, 이런 분들은 등산 가방 열 개를 한꺼번에 등에 지고 산을 오르는 것입니다.

 

당연히 남보다 느릴 수 밖에 없고, 심지어 가방 10개의 무게에 짖눌려 한걸음 발을 때는 것조차 엄두가 안날 수 있습니다.

 

소설의 비유로 돌아가자면, 남들은 내용에만 집중하고 있는 단계에서, 이분들은 오타, 주인공 이름, 페이지 디자인까지 한꺼번에 신경쓰고 고치려고 합니다. 후반부에 나올 상황에 대한 복선을 깔아두는 것까지 미리 고민하고 있죠.

 

이런 프로그래머들에게는

“너무 처음부터 완벽하게 짜려고 노력할 필요없다. 일단, 그냥 함수/메소드 이름을 짓는 걸로 시작하자. 최대한 멍청하고 우스꽝스러운 함수 이름이 좋겠다. soStupidMethod 어떠냐? 메소드 이름이 멋진 것 같다. 지금 단계에서는 이 정도만으로도 충분하다. 우리 지금 일단 발 한걸음 뗀거 아닌가? 시작이 반이라는데, 그럼 이미 기능 구현 50% 끝낸거 아닌가? Excellent하다. 이런 높은 생산성은 내가 주니어 시절에는 엄두도 못꾼 일이다.”

 

“내일 벌어질 일을 오늘 고민하지 마라. 내일은 또다른 내일의 고민이 찾아올 것이다. 오늘 미리 고민하면 억울하고 손해다.”

 

“어차피 개발은 여러 사람이 하나의 기능을 수십번 뜯어고쳐야 제대로 돌아가는 제품이 나온다. 우리 코드 중 3번 이상 재작성하지 않은 부분은 우리가 모르는 어떤 버그가 잔뜩 있을 거다. 재작성하는 건 제품을 고도화하는 필수적인 과정이다. 재작성을 피해야 한다고 생각하지 말고, 오히려 재작성을 거의 안한 부분이 품질이 떨어지는 건 아닌지 의심하는게 좋다.”

 

“어차피 개발은 축구 경기와 비슷하다. 지금 네가 실수하더라도, 네 뒤에는 우리 팀이 있다. 실수를 두려워하지 마라.”

 

“한걸음 한걸음 발을 떼어 걸어나가다보면, 어느 순간 산정상에 도착해있게 된다. 지금 단계에서 미리 산정상을 바라보고 있으면 쉽게 지칠 수 있다. 아마 중간에 발을 헛디뎌 넘어지는 순간도 올 것이다. 근데, 넘어져서 다치는게 두렵다면, 집 밖에 나올수도 없는 것 아닌가? 넘어지는 거 걱정하지 마라. 네가 넘어지면 우리 팀 중 누군가 손을 잡아줄 것이다.”

라고, 격려를 해주는 것이 좋습니다.

 

불필요한 심리적 중압감을 해소해주고, 본인 스스로가 원칙을 깨는 경험을 여러번 해보면서, 생산성의 차이를 느끼게 되면... 본인 스스로가 천천히 방법론, 원칙의 함정에서 벗어나게 됩니다.

 

소설가들 중에는 경력이 쌓이고나면, 글을 쓰기 위해 책상에 앉는 것조차 고통스러울 정도의 상황이 오는 경우가 있다고 합니다. 워드에서 깜박이는 커서가 자꾸 글을 쓰라고 재촉하는 것같아 두려움을 겪는 분도 있다고 합니다.

 

초보 때와 달리 아는게 많아지면서, 처음부터 너무 좋은 글을 쓰려는 욕심에 사로잡혀 정작 한 단어조차도 쓰지 못하는 것이죠.

 

이런 분들에게 필요한 것은 더 많은 지식이나 비난이 아니라...

 

마음의 짐들을 벗어던지고, 두려움과 맞서 싸울 수 있게... 격려해주고, 지지해주는 주변 사람들의 도움입니다.

 

“그래, 코드가 형편없어도 돼.”

 

“일단 오늘 한 줄이라도 썼으면 대단한거야. 살다보면 하루에 한줄도 못쓰는 경우도 많거든.”

 

이렇게 격려해주세요.

 

단, 이 방법의 단점은...

방법론, 원칙의 세뇌 효과는 생각보다 대단합니다.

 

상대방이 당신은 평소에 형편없는 코드나 짜고, 품질 따위는 안중에도 없는 무능한 시니어 개발자라고 오해할 가능성이 “매우” 높습니다.

 

하지만, 괜찮습니다. 결국 계속 같이 팀에 있다보면... 그 친구들도 점진적 개선의 힘을 깨닫게 될 것이고,

 

당신이 점진적 개선을 통해 작성한 코드가 그 수많은 방법론, 원칙에서 이런 코드가 좋은 코드라고 했던 바로 그런 코드라는 걸 결국 깨닫게 될 것입니다.

얼마전에 읽은 책(?), 블로그 글(?)에 보니...

 

“프로젝트를 반드시 실패하는 증명된 방법이 있다. 해당 프로젝트의 기술 스택에 대해 일단 책 10권을 읽고 시작하라. 당신의 제품은 영원히 완성되지 않을 것이다”

라는 내용이 있었는데...

 

인상이 깊더군요.

 

과도한 지식의 함정에 빠진 동료를 비난하지 말고, 도와주세요.

 

과도한 지식에 대한 갈망은 반대로,

“내가 제대로 하고 있는 건가? 이 코드, 잘짠건가? 너무 아마추어적인 코드 아닌가? 프로들은 이 따위로 안짜겠지?”

라는 자기 불신, 자신감 부족에서 나오는 것입니다.

 

즉, 그는 불안한 것입니다.

 

이런 상황의 사람에게 비난은 더 큰 자기 불신을 불러 일으키기 때문에, 프로젝트 생산성이 더욱 떨어집니다.

 

자기 확신을 갖도록 도와주는게 좋습니다.

완벽한 코드는 환상입니다. 유니콘 같은 것이죠. 실제로 존재하지 않는...

 

상대적으로 좋은 코드, 상대적으로 나쁜 코드가 있지만... 이것도 상황에 의존적인 것이지... 절대적으로 이건 나쁘고, 이건 좋은 건 없습니다.

 

예를 들면, 대규모 분산 환경에서 퍼포먼스 최적화를 한 코드는, 임베디드 환경에서 최악의 퍼포먼스를 보일 가능성이 높습니다.

 

처음부터 좋은 OO 설계를 염두에 두고 짠 좋은 코드는, 순수 Functional programming 관점에서는 형편없는 설계와 구현을 한 코드일 가능성이 높습니다. (물론 프로젝트가 OO, Functional 모두를 염두에 둔 hybrid 환경일 경우에는 잘짠 OO 코드와 잘짠 Functional 코드는 상호 유사한 경향이 있습니다)

 

풍부하고 직관적이며, 깔끔한 expression을 선호하는 개발자 입장에서는, 온갖 기괴한 퍼포먼스 최적화 테크닉이 적용된 코드가 형편없이 보일 것입니다.

 

지금 처한 상황에서 더 중요하게 요구되는 부분에 포커스를 맞춰야 하는 부분이지, 항상 모든 상황에서 좋은 코드란... 없다고 생각합니다.

 

우리가 미덕으로 생각하는 중복 제거나 최적화 역시... 프로젝트 초기에는 문제 도메인이 이렇다고 생각해서, 그에 맞게 설계를 하고 중복을 최대한 제거하고 퍼포먼스를 최적화한 코드가...

 

프로젝트 중간에 보니, 문제 도메인이 사실은 달랐습니다. 그래서, 전부 다시 쪼개고, 설계를 바꾸고, 최적화한 거 전부 제거해야 하는 경우는 생각보다 자주 발생합니다.

 

즉, 중복적인 코드가 남발된 형편없는 초기 코드를 그대로 놔둔 편이... 실제 프로젝트에서는 더 나은 선택으로 밝혀지는 경우가 꽤 많다는 것이죠.

 

때문에,

- 원하는 기능대로 구현되었으면 일단 O.K.

 

- Comment가 있으면 좋겠지만, 계속 설계와 구현이 바뀐다면 comment 없어도 O.K.

 

- Test 코드 있으면 좋겠지만, 계속 feature가 바뀌고 있다면 feature가 fix되고 나서 Test 코드 넣어도 O.K.

 

이 정도면 무방하다고 생각합니다.

(이런 생각은 과거의 저라면, 혐오하는 생각입니다)

 

지금 깔끔하고 좋은 코드가, 프로젝트 중반이나 후반에 가서, 팀 전체의 생산성을 갉아먹고, 심지어 설계 변경이 불가능해서 편법으로 우회기법(workaround)을 적용해야만 하는 최악의 쓰레기 코드가 될 수 있습니다.

 

반대로 지금 쓰레기처럼 형편없이 보이는 코드가 프로젝트 후반에 가서, 팀 전체에게 4주의 시간을 절약해준 최고의 선택이 될 수도 있습니다. (그건, 그때 가봐야 압니다)

 

자신감을 가지세요. 좋은 코드로 만들고, 중복을 제거하고, 퍼포먼스를 최적화하는 건 프로젝트 후반에... 그게 필요하다고 판단될때 하면 됩니다.

 

그리고, 그때가서야 보입니다.

우리, 개발자이지 예언자 아니잖아요.

지금 할 수 있는 것만 하면 됩니다.

미래에 일어날 어떻게 될지 모르는 것을 위해 미리 뭔가를 해두는 건, 불필요하고... 심지어, 미래의 변화에 적절하게 대응하는 걸 방해할 가능성이 높습니다.

 

일단, 프로젝트의 기능 요구 사항대로 작동하는 코드를 만들었습니까? 잘한 것입니다.

 

좀 더 개선하고 싶은 부분이 있습니까? 프로젝트 전체의 요구 사항과 설계가 여전히 계속 바뀔  것 같다면, 앞으로 개선하고 싶은 부분을 잘 메모해놓았다가, 나중에 그게 필요해질 때 하면 됩니다.