얕고 다양한 경험

한양대학교 놀러가서 찍은 야경

코로나로 인해 만나지 못하니 대학 동기와 Zoom 으로 프로그래밍에 대한 대화를 자주 나누곤 한다. 대게 내가 알려주고 친구가 질문하는 방식이였다.

"처음부터 아무리 설계를 해도 언젠가는 바뀌어야 하지 않아?"

설명하는 도중에 동기가 나에게 물었다.

곰곰이 생각해봤다.

 

"그러한 변경사항을 유연하게 반영하기 위한 것이 디자인 패턴의 한 역할이야" 라고 답변을 해주려다가

 

이렇게만 설명하면 뭔가 명료하지 않고 뒤에 설명도 재미가 없어질 것 같아서

내가 디자인 패턴에 대해서 깨닫게 된 기나긴 과정을 설명해주기로 했다.

지금까지의 경험상 프로그래밍 프로젝트는 4가지로 나눌 수 있다.

 

 

이게 정확히 분류가 가능한지는 모르겠지만 설명하면서 생각난 분류이다.

해커톤 대회

나는 개인 프로젝트와 해커톤 대회로 무언가를 만들어내는 프로그래밍을 시작했다.

해커톤 대회 같은 경우는 인원이 한정되어있기 때문에 한 포지션을 한 명씩 맡을 수밖에 없기 때문에  
내 코드를 다른 사람이 보게 될 일은 적다.

대신 짧은 시간에 어떠한 방법을 써서라도 결과물을 만들어내야 하고
우선 돌아가는 게 중요했다. 기본이 거의 없는 고등학생이 어찌어찌 검색해서 만든 코드는 읽을 수 없을뿐더러
본인도 왜 동작하는지 모르는 일이 다반사였다.

시간이 짧은 만큼 기획에 대한 추가 변경도 잦은 편은 아니다. 기획자가 개발자를 죽일 목적이 있는 것이 아니라면
아침에 회의하고 정했던 내용을 가져가게 되며, 불가피하게 변경해야 하는 상황은 보통 개발 쪽 이슈로 나오게 된다. 

이 때문에 코드에 대한 확성성은 더욱 떨어지게 된다.

해커톤이 나쁘다는 이야기는 아니다. 만약 처음 웹 공부를 시작한 사람에게는 눈에 바로바로 보이는 것이 재미있지,
갑자기 웹 접근성에 관해서 설명하고 DOM의 역사에 관해서 이야기하면 절반은 지루해 할 것이다.

지식을 빠르게 익혀보는 부분에서는 좋지만, 해커톤만 다니다 보면 장기적으로 나쁜 코드 습관이 들 수 있다.

 

 

외부 프로젝트 / 공모전

 

외부 공모전 같은 경우에는 보통 짧게는 한 달 길게는 3달 정도 기간을 준다. 해커톤보다는 확실히 코드를 개선할 수 있는 시간이 충분히 주어진다. 

하지만 포지션에 있어서는 해커톤과 마찬가지로 공모전도 인원이 제한적이기 때문에 한사람이 한 포지션을 담당하게 된다.

이때부터는 과거의 내 코드와의 싸움이다. 함수 이름을 asdf 로 만든 내 몇 주전의 나를 욕하면서 코드를 개선해 나아간다. 

처음에는 차근차근 계획을 잡고 나아가지만 기간이 3일 남은 공모전은 공모전이 아니라 해커톤이다. 보통 대부분 문제점은 이 시기에 발견되는데 공모전의 특성상 제출 후에는 유지 보수할 일이 없고 무사히 돌아가는 작품이 제출만 되면 되는 일이기 때문에 개발자는 해커톤처럼
안 좋은 코드를 작성하게 된다.

 

외주

 

각종 공모전과 해커톤을 오가면서 그 분야에 대한 자신감이 생기고 상금을 받다 보면 금전적으로 욕심이 생기게 된다. 

그래서 보통 외주를 시작하게 된다.

외주 코드가 모든 변경사항에 대응할 수 있도록 작성하면 나중에 엄청나게 편하지만, 마감기한과 지급금액은 정해져 있다.

내가 맘대로 예측해서 대응하는 코드를 짜면 짤수록 금전적으로는 당장에는 손해이다. 

외주는 위의 2가지와 다르게 제출하고 끝이 아니다. 상과 상금은 못 받으면 그만이지만 외주는 잘못되면 법정 싸움까지 걸 수 있는 것이다.

실제로 마감기한에 늦은 외주가 하나 있었는데 클라이언트 측에서 늦은 마감을 빌미로 추가기획을 마구 요구했었다.

이에 대응하려고 기존코드에 추가 기획을 얹게 되었고 그렇게 만들어진 불안정한 결과물은 각종 버그를 만들어냈다.

클라이언트로서는 시간을 아무리 줘도 자꾸 버그만 생기는 결과물에 대해서 불만을 품는 일이 발생했었다.

이미 너무 지친 상태에서 코드를 유지보수하기란 쉽지않은 일이였고 이를 해결하려고 코드를 다시 짜기에도 이미 너무 늦은 시기였다.

 

회사 프로젝트

 

정말 여러 가지 프로젝트를 겪고 회사로 오게 되었다. 여기의 가장 큰 장점은 내 코드를 누군가 리뷰해줄 수 있다는 것, 그리고 기획변경에 유연하게 대처할 수 있는 코드를 작성할 수 있는 시간이 있다는 것이다.
앞선 실패 경험을 바탕으로 안정적인 디자인 패턴을 적용해서 서비스를 제작할 수 있었고, 예상대로 급격한 기획 변경에도 개발적인 공수가 많이 들지 않았다.

위에서 저런 고생이 없었다면 회사를 와서 디자인 패턴을 마치 지침서를 따르듯이 적용했을 것 같다는 생각이 든다.

 

결론

 

친구의 단순한 질문으로 시작된 설명이였지만, 내 머릿속으로만 생각하고있던 내용을 정리할 수 있어서 많은 도움이 되었다.