들어가기 앞서

어찌저찌 시간이 흘러가다보니, 23년도 찾아오고 항해는 어느새 실전 프로젝트 주차에 와있었다. 해당 프로젝트 기간이 6주가 되면, 항해는 끝나있을 것이다.
그럼, 나는 이제 이력서를...

이쯤에서 거두절미하고,
실전 프로젝트 1주 동안 어떤 어려움이 존재했는지 기록하려고 한다.

프로젝트 소개

우리 조는 일정 관리 서비스를 진행하게 됐다. 자세하게 말하면, 불렛 저널이라는 다이어리 방법론을 도입해서 스케쥴러와 합친 셈이다. 여러 가지 아이디어들이 존재했지만, 기존의 서비스와 차별점을 가진다는 것이 쉽지 않은 일이였다.

기획 단계

디자이너, 프론트, 백엔드 드디어 총 집합이다. 세 개의 직군이 뭉쳐서 협업을 진행했다. 매번 느끼지만, 협업한다는 것이 여간 쉬운 일은 아니었다. 커뮤니케이션 능력이 상당히 필요하다는 것을 다시 한 번 느꼈다. 그래서 시장은 의사소통을 잘 하는 개발자를 좋아하는 것 같다.

소통의 어려움

기획하면서, 늘 하던대로 소통하면서 와이어 프레임을 그리고 어떻게 그리는 것이 좋을 지에 대해 합의점을 찾아갔다.

위에서도 언급했지만, 소통하는 일은 굉장히 어렵다고 느꼈다.
나는 백엔드 개발자다. 그래서 그런지 대화를 나눌 때도 개발이라는 단어에 중점적으로 얘기를 하고 있다는 것을 많이 느끼게 되었다. (디자이너와의 협업이 이번에 처음이기에)

반면, 디자이너분은 사용자적인 측면을 많이 고려했던 것 같다. 어쩔 수 없는 것이 UX/UI 라는 것이 사용자와 관련된 모든 요소를 고려해야 하니, 어쩔 수 없다고 생각했다. 그래서 서로 의견이 다를 때도 있었다. 이를 하나로 합치는 합의점을 찾는 것이 굉장히 쉽게 느껴지면서도 어려웠던 것 같다.

코드 컨벤션

백엔드 코드 컨벤션을 작성할 때, 이미 작성해놓은 컨벤션에 대해 쿠팡에서 5년을 일하시고, 스타트업에서 CTO를 맡으신 분께 피드백을 받았다. 우리 조의 기획서를 보니, 현직자가 있다고 해도 무방할 정도로 문서화가 잘 되어있다고 칭찬을 받았다. (기분은 좋았다..^^;)

이제 본론으로 들어가면, Builder 패턴에 대해 짧게(?) 멘토님과 가벼운 토론을 할 수 있던 시간을 가질 수 있게 되었다. 우리 조는 Builder 패턴으로 객체를 생성하는 방식을 채택했다. 하지만, 멘토분께서는 현업에서는 Builer 패턴으로 인해, 내가 통제할 수 없는 일들이 쉽게 벌어질 수 있다고 말씀해주셨다. 당연히 공감되지 않았다. 나는 그런 경험을 해본 적이 없으니. 그래도 이해하려고 노력했다.

신입 개발자가 와서 Builer가 public으로 풀려있으니, "아, 빌더 패턴으로 객체를 생성하면 되겠구나"하면서 막무가내로 객체를 찍어냈을 경우, 휴먼 에러가 발생할 수 있다는 것(매개변수를 넣지 않는 값이 있을 경우 디폴트 값으로 멤버 필드에 값이 세팅됨)과 확장성이 너무 커질 수 있다고 하셨는데 이건 이해가 되지 않아, 다음주에 질문 드리려고 한다.

개인적으로 Builder패턴을 사용하면, 생성자 방식과 달리, 파라미터의 순서를 알지 못 해도 객체를 생성할 수 있다는 장점이 있다. 또한, 직관적이다. 무슨 값이 들어가는지 메서드 이름으로 나와있기 때문이다. 즉, 가독성이 좋다. 이러한 장점으로 인해 도입하려고 했던 컨벤션이 와르르,,,

아니면, Builder 패턴에 검증 방식을 도입해야 하는 것일까? 라는 생각도 해봤다. (Assert 라이브러리와 Object의 내장 메서드를 통해서)
하지만, 이는 런타임 에러 시, Exception을 터트려주기 때문에 이미 결과가 발생한 것이라 근본적인 해결이 되지 않았다.

그래서 우리팀은 정적 팩토리 메서드를 사용하기로 했다. 근데, 이걸 또 사용하자니 "메서드 오버로딩을 해야 하는 걸까?" 캡슐화를 위해 오버로딩을 하거나 "모든 파라미터를 받는 메서드를 생성해주어야 하는 걸까?" 그리고 "파라미터가 많으면 이 또한 휴먼에러를 불러일으키지 않을까?" (IDE가 아무리 좋아졌다고 해도.)

그런 말이 있지 않나. 똥인지, 된장인지는 먹어봐야 안다.

그래서 직접 사용해보면서 체험해보기로 했다.

오늘 어떤 블로그글에서 직접 경험해보지 못 하면, "왜 이렇게 사용할까?"에 공감을 쉽게 할 수 없다는 글을 봤다. 진짜 맞는 말인 것 같다. 빌더 패턴도 사용을 지양하는데, 우리 조는 고통을 겪어보지 못 했으니 사용하자고 했던 것과 정적 팩토리 메서드도 빌더 대신 모든 경우에서 사용하자는 것도 마찬가지기 때문이다.

고통을 느껴보고, 코드에 대해 피드백을 받아볼 예정이다.

새로운 기술 스택

이 부분도 굉장히 염려되는 것 중 하나의 요소다. 지금까지는 자바와 스프링부트라는 프레임워크를 배웠다. 이는 당연히 백엔드 개발자라면, 기본적으로 지식이 있어야 하는 것이라고 생각한다.

하지만, 새로운 기술 스택은 다르다. 프로젝트에서 자바와 스프링부트로 얼마든지 서비스를 만들어낼 수 있다. 하지만, 어떻게 이 서비스를 더욱 더 빛나게 할 수 있는지는 자바와 스프링으로 해결할 수 없다. 즉, 다른 무언가들이 더 필요하다는 것이다. 또한, 시간이 6주라는 문제점도 존재한다. 6주안에 도입하려는 기술 스택에 대해 완벽히 이해하고, 적용하는 것까지 쉽게 할 수 있을까라는 의문도 든다.

그런데 어쩌겠나. 런칭할려면 해야지.

맺으며

이러한 걱정들과 함께 1주일을 보냈던 것 같다. 앞으로 5주라는 시간이 남았고 이 기간동안 열심히 하면 별 탈 없이 런칭할 수 있을 것이라고 믿어 의심치 않고 있다..ㅎㅎ;

아직 코딩을 시작하지 않았지만, 아마 지금이 일요일에서 월요일로 넘어가는 새벽이니 오늘부터 코딩을 시작할 것 같다.

열심히 서비스 로직을 짜고 서로 코드리뷰를 깐깐하게 진행하면서 잘 헤쳐나가야할 것 같다.