0. 들어가기전에
•
문제해결과 요구사항 구현은 개발자들의 숙명이다. 개발자 존재자체의 근간이며 존재 이유이다. 이말은 모든 개발자들이 동의할 것이다. 개발자의 근간과 존재이유인 문제해결과 요구사항 구현 시 개발자가 어떻게 접근해야할까? 에 대해 이야기 해보겠다.
•
이 글은 개발자가 사용하는 각 패키지에 대한 이해가 문제해결과 요구사항 구현에서 왜 중요한지 어떤 식으로 접근해야할지를 다루는 내용이다.
•
패키지의 이해가 문제해결과 요구사항 구현에 끼치는 영향을 다루기전에 우리가 생각하는 “해결법”에 대하여 좀더 자세하고 깊게 고찰해본다.
1. 해결법의 종류
•
해결법의 성격은 매우 다양하다.
•
필자는 해결법은 “해결법”이라는 단어 하나로 해당하는 해결법의 성격을 충분히 설명할 수 없다고 생각한다. 문제의 해결 방법에도 수많은 방법들이 존재하며 그에 따라 크게 3가지로 나눌 수 있다.
1.
성능, 유지보수성, 가독성, 확장성 등을 고려한 최적의, 이상적인 해결법
2.
이상적인 해결법을 구현할 수 없는 상황에 최대한 성능, 유지보수성, 가독성, 확장성등을 고려한 해결법
3.
Deprecated된 API 사용 또는 비효율 적인 알고리즘을 사용하여 문제의 “해결” 그 자체에만 집중한 해결법
•
필자는 위 3가지 해결법은 이상적인 해결법(Ideal Solutions), 타협(절충)된 해결법(Compromised Solutions), 이상적이지 않은 해결법( Non-ideal Solutions) 세가지로 명명했다. 해당 해결법들의 차이와 특징에 대해 설명한다.
2. 이상적인 해결법 (Ideal Solutions)
•
말 그대로 이상적인 해결법을 가르킨다. 성능, 유지보수성, 가독성, 확장성등을 고려한 최적의 이상적인 해결법으로 패키지의 경우 메인테이너가 의도한 방법대로 해결한 방법이다.
이상적인 해결법의 기준
•
이상적인 해결법의 기준은 개발자마다 편차가 심하다. 그도 당연할게 개발자, 속한 그룹 마다 “이상”이라는 코드의 기준이 매우 다르기 때문이다.
•
예를들어 설명해보겠다. 성능을 좀 감수하더라도 코드의 가독성을위해 컴포넌트를 나누지 않는 상황이 있다. 컴포넌트를 나눈다고 무조건적으로 성능이 좋아지는건 아니지만 컴포넌트를 나누고 memoizing을 해야 성능이 개선되는 경우가 있다. 이때 그 memoizing 조차 두개의 차이점이 존재한다. 처음에 느리고 그 후 리렌더링때 더빠를 것이냐? 첫 렌더링에서 느리고 그후 리렌더링때 더 빠를것이냐”
•
이 때 의견은 두개로 나뉠 수 있다. 필자는 두개의 의견 모두 “이상적인 해결법” 이라고 생각한다.
◦
“당연히 가독성보다 실제 유저들이 느끼는 성능이 더 중요하지. 첫 렌더링에 조금의 시간을 희생해도 이용자들은 첫 로드 후 해당 페이지에서 체류하는 시간이 훨씬더 기니까 그 후의 성능을 신경쓰는게 맞아!”
◦
“여기서 성능을 위해 가독성을 해쳐서 코드를 이해하기 어렵게 만드는게 더 잘못된 선택이 아닐까? 심지어 컴포넌트를 나눈다고해도 그 차이는 유저가 절대 느낄 수 없는 10ms도 안되는 차이 이잖아”
•
이와같이 이상적인 해결법의 기준은 절대적이지 않고 매우 상대적이며 주관적이다. 절대적인 정답이 없으므로 구성원들에게 “내가 맞다고 생각하는 이유”를 설득해야하며 구성원들이 “그들이 맞다고 생각 하는이유”를 설명할때도 “내가 틀릴 수 있다”라는 자세로 받아들여야한다. 모든 사람들은 각자 “중요하다”라고 생각하는 기준이 다르기 때문이다.
•
아래는 이상적인 해결법의 “주관적 성격을 띄는 특징들”의 일부분 이다. “주관적인 성격을 띄는 특징들”은 “절대적인 기준”이 아니며 “절대적일 수 없다.”
◦
가독성이 좋다.
◦
확장성이 좋다.
◦
유지보수성이 좋다.
◦
테스트하기 좋다.
◦
다른 선택지에 비해 Noticable하게 성능이 좋다.
이상적이지 않은 해결법
•
필자는 “이상적인 해결법”이 아닌 코드의 절대적인 기준은 존재한다고 생각한다. 여기서 말하는 이상적인 해결법이 아니다 를 결정짓는 절대적인 기준도 모든 케이스에서 존재하지 않고 아래 나열한 항목과 같이 특별한 케이스만 존재하기 때문이다.
◦
Deprecated한 방법을 사용한 경우
◦
이용자에게 Noticable한 성능 저하가 존재할경우
◦
하위호환성을 지키지않아 사용처에 문제가 생길 경우
•
이상적이지 않은 해결법은 말 그대로 “이상적이지 않은 해결법”과 “타협된 해결법”으로 구분 될 수 있다. 이 두항목은 2. 3.에서 다루겠다.
3. 타협된(절충된) 해결법 (Compromised Solutions)
•
마주친 이슈에대하여 이상적인 해결법이 존재하지 않는 상황에서 최대한 성능, 유지보수성, 가독성, 확장성을 고려한 문제의 해결법을 뜻한다. 말그대로 타협, 절충한 해결법이다. 패키지로 예를 들자면 해당 패키지에 마주친 이슈, 요구사항에 대해 직접적인 해결법이 없을때 채택하는 해결법이 될 수 있다.
•
꼭 이상적인 해결법이 존재하지 않아도 상황적인 이유로 인해 선택적으로 타협된 해결법을 채택 할 수도 있다.
◦
실생활 예를 들어보자. 지금 필자가 사용하는 패키지에서 이상적인 해결법을 선택하기 위해서는 업그레이드를 해야하는데, 해당 패키지를 업데이트하면 현 개발환경에서 다른 패키지들은 호환되지 않아 많은 시간이 든다. 시간이 충분하다면 물론 모든 패키지를 업데이트하고 변경된 사항들을 적용하면 좋겠지만, 그렇지 않은 경우가 대다수 이다.
•
해당 방법으로 해결한 이슈나 요구사항은 지속적으로 추적 및 관리해야하며 본인 환경에서의(사용하는 패키지나 환경의 업데이트 e.g. browser API의 업데이트) 변화가 있을 경우 타협된 해결법으로 해결된 문제들을 이상적인 해결법으로 해결할 수 있다.
4. 비이상적인 해결법(Non-ideal Solutions)
•
이상적인 해결법, 타협된 해결법 그 어디에도 속하지않는 해결법들이 이 범주에 해당된다.
•
이상적인 해결법도 존재하지 않는 상황에서 타협된 해결법에 해당되지 않고 빠른 패치 또는 “돌아가는 코드”를 집중한 해결법으로 주로 개발자의 Capacity로 인해 채택 되거나 또는 “최대한 빨리 대응”하기 위해 채택하는 방법이다.
5. 해결법 구분의 제약사항
기술적 이해도 전제
•
위의 이상적인 해결법, 타협된 해결법, 비이상적인 해결법을 구분지을때는 구분짓는 개인의 평균이상의 기술적 이해도가 전제되어야한다. 최소한 자신이 사용하는 라이브러리나 개발환경에 대한 이해도가 필요하며 그 이상 넘어가 내부 동작방식까지 파악하고 이해할 수 있어야 각 해결 법의 기준을 결정 지을 수 있기 때문이다.
•
평균 이상의 이해도가 전제되지 않는다면 위의 해결법을 나누는건 사실상 불가능하다. 아니, 오히려 피해야할 구분법이다. “우물 안의 개구리” 패러독스에 갖혀 “이 방법이 최고야!”라는 망상에 빠질 수 있기 때문이다.
◦
필자도 물론 우물안의 개구리 패러독스에 종종 갖힐때가 있다. 다만 이제는 자기 객관화가 이전보다는 더 가능하여 우물안의 개구리 패러독스에 갖혀도 이전과 비교했을때 비교적 떠 빨리 빠져나올 수 있다.
절대적인 구분은 불가능하다
•
이전 단락에서도 많이 언급했지만 다시 언급해도 절대 모자라지 않는 부분이다. 개개인의 기준은 절대적일 수 없다. 매우 주관적이며 일시적이다. 하다못해 AI도 프롬프트, AI 에이전트에 따라 전혀 다른 “기준”을 적용하여 답을 해주는데 어떻게 수많은 변수, 서로 전혀 다른 삶을 살아온 서로다른 개인들이 같은 기준을 가질 수 있겠는가? 우리는 서로를 이해하려 노력해야한다. 개발자들이 서로를 이해해주지않으면 대체 누가 개발자들을 이해해줄 수 있겠는가.
•
위 이유의 연장선으로 “개인마다 다른 기준”으로 인해 필연적으로 아래와 같은 Gray zone들이 생겨난다. 표현상 한계로 인해 작게 표현했지만 각자의 기준에 따라 이 Gray zone은 더 커질 수 있으므로 서로간 기준의 간극을 메꾸는 노력도 많이 필요하다.
이상적인 해결법은 이상적이다
•
본인을 포함한 많은 개발자들이 범하는 실수 중 하나가 이상적인 해결법으로 문제해결하기 위하여 많은 노력을 한다는것이다. 이전 블로그 포스트에도 몇번 언급했지만 우리는 고용주에게 결과물을 제공할 의무가 있는, 돈받고 일하는 개발자이다. 모든 문제를 이상적인 해결법으로 해결하면 좋겠지만 모든 업무에는 Due Date가 존재하며 내가(대부분의 기능개발 업무에 마지막을 담당하므로 특히 Front-end 개발자에겐 더욱더 중요하다.) 늦어질경우 배포까지 늦어지므로 이 사실을 꼭 기억해야한다.
•
물론 필자는 “적당히 하자”를 말하는게 아니다. 필자 본인의 좌우명 중 하나가 “완벽이란 도달할 수 없는 이상임을 자각하며 그 완벽을 추구하자”이다. 이 뜻을 설명하기위해 좋은 단어가있는데 바로 “유토피아(Utopia)”이다. 고대 그리스어에서 유래한 이 단어는 모두가 알고있는 단어이며 많은사람이 그 뜻을 알고 있겠지만 고대그리스어로는 “존재하지 않는 곳”이다. 맞다. 이상향은 존재하지 않는곳이다. 그러나 “존재하지 않는다”라는 명확한 이해와 함께 이상향을 쫓는다면 적절한 타협과 그 타협에 따른 최선의 선택을 할 수 있다고 생각한다. 우리 모두 이런 자세를 가진다면 각박한 개발팀에 한줄기의 빛이 될 수 있지 않을까?
•
문제해결 시 이상적인 해결법을 쫓는게 아니라 “이상적인 해결법을 추구하며 비 이상적인 해결법을 최대한 피하는걸” 목표로 개발을 하는게 우리 개발자가 현실적으로 이룰 수 있는 이상향이라고 생각한다.
•
Web Frontend에 예를 들자면 사실상 이상적인 해결법의 한계를 잘 알아야한다. 하위호환성을 위해 존재하는 수많은 Paradox, OS/브라우저/브라우저 버전/ 기기 성능, 과 같이 심각하게 나뉘어진 환경 과 같은 환경적인 한계가 존재 하므로 애초에 달성하기 쉽지 않은 목표이기 때문이다.
6. 혼자서 되묻기
모두 이상적인 해결법인 상황
•
React 사용 개발자의 예시로 들자면 DOM 변경 시 useState/useRef 사용과 같은 상황을 “모두 이상적인 해결법인 상황”이라고 부를 수 있다. 말그대로 “모두(둘다) 해결법인 상황”이기 때문이다.
◦
당연히 React, Frontend Ecosystem에 이해도가 높은 독자들이라면 둘 중 선택하기가 아주 쉽고 어디서 뭘 써야할지 잘알겠지만 useState/useRef는 예시이므로 본인이 “뭐가 옳은 선택인지” 몰랐던 과거의 자신이라고 생각하고 글을 마저 읽으면 이해하기가 쉽다. 쉽게 말하자면 “뭐가 옳은지 모른다”라고 가정하고 글을 읽어주길 부탁한다. 그게 정 힘들다면 요즘 본인이 겪고 있는 “모두 해결법인 상황”을 대입하여 글을 읽어도 좋다.
이상적인 해결법
•
개인적으로 “모두 해결법인 상황”은 항상 필자를 지치게한다. 항상 올바른 선택을 하고싶다는 강박이라 할까? GPT한테 물어보면 되잖아! 라고 할 수 있지만 글을 작성하는 현재 기준 LLM들은 아래와 같은 이유때문에 “이상적인 해결법”을 제대로 답할 수 없다.
◦
프롬프트에 따라 전혀다른 대답
◦
모든 컨텍스트를 파악할 수 없는 능력
•
1. 사용중인 (사용 예정인) 패키지 이해의 필요성의 예시로 들었던 DOM 변경 시 useState/useRef 사용 과 같이 “애매한” 부분에 대한 의사결정을 위해서는 명확한 이해가 선행되어야한다.
•
본인은 명확한 이해를위해서 “혼자서 되묻기”라는 방법을 사용한다. “비판적으로 질문하는 나”와 “대답하는 나” 둘이서 롤플레이를 하는것이다. (지금 이 글을 쓰는 본인조차 제정신이 아닌거 같다 라는 생각이 조금씩 들긴한다. Please bare with me)