Article : 개발자가 문제 해결 과정에서 겪는 어려움 3가지

https://yozm.wishket.com/magazine/detail/2670/

개발자가 문제 해결 과정에서 겪는 어려움 3가지 | 요즘IT

 

 

<아티클 내용 요약>

문제 해결 과정에서 겪는 어려움에 대해 이야기하고자 한다. 왜냐하면 외부적인 요인은 개발자 개인의 노력과 능력만으로는 통제할 수 없는 상황이 많지만 문제 해결 과정에서 겪는 어려움은 분석한다면 내가 어떤 이유로 인해 혼란스러움을 겪고 있는 상태인지 알 수 있고, 그에 맞는 적절한 해결 방법을 선택할 수 있다. 

 

문제 해결 과정에서 어려움의 유형과 판단 기준은 크게 세 가지다. 

1. 문제 그 자체의 복잡성이 높은 경우
2. 문제 해결에 필요한 적절한 배경지식이 갖추어지지 않은 경우
3. 문제를 해결할 수 있는 방법이 여러 가지인 경우 

 

 

문제 그 자체의 복잡성이 높은 경우

우리는 문제의 요구조건을 살펴볼 대, 복잡하다고 느끼는 경우가 종종 있다. 

문제 그 자체의 복잡성이 높다는 것은 곧 문제를 해결하기 위해서는 높은 수준의 추상화가 필요하다는 것을 의미한다. 

우리는 소프트웨어 개발에서 추상화라는 개념을 통해, 구현의 세부 사항은 숨기되 기능 제공에 초점을 맞추며 이를 통해 코드의 이해와 재사용성을 높이고 유지보수를 용이하게 할 수 있다. 실세계의 복잡한 상황을 간결하고 명확하게 핵심 위주로 단순화시킴으로써 문제를 해결할 수 있는 것이다. 

 

추상화 덕분에 저수준의 코드를 이해하거나 작성하지 않고도 제공되는 기능을 사용할 수 있지만 추상화를 적용한다고 해도 무조건 문제를 간단하게 만들 수 있는 것은 아니다.   

또한, 추상화를 통해 복잡도를 줄이고 단순화를 할 수 있지만 한계점 이하로는 추상화를 진행할 수 없고 오히려 한계점을 넘어서면 추상화는 문제를 해결하는 데 방해가 될 수 있다. 

 

추상화를 통하더라도 분제의 복잡성을 해결하는 것에는 한계가 있다는 것이다. 이를 두고 복잡함 보존의 법칙이라고 한다.

 

 

문제 그 자체의 복잡성이 높은 경우 해결 방법

문제의 본질을 호도하는 혼란스러움을 문제로부터 분리하면 된다. 

해결하고자 하는 문제를 올바르게 이해하고, 문제 해결에 영향을 주지 않는 선에서 불필요한 정보를 제거하며 문제를 단순화하는 것이다. 

 

혼란스러움을 분리하게 되었다면 문제를 작은 단위로 나눈다. 

나눈 문제를 가장 복잡도가 적은 문제부터 해결해 나가며, 작은 문제의 해결 방법을 찾았다면 추상화한 인터페이스로 제공한다. 이렇게 작은 문제들을 합쳐가며 전체 문제를 조금씩 해결하는 것이다. 

 

추상화는 곧 현실에서 우리가 겪는 문제를 해결하기 위한 도구다. 따라서 문제를 해결하기 위해서는 문제 상황을 올바르게 모델링하는 것이 중요한데, 이때 자료구조와 알고리즘, 그리고 디자인 패턴에 대한 지식이 갖추어져 있다면 문제를 빠르고 효율적으로 해결할 수 있다.   

 

 

문제 해결에 필요한 적절한 배경지식이 갖추어지지 않은 경우

이는 도메인 지식이 부족한 상태라고 할 수 있다. 여기서 도메인은 문제가 풀고자 하는 비즈니스의 영역일 수도 있고, 언어나 프레임 워크, 라이브러리 등의 기술적인 영역일 수도 있다. 

 

비즈니스 도메인이 문제인 경우는 배경 지식이 문제 해결에 영향을 특히 많이 주는 분야에서 그럴 수 있다.

우리가 일상생활에서 접하기 힘든 낯선 용어와 개념을 자주 사용하기 때문에, 개발자가 어려움을 겪을 수 있다. 

 

기술 도메인이 문제인 경우는 유사 경험이 있는지 없는지에 따라서도 서로 다른 어려움을 겪을 수 있다. 

유사 경험이 없는 경우라면 '이게 대체 무슨 용어야?'와 같은 생소함을, 유사 경험이 있는 경우라면 'A에서는 이런 방법으로 해결했었는데 B에서는 그걸 어떻게 할 수 있지?'와 같은 혼란스러움을 겪을 수 있다.    

 

 

문제 해결에 필요한 적절한 배경지식이 갖추어지지 않은 경우 해결 방법 

가장 좋은 방법은 도메인 지식에 대한 학습과 교육을 진행하는 것이다. 

기술 도메인에 대한 지식은 개발자 스스로 학습할 수 있는 범위가 넓으므로, 여유가 된다면 시간을 내서 학습하는 것이 중요하다. 만약 주변에 도움을 줄 수 있는 선배 개발자나 동료가 있다면 그들에게 도움을 요청할 수도 있고, 없다 해도 오픈소스 커뮤니티에서 도움을 받을 수도 있다. 

 

유사 경험이 없는 경우라면 차라리 책이나 강의, 문서처럼 잘 정리된 커리큘럼을 먼저 다라가 보는 것도 추천한다. 방향을 정하지 않고 무작정 뛰어드는 학습과 질문은 비효율적일 수 있기 때문이다. 

유사 경험이 있는 경우에는 기존 배경지식을 활용해 프로젝트 경험을 빠르게 가져가는 것을 추천한다. 이때 각 기술의 특징과 장단점을 비교해 가며 학습한다면 내가 가지고 있는 지식을 더욱 확장할 수 있다. 

 

유사 경험은 많으면 많을수록 새로운 기술이나 도메인에 대한 학습을 빠르게 만들어주는 촉진제 역할을 할 수 있기 때문에, 새로운 기술이나 도메인에 대한 학습을 빠르게 진행하고 싶다면 다양한 프로젝트에 참여하거나 다양한 기술을 사용하는 것을 추천한다. 

 

 

문제를 해결할 수 있는 방법이 여러 가지인 경우 

어떤 방법이 최선인지 판단하기 어려운 상황에서 반드시 선택을 내려야 하는 경우다. 

위의 두 문제가 문제 해결 방법을 찾는 과정에서의 어려움이라면 이번에는 발견한 해결 방법에서 선택하는 것에 대한 어려움이라는 점에서 성격이 다르다. 

 

가장 대표적으로 기술 스택 선택이 있다. 

새로운 프로젝트를 시작할 때 어떤 기술 스택을 선택해야 하는지 판단이 어려울 수 있다. 다양한 언어, 프레임워크, 라이브러리들이 존재하며 각각의 장단점이 있기 때문이다. 

 

다른 예시로는 코드 컨벤션이 있다. 

코드 컨벤션은 코드의 가독성과 유지보수성을 높이기 위한 목적으로 조직 내에서 통일한 규칙이다. 하지만 어떤 코드 컨벤션을 선택해야 하는지를 판단하기는 쉽지 않다. 개인이 선호하는 코드 스타일이나 팀의 코드 스타일 도는 프로젝트의 특성에 따라 달라질 수 있기 때문이다. 

 

 

문제를 해결할 수 있는 방법이 여러 가지인 경우 해결 방법

해결 방법이라고 제시하는 것도 애매하지만 결국 선택을 해야 하는 상황에서는 비교의 기준 간 우선순위를 정하는 것이 중요하다. 기준 중에서 중요도순으로 정렬해 보고, 그중 가장 우선이 되는 기준을 세우는 것이다. 

 

일반적인 방법은 외부 레퍼런스를 참고하여 토론하는 것이다. 혹은 팀 또는 주변에 시니어 개발자가 있다면 그들의 경험을 선택 기준으로 활용할 수도 있다. 

 

또는, 각 선택지에 해당하는 방법을 직접 프로토타이핑해 보고 결과를 비교해 보는 것도 좋은 방법이다. 시간과 노력은 조금 더 걸리겠지만 미처 개발 전까지는 몰랐던 장단점을 확실하게 파악할 수 있다.

 

 

마치며

개발자가 문제 해결 과정에서 겪는 어려움은 독립적으로 존재하는 것이 아니라 함께 존재할 수 있기 때문에, 여러 어려움이 중첩되는 상황을 만난다면 개인이 경험하는 불안감은 더욱 커질 것이다. 이러한 경우에는 어려움의 유형을 하나씩 줄여나가는 것을 목표로 프로젝트를 진행할 수도 있다.  

 

 

 

 

<알게 된 개념>

새로운 용어들과 어떤 어려움이 있을 수 있는지 또한 그에 걸맞은 해결 방법에 대해 알 수 있었다.

그리고 현재 내가 느낄 수 있는 어려움에 맞닿아 있다고 느꼈다. 

 

새로 프로젝트를 해야 한다고 생각을 할 때마다 드는 막막함과 고민들에 대해 짚어주고 어떤 방식으로 해결하면 해결할 수 있다는 방향성을 주는 내용들이라 크게 도움이 됐다. 

 

아티클의 내용을 교훈 삼아 계속 공부하면서 정진해야겠다.