철저히 개인적인 경험을 기반으로 작성한 글이고 정답이라고 절대 생각하지 않습니다.
작년에 우아한테크코스를 하면서 팀원들과 정말 많은 토론을 했습니다. 그때 실무에 대한 경험이 없었기 때문에 대답하기 어려웠던, 저에게 고민이 많이 됐던 질문들에 대한 생각들을 정리해봤습니다.
-
실무에서 작성하는 코드는 정말로 잘 작성된 코드일까? 정답에 가까울까?
실무에서는 이렇게 한데취업 준비를 할 때 이 말이 나오면 반박하기가 어려웠습니다. 현업에서 사용한다는데 좋겠지 그게 더 올바른 선택이었겠지 이렇게 생각하고 수용하고 이해해보려고 노력했습니다. 지금은 생각이 많이 다릅니다. 회사 두 곳을 다니면서 리팩토링이라는 단어가 괜히 존재하는게 아니고, 코드가 작성되어 배포되기 까지는 영향을 미치는 여러 변수를 만났습니다. 우아한 코드(예술)와 실행 가능한 코드(기능) 사이에서 적절한 타협이 필요한 상황이 많이 펼쳐집니다. 하나의 기능을 구현하는데 시간을 무한정 허락해주지 않을 뿐더러, 개발외에 처리해줘야하는 일들이 많습니다. 온콜 대응, 데이터 확인, 아이디어 회의, 아키텍처 회의, 관련 부서들과의 회의 등 당장 맡은 기능 개발 외적으로 해야할 일들이 굉장히 많습니다. 우아한 코드만을 작성하고 고민하기에는 시간이 모자랍니다. 물론 개발팀에서도 코드리뷰를 통해서 최대한 개선하고 스터디를 하면서 더 나은 코드에 대한 고민을 하고 있습니다. 하지만 시간이 많지 않고, 해야할 일들은 많습니다.
취준할 때는 일주일 동안 고민만하고 기능이 개발되지 않더라도 큰 문제가 되지 않습니다. 하지만 회사에서는 그렇게 일을 진행할 수는 없었습니다. 목표가 있고 그에 맞는 기간을 산정해서 일을 진행하기 때문에 기간에 맞춰서 기능 개발하는 것이 더 중요합니다. 저희 회사의 규모가 작기 때문에 상대적으로 해야할 업무가 더 다양하고 많을 수도 있을 것 같습니다.
작년에 저에게 저는 실무에서 사용하는 코드는 정답에 가까울거라는 생각을 과감히 버리라고 말해주고 싶습니다. 가져야할 자세는 어떤 방식이든지 우리가 의심을 하고 더 나은 방향을 찾아보자, 설령 틀릴지언정 그런 고민들이 실력을 길러준다고 생각합니다. -
코드 컨벤션을 어떻게 맞추는게 좋을까?
절대 모두가 만족하는 컨벤션을 지킬 수 없습니다. 위에서 말한 것처럼 개발 외적으로 써야하는 시간이 굉장히 많습니다. 인텔리제이 컨벤션 스키마, 소나린트, 소나큐브 등 도구들로 최대한 커버를 하고 코드리뷰에서 최대한 걸러내려고 합니다. 하지만 모든 컨벤션을 하나로 맞추려는 생각은 위험합니다. 소프트웨어 엔지니어링이 다른 엔지니어링 직군보다 유연한 프로덕트를 만들어낸다는 관점에서 생각해봤을 때 정확성에 대한 가치가 상대적으로 높지 않다고 생각합니다. 이 업계의 핵심은 신속하고 점진적인 개선 과정을 지속적으로 유지하는 행위라고 생각합니다. 컨벤션도 마찬가지로 맞으면 좋다고 생각합니다 가독성이 좋은 코드가 최고라고 생각합니다. 하지만 어쩔 수 없습니다 혼자서 개발하는 것이 아니기 때문에 서로 작성하는 방법을 완전히 합치시킬 수는 없습니다. 어느정도의 타협이 필요합니다.
개발 속도와 코드 스타일의 획일성을 놓고봤을 때 저는 전자가 더 중요하다고 생각합니다. 계속 말해왔듯이 시간이 많지 않고 해야할 일은 많기 때문입니다. 혹자는 획일성을 맞추면 오히려 읽는 속도가 빨라지기 때문에 결과적으로 효율적이라고 주장할 수 있습니다. 제가 거의 스타트업 규모에서 일하고 있어서 그럴 수도 있겠습니다. 그 의견에도 동의하는 바가 많지만 당장 코드 리뷰를 끝내고 상호합의하에 merge를 하는 과정을 겪으려면 생각보다 시간이 정말 많이 소요될 수있고 소모되는 감정적 에너지가 많다고 생각합니다. 어느정도 서로를 용인해주는 선에서 정말 중요하다고 생각하는 컨벤션은 그때그때 짧은 커뮤니케이션을 통해서 정하면서 나아가는 방식이 저희에게는 적합했습니다.
-
테스트와 TDD
테스트 중요합니다. TDD는 잘 모르겠습니다. 우아한테크코스에 과정들은 TDD를 기반으로 진행됩니다. 저 또한 모든 과정을 TDD로 진행하려고 했고 거의 80~90% 작업을 TDD로 진행했습니다. 신규 기능을 개발할 때 어느정도의 장점에 대해서는 동의하지만 이게 더 효율적인 방법인가에 대한 의문점은 많습니다. 애자일한 개발은 작은 단위의 개발과 CI / CD를 통한 지속적인 빠른 배포가 중요하다고 생각합니다. 개발하는 단위를 잘 쪼개서 작게 가져간다면 TDD를 할 필요도 없을 수준의 설계가 머릿속에 그려집니다. 켄트 벡의 TDD 책에서 진행하는 과정중에 리팩터링의 과정에 대해서는 긍정적으로 생각하지만 레드 / 그린 방식에 대해서는 잘 받아들여지지 않습니다. 과연 인간이 이 과정을 자연스럽게 받아들일 수 있는 프로세스인지에 대한 의구심도 있습니다. TDD를 접하는 대부분의 사람들이 처음에 TDD의 흐름을 이해하는데 시간을 쏟지만 해석하는 방식이 다양해서 수행하는 방식이 달라지는데 저는 꼭 가져갈 필요가 있는지 모르겠습니다.
테스트 커버리지에 대해서도 높은 테스트 커버리지는 독이라고 생각합니다. 오히려 유연한 변경에 대응하기 어렵게 만들고 발목을 잡아 삭제하는 경우를 경험하면서 적정선에 대한 고민을 하게되는 것 같습니다. 지금은 최소한의 성공 테스트와 정말 독특한, 중요한 엣지케이스를 제외하고는 테스트를 안만드는 것이 중요하다고 생각합니다. -
회사에서는 페어프로그래밍을 하는가?
페어 프로그래밍으로 교육받고 계속 진행해왔습니다. 지금도 페어 프로그래밍이 가지는 생산성에 대해서 동의하는 부분도 많습니다. 환경이 허락한다면 저도 페어프로그래밍을 하고 싶습니다. 근데 그런 회사가 올바른지에 대한 의문은 듭니다. 요즘 구조조정하는 회사가 점점 늘어나고 있습니다. 스타트업들이 적자를 내는게 당연했던 호황기에 비교하면 지금은 비용감축과 이 시기를 무사히 보내려는 회사들이 많아졌습니다. 개발자들의 연봉은 많이 올랐습니다. 페어프로그래밍 좋죠 그런데 가성비가 떨어진다고 생각합니다. 개발해야할 건이 A,B가 있는데 페어프로그래밍으로 A를 하고 B를 한다. 저도 한번 비교를 해보고 싶긴한데 직관적인 생각으로는 같이 하나씩 처리는 것보다는 병렬처리가 빠르지 않을까 하는 생각이 있습니다. 코드 리뷰 하는 시간이 줄어든다는게 큰 장점이겠지만 둘이 시간을 맞추고 진행하는 것보다는 혼자서 빠르게 코드를 만들고 공유하는게 더 효율적이지 않으까 하는 생각입니다. 나중에 여유가 생긴다면 한번 테스트해보고 싶은 부분인긴 합니다. 정말로 페어프로그래밍이 솔로 프로그래밍 보단 효율적인지?
-
객체 지향
객체 지향은 만능이 아닙니다. 저는 객체지향 방식의 코드 작성을 사랑합니다. 하지만 트랜잭션 스크립트 방식 절차 지향 개발 방식대로 하는 것에 대한 장점도 있습니다. 직관적이고 하나의 메서드에서 많은 것을 확인할 수 있습니다. 상대적으로 객체지향은 단위를 잘게 나눠서 메서드가 여기저기 분산되기 때문에 작아집니다. 제가 회사에 처음 왔을 때 모노리식으로 작성되어있어서 너무 좋았습니다. 자바 개발자인데 루비를 봐야하는 상황이었는데 객체지향은 처음에 발목을 잡았습니다. 타입 추론 언어고 덕타이핑때문에 메서드를 추적하기 어려웠거든요. 만약 절차 지향으로 짜여있다면 파악하기 더 편하지 않았을까 생각했습니다.
마찬가지로 저에게는 MSA도 비슷한 느낌입니다. 코드가 전부 MSA로 작성되면 그만큼 파악하기 어려워 집니다. 전체흐름을 바라보기에는 모노리식이 더 낫다고 생각합니다. 규모에 따라 운영해야하는 사이즈에 맞는 개발도 중요하다는 생각을 합니다. -
소통
제일 중요합니다. 팀원들간의 신뢰관계 형성이 제일 중요하다고 생각합니다. 지금 팀원들을 너무 잘 만나서 회사에 가는 부담이 전혀없고 오히려 행복합니다. 이것만으로 많은 것이 이뤄집니다. 의견을 편하게 낼 수 있고 더 나은 방향에 대해서 고민할 떄 너무 든든한 존재입니다. 삶의 질이 몇배는 올라갑니다. 소통에 문제가 없기 때문에 관련된 스트레스를 받지 않습니다. 당연히 업무에 집중하기도 쉽습니다. 삶 자체가 그냥 행복해집니다. 어딜가나 다들 좋은 사람 만나고, 누군가에게 좋은 사람이 되기를 바랍니다.
취업 준비를 하면서 환상속의 실무 코드를 보고 일을 하면서 느꼈던 점들을 가볍게 정리해봤습니다. 물론 아직 경험이 많이 모자라고 저도 언제든 생각이 바뀔 수 있을거라고 생각합니다. 혹시 저처럼 실무에 대한 환상(?)이 있으신 분들에게 도움이 됐으면 하는 마음에 작성해봤습니다.
