7 분 소요

왜요왜요왜

프롤로그 🎬

혹시 개발자로 일하면서 얼마나 자주 “왜?”라고 물어보며 개발을 하고 있는지 생각 해본적이 있나요? 최근에 개발을 하면서 ‘왜?’라는 질문을 잊고 사는 내 자신을 발견했다. 손이 먼저 올라가는 코딩을 하고 있고, ‘깊이 있는 사고가 빠진 개발을 하고 있지는 않은가?’ 라는 생각이 들기 시작했다. 더 나아가서, 우리의 일상에서도 생각할 기회를 점점 잃어가고 있는 것은 아닌지 고민이 된다.
특히 짧고 빠른 결과를 요구하는 현대 사회에서는 깊은 고민 없이 처리할 수 있는 일이 많아졌고, 내가 몸 담고 있는 개발이라는 작업조차 그 영향을 받고 있는 듯하다.

개발자에게 ‘왜?’는 왜 중요할까? 🧐

개발자에게는 특히 왜?가 중요한 질문이라고 생각한다. “왜?”라는 질문은 단순한 의문을 넘어서, 개발자가 더 깊이 있는 사고를 통해 문제를 해결하고 더 나은 결정을 내리도록 도와준다. 이 질문이 필수라고 말 할 수는 없을 것 같다. 하지만, 앞으로 더 깊이있는 개발자가 되기 위해서는 필수적으로 가져가야할 소양이 아닐까 라는 생각이 든다.
그래서 초보 개발자일수록 “왜?”라는 질문에 더욱 익숙해야 한다. 이때는 자신이 무엇을 모르는지도 모르기 때문에, 질문이 많아질 수밖에 없다. “왜 이 코드를 이렇게 작성해야 하지?”, “왜 이 라이브러리를 써야 할까?”, “왜 이 기능이 중요한가?”와 같은 질문들은 모두 개발 여정?에서 필연적으로 맞닥뜨리는 부분일 것이다. 이 질문들을 잘 수집하고 하나하나 확실하게 짚고 넘어간다면, 개발자로서의 성장에 큰 도움이 될 것이라고 나는 확신한다! 이는 단지 지식의 축적을 넘어서, 개발자로서의 자신감도 채워나갈 수 있지 않을까?
요즘 느끼는 것은 연차가 낮을 때 더 많이 “왜?”라고 묻고 그 답을 찾아갔더라면, 지금의 내가 조금 더 나은 개발자가 되어 있지 않을까 라는 약간의 후회가 들때도 있다.
당시에는 스스로에게 왜라고 묻지 않고 흐린눈으로 넘어갔던 문제들이 시간이 지나며 나를 괴롭힐 때도 있기 때문이다.
지금부터 라도 이 질문을 습관화해야겠다는 결심을 했다. 또한,’왜?’는 단순한 호기심이 아니라, 논리적인 사고의 출발점이기도 하다.

대부분 우리는 동료들과 함께 협업하여 하나의 프로덕트를 만들어 나간다. 혼자 개발할때는 크게 느낄수 없지만, 협업 환경에서는 단순히 기능을 구현하는 것을 넘어, 그 과정에서 의사결정의 이유와 배경을 명확히 설명할 수 있어야 할때가 있다. 그때 평소에 왜?라고 묻는 습관을 꾸준히 해왔다면, 빛을 바랄수 있다. 협업하는 상황에서 종종 이런 경우를 맞닥 드릴때가 있었을 것이다.

  • 이 코드가 왜 이렇게 동작하지?
  • (동료 개발자가) 이 코드를 이렇게 작성한 이유가 뭔가요?
  • 내가 왜 이 라이브러리를 제일 낫다고 판단했을까?
  • 내가 작성한 코드가 왜 다른 팀원이 작성한 코드보다 더 나을까? (반대 경우 포함)

위의 예시 뿐만아니라 많은 사례에서 “왜?”라는 질문이 등장한다. 이런 질문에 명확하게 답하지 못하고 넘어간 경험이 있다면, 그것은 곧 나의 개발 방식에 어느 정도 허점이 있음을 의미할 수 있다. 그리고 나에게도 답을 못했다는 것은 동료들에게도 공감을 못시켰을 확률이 높을 것이다. 그래서, 이런 질문에 대해 확실하게 짚고 넘어가면, 추상적인 지식이 구체화되고, 그것을 팀 동료들에게 설명을 하고 공감을 얻어낼 수 있다.

“왜?”의 과정이 없다면 무슨 일이 벌어질까 상상해봤다 🙃

점점 왜?라는 생각없이 개발을 해나간다면, 어떤 안좋은?일이 벌어질까 혼자서 상상을 해봤다.

  1. 테스트나 인터뷰를 제대로 치를 수 없다.
    최근에 토X 테스트를 치렀는데, 평소에 “왜?”라는 질문을 충분히 하지 않아서 결과가 좋지 않았다.(어느정도 원인이 되었다고 판단했다.) 문제의 의도를 정확히 이해하지 않고 해결법만 찾으려고 했기 때문에, 답을 유추하는 과정에서 결국 확신에 찬 판단을 하지 못했다. 테스트나 코드 구현할때 “왜 이렇게 해야 하는가?”라는 질문을 스스로 던지지 않으면 문제의 본질을 놓치기 쉽다. 결국 깊이 없는 이해로는 문제 해결 능력을 키울 수 없고, 테스트에서 좋은 성과를 내지 못한다.

  2. 나중에 후배 개발자에게 판단의 근거를 논리적으로 설명할 수 없다.
    아직은 나보다 후배 개발자와 함께 일해본적은 없지만, 앞으로 내가 연차가 쌓여가며 결국은 같이 일 할 상황이 올것이고, 나의 경험과 기준을 바탕으로 방향성을 어느정도 제시해줘야할 경우가 있을 것이다. “왜 이 방식을 선택했는가?”, “왜 이 코드를 이렇게 작성했는가?”에 대한 이야기를 제대로 할 수 없다면, 분명 후배 개발자에게 신뢰를 얻지 못할 뿐더러 같이 일을 해나가며 매끄럽지 못한 상황에 자주 직면 할수도 있겠다 라는 생각을 했다.

  3. 결정의 근거가 약해진다.
    “왜 이 기술을 선택했는가?”, “왜 이 디자인 패턴을 적용했는가?”와 같은 질문이 없다면, 프로젝트의 기술적 선택에 대한 명확한 근거를 제시할 수 없다. 결과적으로, 프로젝트의 방향이 혼란스러워지고 비효율적인 선택을 하게 될 위험이 커진다. 또한, 동료들과의 논의에서 논리적인 설명 없이 단순히 ‘이렇게 해왔으니까’라고 답하는 것은 신뢰를 떨어뜨릴 수 있다.

  4. 팀내 의사소통이 어려워진다.
    3번과 같은 맥락이겠지만, 팀원들 간의 의사소통에서 “왜?”라는 질문에 대한 답변이 불충분하다면, 프로젝트는 정상적으로 진행되는 것 처럼보이나 발견못한 허점들이 발생할 확률이 높아진다. 또 의사소통이 원활하게 이루어지지 않으면, 코드 리뷰 과정에서 불필요한 논쟁이 생길 수도 있다. “왜 이렇게 했는지” 명확하게 설명할 수 있는 능력은 팀 내 협업에서 매우 중요한 요소다.

결국, “왜?”라는 질문을 생략하게 되면, 개발 과정에서 발생하는 여러 문제를 명확하게 해결하지 못하고 넘어가게 된다. 이는 곧 팀 내 개발자의 성장을 늦출수 있을 뿐만 아니라, 프로젝트의 완성도도 낮출수 있지 않을까?

왜?라고 묻지 않아 생겼던 나의 경험 🥲

회사에서 동료 개발자 분과 의견 대립이 있었던 적이 있었고, 상황은 다음과 같았다.

리액트에서 컴포넌트를 반복문으로 컴포넌트를 렌더링하는 코드가 있었고, 그 컴포넌트 내부에서 커스텀 훅을 호출하여 사용하고 있었다. 커스텀 훅에서 반환되는 특정 값 하나만을 사용하고 있는 구조였다.
나는 오히려 커스텀훅 호출을 한단계 상위 레벨에서 호출을 하여, 반복문 돌려지는 컴포넌트에 props로 넘기는게 더 나을것 같다는 판단으로 코드를 수정했다.

팀원 👩🏼‍💻 : “이 컴포넌트 내부에서 커스텀 훅을 호출해 값을 사용하고 있었는데, 왜 상위 레벨에서 props로 내려주는 방식으로 변경하셨나요?”

👨🏻‍💻 : “커스텀 훅도 결국 함수니까, 반복문을 돌 때마다 매번 함수를 호출하는 게 성능에 영향을 미칠 것 같았습니다. 그래서 상위 레벨에서 한 번만 호출하고, 필요한 값만 props로 내려주는 게 더 효율적일 거라고 생각했어요.”

팀원 👩🏼‍💻 : “성능 때문이라고 하셨는데, 그렇게 큰 차이가 있을까요? 저는 오히려 가독성 때문에, 사용하는 컴포넌트 내에서 훅을 호출하는 게 더 직관적이라고 생각했거든요.”

👨🏻‍💻 : “음… 그래도 커스텀 훅을 n번 호출하면, n번 함수 컨텍스트가 생성되고 그만큼 쓰레드를 점유하게 되는 거잖아요? 만약 함수가 복잡하거나 무겁다면 성능에 영향을 줄 수 있지 않나요?”

팀원 👩🏼‍💻 : “그럼, 두 방식의 성능 차이를 실제로 비교할 수 있는 데이터가 있나요?”

👨🏻‍💻 : “음….”

결국 해당 기능은 내가 작성한 방식대로, 즉 상위에서 한 번 호출한 후 props로 값을 내려주는 방식으로 반영되었다. 하지만 마음 한구석이 찜찜했다. 왜냐하면 팀원분을 논리적으로 설득하지 못한 것도 있었지만, 내가 제시한 ‘성능 문제’라는 이유가 실제로 얼마나 큰 차이를 만드는지 제대로 검증하지 못했기 때문이다.

내가 “왜?”라는 질문을 더 깊이 던지고, 그에 대한 답을 명확하게 찾아봤다면 어땠을까? 예를 들어, 두 방식을 성능적으로 비교해보고 실제 차이를 확인한 후 데이터를 근거로 설명했다면, 더 설득력 있는 결정을 내릴 수 있었을 것이다. 당시 나는 단순히 추측에 근거해 결정을 내렸고, 그로 인해 논리적으로 팀원과 합의하지 못한 상황이 발생했다.

이 경험은 “왜 성능이 더 나을까?”, “왜 가독성보다 성능을 우선해야 할까?”와 같은 질문을 충분히 하지않았기도 했고, 거기서 더 이어나가지 않고 끝냈다는 것이다. 지금 생각해보면, 성능 비교단계 까지 테스트하여 같이 이야기를 나눠봤다면, 나와 동료분 모두 성장할 수 있는 기회이지 않았을까?

왜?라고 묻는 습관 기르기 🙌🏻

업무 중에 항상 “왜?”라는 질문을 던지며 제품을 만들어 나가는 것은 처음에는 생산성이 떨어질 수 있다. 빠르게 해결해야 하는 업무 속에서 모든 것에 의문을 던지기보다는, 일단 해결하는 데 집중하는 것이 현실적일 때도 많다.
하지만 “왜?”라는 질문을 꾸준히 던지고, 그에 대한 답을 찾아가는 연습을 한다면, 시간이 지날수록 더 명확한 기준과 효율적인 사고 방식을 갖추게 될 것이다. 이러한 질문은 결국 생산성을 높이고, 더 나은 제품을 만드는 데 기여할 수 있을 것 이다. 습관을 기르기 위해 다음과 같은 방법들을 고민 해봤다.

  1. 노션이나 정리 도구에 “왜?” 질문 기록하기
    일을 하다가 “왜 이 방식이 더 좋은가?”, “왜 이 기술을 써야 하는가?”와 같은 질문이 떠오를 때, 바로 답을 찾기 어렵다면 노션같은 툴에 데이터베이스를 하나 만들어서 저장해 놓는다. 추가로 그때 당시의 생각을 짧게 메모해두면, 다시 돌아왔을때 그 사고 부터 이어 나갈수있다!

  2. 따로 탐구하는 시간을 가져보기
    남는 시간에 새로운 것을 공부하기 보다는 기존에 적어두었던 해결하지 못하고 넘어간 기록들을 다시 보며 생각해 보는 것이다! 이 작업은 새로운 지식을 탐구하는 것보다 오히려 더 선행되어야 한다고 생각한다.

  3. 동료나 멘토와 함께 질문에 대한 토론해보기
    혼자서 도저히 찾지 못하는 문제들이 생길 수도 있다. 그때는 동료들은 어떻게 생각하는지 왜?인지 한번 물어보는 것도 좋다. 서로의 의견을 듣고 논의하면서, 내가 미처 생각하지 못했던 포인트를 배울 수 있다.

  4. 작은 질문부터 시작하기
    처음부터 복잡한 질문이 아니더라도, 일상적인 개발 과정에서의 작은 의문들을 자주 던져보는것도 습관을 기르기 위한 좋은 방법이다. “왜 이 변수명을 이렇게 정했을까?”, “왜 이 방식으로 배열을 순회했을까?”와 같은 작은 질문부터 시작해, 조금씩 질문의 깊이를 더해가는 연습을 할 수 있다. 작은 질문들이 쌓이면, 복잡한 문제를 더 쉽게 해결할 수 있는 기초가 된다.

  5. 코드 리뷰에서 “왜?”를 질문하는 습관 들이기
    코드 리뷰는 “왜?”라고 묻기 좋은 기회이다. 다른 개발자의 코드를 보며 “왜 이 부분을 이렇게 처리했을까?”를 “나라면 어떻게 작성했을까?” 스스로 질문하거나, 해당 개발자에게 물어보는 과정을 통해 나와 동료개발자 모두 왜?를 생각해볼수 있고, 이는 같이 성장하는 좋은 방법중 하나가 된다.

더 나아가서 🏃🏼‍♂️‍➡️

왜?라고 묻는 습관이 지속되면, 얻게 되는 좋은점들 중 내가 요즘 배양하고 싶은 능력이 있는데, 바로 “자신만의 개발 철학이 생긴다” 는 것이다.

나는 이전까지 따로 나만의 개발 철학이 없었던 것 같다. 솔직히 판단을 내림에 있어서, 큰 고민없이 결정을 내린 경우도 있었고, 상대방의 의견을 무조건 적으로 수용한 적도 있었다. 그러기에 나의 개발에 자신감이 없기도 했다.
하지만, 위의 연습을 하다보면, 분명 자신의 기준과 철학을 가지게 될 것이고 이는 자신감을 향상 시킬 것이다. 왜 특정 방식을 선택했는지에 대한 이유를 명확하게 알고 있기 때문에, 코드 리뷰나 기술적인 논의에서 더 확신을 가지고 설명할 수 있다.
이는 단순한 기술적인 실력이 아닌 논리적 사고를 성장시킬수 있는 방향이기도 하다.

정리 📚

“왜?”라고 물어보는 것은 개발자의 영역을 넘어, 인간의 사고와 성장에 깊은 영향을 미치는 질문이다. 개발자로서 “왜?”라는 질문을 습관화하면 우리는 문제의 본질을 이해하고, 논리적인 기준을 세우며, 더 나은 의사결정을 내릴 수 있다. 이 질문을 통해 자신만의 개발 철학을 확립하고, 성능 최적화나 협업 과정에서도 더 높은 성과를 기대할 수 있다.

지속적으로 “왜?”라는 질문을 던짐으로써 나만의 기준이 생기고, 그 기준은 시간이 지나면서 더 유연하고 논리적인 방식으로 발전한다. 이는 코드 품질 향상, 성능 최적화, 그리고 팀원들과의 협업에서 중요한 역할을 하게 될 것이다. “왜?”를 묻는 과정은 처음에는 다소 시간이 걸리고 복잡하게 느껴질 수 있지만, 결국엔 더 명확하고 자신감 있는 개발자로 성장하는 데 큰 도움이 될 것이라고 나는 확신한다!

결국, “왜?”라는 질문은 단순한 호기심을 넘어서 우리의 사고를 깊게 하고, 개발자의 성장을 점점 가속화 시킬수 있다. 이를 통해 우리는 더 나은 문제 해결 능력과 논리적 사고를 갖춘 개발자로 거듭날 수 있다. 앞으로 우리가 마주하는 모든? 상황에서 “왜?”라고 물어보는 습관을 들이길 바라며, 이를 통해 개발뿐만 아니라 우리의 삶에서도 더 많은 것을 깨닫았으면 좋겠다.

댓글남기기