Intro

지난 1달 동안 총 3분의 리뷰어 분들과 함께 미션에 대한 피드백을 주고 받게 되었다.

그러다 이러한 피드백을 받게 된 적이 있었다.

자바스크립트의 모든 기본 기능들을 조금은 과하게 의심하거나 틀어보는 경향이 있으신 것 같습니다. ... 기존 코드스타일에 의문을 가지고 탐구해보는 것은 좋지만, 모든 것을 바꿀 필요는 없습니다.

우테코라는 학습 과정에 있으신 만큼 코치님들이 미션마다 제안 해주시는 요구사항을 충족시킬 수 있는 방향을 우선적으로 고려해서 기능을 구현하면 좋을 것 같습니다.

그 동안 코드 퀄리티를 높이기 위해 연습하고 학습했던 과정들이 정말 나에게 옳았던걸까?를 스스로 반성하고 회고하기 위해 이번 글을 작성하게 되었다.

나는 정말 함께 하고 싶은 개발자 였을까?

그 동안의 나는 기술적인 부분에서 피드백을 바라고 있었겠다고 생각하게 되었다.

항상 클린 코드와 가독성 좋은 구조 들에 대해서만 매달려 정작 내가 지향했던 것인 함께 하고 싶은 개발자인지 다시 한번 고민하게 되었다.

내가 지향하던 함께 하고 싶은 개발자의 소망은 다음과 같았다.

1. 원활한 커뮤니케이션을 통해 오해할만한 상황 만들지 않기

2. 주어진 문제 상황을 해결하기 위한 최적의 방법을 고민하기

만약 이러한 소망들이 지금 하고 있는 미션이라고 가정한다면 나는 어쩌면 2가지 조건 모두를 충족하지 못했겠다는 생각이 들었다.

나는 지금 함께 하고 싶은 개발자가 아닐지도 모른다.

내 코드를 확인하는 사람(직장 동료, 리뷰어 등등)들은 내가 왜 이러한 코드를 작성했는지에 대한 의사결정 과정 및 배경 들을 쉽게 파악하기 힘들다.

리뷰를 할 때도 기술적인 사항들 보다는 아래와 같은 사항들을 고려해볼 것이다.

1. 주어진 코드를 통해 현재 필요한 비즈니스 적인 요구 사항들을 충족하는가?

2. 요구 사항 이외 사용자 경험(UX) 측면을 고려한 코드인가?

3. 기능을 확장하더라도 구조적인 변경이 필요 없는 코드 인가?

즉, 기술적인 시도나 접근 방법이 아닌 사내 비즈니스를 만족시킬 수 있는 최적의 결정이었는지를 우선적으로 검토해볼 것이다.

또한, 특정 기술을 사용했다면 그 기술에 대한 충분한 의사결정과 배경지식을 함께 제공해줘야 더 이해하기 쉬울 것이다.

물론 기술적인 고민도 하는 것이 중요하겠지만, 그 고민은 위 3가지 사항들이 고려되었을 때 나중에 해도 되는 고민인 것이다.

이러한 관점들에서 보았을 때 3가지 사항을 다 지켰냐고 물어본다면 나는 이렇게 말할 것이다.

아직 하나도 지키지 못했다.

당장 하고 있는 미션을 예로 들어보자.

Bad Case(#1)

나는 미션에 대한 PR에 대해 다음과 같이 작성했다.

웹 컴포넌트

connectedCallback과 disconnectedCallback과 같은 생명 주기 메서드 사용 및 하나의 역할 부여를 위해 custom-elements를 사용했습니다.

또한, BaseComponent를 만들어 공통 로직을 관리했습니다.

웹 컴포넌트가 DOM의 commit 되는 과정은 아래와 같이 진행 됩니다.

... 중략 ...

이 미션의 학습 목표는 아래와 같았다.

• 어플리케이션을 컴포넌트 단위로 모듈화하여 개발
  • UI를 컴포넌트 단위로 생각하고 개발하는 연습
  • 재사용할 수 있는 컴포넌트를 고민해보기

컴포넌트를 재 사용과 모듈로써 고민하는 연습을 해야 하는 것이었다.

즉, 내가 전달해야 하는건 아래와 같은 사항들이었다.

1. 컴포넌트를 어떻게 재사용 관점에서 고민했는가?
2. 어떻게 화면 내 UI 들을 컴포넌트 단위로 나누었는가?

PR을 다시 보았을 때 이러한 사항들에 대한 나의 의사결정 과정이나 고민 과정들 없이 이 기술을 통해 컴포넌트를 만든 이유에 대해서만 설명하고 있는 것 같다고 느껴졌다.

그리고 요구사항을 충족하기 위해 어떤 사용자 경험을 고려했는지 또한 기술하지 않았다.

물론, 위 사항들에 대해 고민 없이 내가 하고 싶은 것을 한 건 아니었다.

이전에 컴포넌트를 만들기 위한 방법 들을 적용해보다 컴포넌트를 나누었을 때 유지 보수 측면에서 아쉬움을 느꼈기 때문에 그 기술을 적용했던건데 그 이유에 대해 하나도 전달하지 못했다.

이렇게 상황이 전개 되었던 이유 중 하나는 스스로 가지고 있는 기술적 욕심이 있었기 때문이라는 생각과 함께 코드를 보는 입장을 고려하지 못했다는 생각이 들었다.

1번 case에 대한 나의 반성과 다짐

지금까지의 내용을 아래와 같이 정리해 볼 수 있을거 같다.

1. 내 코드를 보는 사람 들은 크게 3가지(더 많을수도 있다.) 관점을 가지고 코드를 바라보며, 기술적인 접근이나 배경은 생각보다 크리티컬하게 보지 않을 수도 있다.
   
   
2. 현재 주어진 요구 사항들을 잘 구현했는지, 잘 전달하고 있는지 고민해볼 필요가 있다.
   
   
3. 구조적인 리팩터링은 그 이후에 고려해봐도 늦지 않다.

이 3가지 사실을 충족시키기 위해 클린 코드와 클린 아키텍처를 지향하는 최상의 결과은 조금은 후 순위로 미뤄도 될 것 같다고 느꼈다.

또한, 앞으로는 내 코드를 보는 사람들을 위해 주어진 시간 내 맞닥들인 문제와 목표를 보기 쉽게 전달 할 수 있는지에 대한 최적의 결과를 만들어내기 위한 연습을 해야겠다고 느꼈다.

이를 위해 구조적인 고민은 제한된 시간 내에서 하되, 주어진 요구 사항과 목표 들을 어떻게 해결할 수 있을지의 의사 결정 과정 들을 보기 쉽게 전달할 수 있을지에 대해 고민할 것이다.

질문을 할 때도 마찬가지다.

Bad Case(#2)

이번 미션에서 이 기술을 도입하며 장/단점을 정말 명확하게 느꼈다고 생각되는데, 구조적인 코드를 선호하는 제 입장에선 그래도 아직까지는 단점보다는 장점이 더 뚜렷하다는 생각이 들었습니다.

하지만 제 생각을 확고히 하는 것 보다는 다른 분들의 의견을 통해 좀 더 인사이트를 받아보고 싶은데 xx이 느꼈던 웹 컴포넌트의 장점과 단점은 어떤 것들이 있었는지 궁금합니다.

나의 경우 이 질문을 다시 봤을 때 기술에 대한 갈증이 느껴졌다.

사용자 경험, 학습 목표에 대한 고민을 함께 공유하기 보다는 더 좋은 코드를 만들기 위한 기술적인 고민을 공유하는 것을 원한다는 생각이 들었다.

앞서 말했지만, 지금 하고 있는 교육 과정이나 회사는 기술이 우선시 되지 않는다.

2번 case에 대한 나의 반성과 다짐

즉, 주어진 문제를 어떻게 잘 해결할 것인가?에 대해서 질문하고 답변 받아야 하는 것이 먼저인 것이다.

예로 들면 다음과 같은 사항들이 있을 것이다.

이 때까지 form에서 submit 되었을 때 주어진 값들이 유효성 검사에 통과하지 못한다면 alert 함수를 통해 error message를 보여주었습니다.

이러한 방식의 경우 디자이너와 협업할 때 사용하기엔 어렵다고 느껴졌습니다.

그래서 사용자에게 효과적으로 전달하기 위해 error text를 전달하는게 좋을지, toast를 띄우는 것이 좋을지 아니면 다른 방법이 있을지 함께 의논해보고 싶습니다.

지금의 질문을 살펴보면 2가지 사항을 만족하고 있는 것을 알 수 있다.

1. 주어진 요구 사항을 만족시키기 위한 고민들을 공유하고 있다.
2. 단순히 궁금증에 의한 질문이 아닌 그 동안의 의사 결정 과정을 공유하고 있다.

이렇게 알기 쉽게 전달하면 좀 더 원활한 소통이 가능할 것 같다고 느꼈다.

끝으로

좋은 코드 작성과 보기 쉬운 구조의 소프트웨어를 만드는 것은 개발자로써 좋은 자세인 것은 틀림 없다고 생각하며, 이것 또한 하나의 역량이라고 생각한다.

하지만 그 전에 개발자라는 포지션은 코드 리뷰라는 것을 진행하며 그 외에도 QA를 거치며 소프트웨어가 만들어진다.

이 기간 동안엔 함께 좋은 제품을 만들어가기 위해선 충분한 커뮤니케이션이 필요하다.

원활한 소통을 위해선 알기 쉽게 전달하는 것 또한 개발자로써 가져야 하는 자세라고 생각이 들었다.

앞으로는 기간 내 주어진 문제에 대한 문제 해결에 충실하기 위해 부단하게 연습할 것이다!