문제 해결과 그 과정을 해결하는 방식에 대해서
이제까지 코딩을 하는 과정에서 에러를 마주하게 되었을 때, 보통은 구글링이나 ai를 활용하여 정보를 얻고 이를 임시방편처럼 문제를 해결해왔다.
하지만 현재는 이러한 문제를 해결하는 방식이 잘못되었으며, 앞으로도 똑같은 에러가 발생하더라도 이에 대한 이해보다는 조치를 위한 검색과 해결을 할 것이라고 생각하여 조금씩이라도 이를 기록하고 있다.
하지만 이 문제와 해결하는 과정을 담는 글을 작성하는 과정이 익숙치 않아 생각보다 많은 시간을 잡아먹고 있다고 생각한다. 당장 수요일만 하더라도 빌드 과정에서 생기는 오류를 고치는 과정을 적다가 대부분의 시간이 가버렸고, 이는 곧 생산력을 떨어뜨릴 수 있다고 생각했다.
물론 이해를 기반으로 에러를 해결하는 것이 가장 이상적인 방향의 문제 해결이라고 생각하지만 이러한 과정이 전체적인 프로젝트의 일정을 맞추지 못하게 되는 문제를 낳게 될까봐 계속 걱정이 되었던 것 같다.
이렇게 공부를 하면서 하나의 오류에도 생각보다 근본적인 기술에 대한 공부를 많이 해야 하기 때문에 ‘문제해결을 위해서 어느 정도의 범위를 잡고 해야 하는가?’에 대한 생각을 계속 하게 되었고, 이를 멘토님께 여쭤보았다.
일정에는 문제 해결을 위한 시간을 고려해야 한다
멘토님의 경우 또한 문제 해결을 위해서 해당 문제의 근본적인 문제들부터 하나하나 알아가면서 해결해가는 방식은 좋은 방식이라고 말씀하셨으며, 이를 위한 시간 투자도 마땅히 필요한 것이라고 하셨다.
하지만 어떠한 문제가 언제 터질 것임을 우리는 제대로 알지 못하기 때문에, 이를 위한 시간을 미리 버퍼를 두는 것이 정석이라고 하셨다. 즉, 조금 더 보수적으로 일정을 짤 필요성이 있다는 것.
멘토님의 말씀을 듣고 그렇기 때문에 보다 빠른 생산성 또한 요구되는 것이라고 생각했다. 프론트엔드의 역량 중 중요한 요소 중 하나는 기한 내에 기능을 완성할 수 있는 역량이다. 빠른 생산성을 기반으로 개발을 하다가 만약 에러가 터진다면 이에 대한 해결 시간을 보다 확보할 수 있기 때문에 어찌보면 당연할 이야기라고 생각한다.
아무튼 그렇기 때문에 일정을 수립하는 과정에서 꼭 시간 내에 아슬아슬하게 맞출 법하게 일정을 잡지 말고, 꼭 중간에 생각치 못한 에러가 생길 것임을 고려하여 일정을 맞추는 것이 중요할 것 같다.
캔버스 라이브러리 사용에 관해서
처음에는 우리가 계획했던 프로젝트는 바닐라 자바스크립트와 Canvas API를 이용하여 저희가 직접 만든 라이브러리를 통해 마인드맵을 만드는 것을 프론트엔드의 가장 궁극적 목표로 정했었다.
가장 기초부터 우리들이 설계하여 만들게 된다면, 이를 통한 바닐라 자바스크립트와 캔버스에 대한 학습 효과가 더욱 클 것이라 생각하여 선택하였다.
하지만 백엔드 분께서 아무래도 모든 로직들에 대해서 하나하나 직접 만들고 이를 프로젝트에 적용시키기 까지는 상당한 시간이 걸릴 것 같다는 얘기를 조심스레 꺼내주셨다. 처음부터 이러한 말을 들었을 때는 ‘괜찮을 것 같은데?‘라는 생각이 들었을 수도 있지만 조금이나마 캔버스를 맛본 후에 나온 결과는 ‘안될 것 같다’였다.
따라서 우리는 라이브러리를 사용하되, 자유도가 높은 라이브러리를 활용하여 최대한 우리들이 설계 및 구현하는 기능들이 많게끔 하면서도 6주 안에 완성될 수 있는 정도의 목표를 잡고 다시금 진행하고 있다.
하지만 이러한 라이브러리를 사용하는 과정에서, 사실상 이 라이브러리는 수많은 캔버스 라이브러리 중 하나기 때문에 사실상 학습을 한다고 하더라도 해당 라이브러리에 대한 API들의 학습이 정말 저의 성장에 도움이 될까 하는 걱정도 있었던 것 같다. canvas API를 사용한다고 하면 웹에서 공통적으로 제공하는 기능이기 때문에 다른 곳에서도 많이 쓰일 것 같다고 생각하지만 라이브러리는 아무래도 한정적인 느낌이 강해해서 그런 것 같다고 생각한다.
프레임워크와 라이브러리의 차이
프레임워크
프레임워크의 경우 개발자가 소프트웨어를 개발함에 있어 코드를 구현하는 개발 시간을 줄이고, 코드의 재사용성을 증가 시키기 위해 일련의 클래스 묶음이나 뼈대, 틀을 라이브러리 형태로 제공되는 것을 말한다.
프레임워크의 특징은
- 개발자가 따라야 하는 가이드를 제공한다.
- 개발할 수 있는 범위가 정해져있다.
- 개발자를 위한 다양한 도구 , 플로그인 지원
| 장점 | - 개발 시간을 줄일 수 있음 - 정형화 되어 있어 일정수준 이상의 품질을 기대할 수 있음 - 유지 보수가 쉬움 |
|---|---|
| 단점 | - 너무 의존하면 개발자들의 능력이 떨어져서 스스로 직접 개발하는 것이 어려워짐 - 습득에 걸리는 시간이 오래 걸림 |
라이브러리
- 라이브러리란 개발자가 만든 클래스들의 나열로, 다른 프로그램들에서 사용할 수 있도록 제공하는 방식이다.
프레임워크(Framework)와 라이브러리(Library)의 차이점
: 라이브러리와 프레임워크의 차이는 제어 흐름에 대한 주도성이 누구에게 / 어디에게 있는가에 있다.
즉, 애플리케이션의 Flow(흐름)을 누가 쥐고 있느냐에 달려있다.
- 프레임워크는 그 스스로 제어 흐름의 주도성을 갖는 반면, 라이브러리는 개발자가 가지고 있다.
- 프레임워크는 집이고, 라이브러리는 그 집 안의 가구이다.
- 라이브러리와 달리 프레임워크는 이미 프로그래밍에 대한 규칙을 가지고 있다. 예를 들면 설정파일의 태그설정이나, DB연동 방법등에 대한 규칙을 가지고 있고 개발자는 이를 따라야한다.
라이브러리는 ‘도구’이다
위에서 말했듯 프레임워크는 내가 따라야 하는 것들이지만, 라이브러리는 내가 사용하는 것들 이다. 겉보기에는 비슷해 보이지만 제어 흐름의 주도성은 크게 다르다.
프레임워크의 경우 따라야 하는 것들을 따르며 여러 명이 개발을 해도 얼추 비슷한 것들이 나온다면, 라이브러리는 사용자의 역량에 따라서 결과물이 크게 달라질 수 있다는 것이다.
따라서 멘토님께서는 라이브러리를 사용하는 것 정도는 문제가 될 것이 없다고 생각하신다고 하셨다. 프레임워크가 아닌 라이브러리인 이상, 우리가 어떻게 활용하느냐에 따라서 기술적 완성도가 결정되기 때문이다. 우리는 이 라이브러리를 사용하면서 학습 효과가 떨어질까 생각하는 것이 아니라, 어떻게 활용하는지 를 생각하며 이를 문서화하고 기록한다면 보다 다른 방면에서 좋은 학습 효과를 얻을 수 있을 것이라고 말씀해주셨다.
이전까지는 프레임워크와 라이브러리의 차이에 대해서 크게 다르다는 느낌을 받지 못했지만, 멘토님의 말씀을 듣고 라이브러리를 다시 보니 확실히 차이가 크다는 느낌을 받았다. 또한 이를 어떻게 커스텀하여 사용할 지 스스로 결정하며 이 또한 나에게 좋은 학습 효과를 줄 것이라 생각한다.
전역 상태의 관리
내가 생각한 핵심 상태 관리는 세 가지 방식이 있다.
- useSearchParams → 섹션별 상태 관리
- useContext
- zustand 하지만 이 useContext와 zustand의 경우 둘 다 전역적으로 state를 내려 줄 수 있게 해주는 라이브러리다 보니, 사실상 이 두개 중에 하나를 선택하느냐, 아니면 둘 다 선택하느냐가 계속 고민이 되는 것 같다.
전역으로 관리할 상태는 현재까지는
- 캔버스에 그릴 요소들의 데이터
- 로그인 상태
- 동시 편집자 정도들의 상태가 있는데 이 상태를 무엇으로 관리해야 할 지 고민이 된다. 각각 장단이 뚜렷하다고 생각하기 때문이다.
context api의 경우는 확실히 Provider를 통해서 상태를 내려줄 범위를 직접 지정할 수 있고, 이를 통해 여러 컴포넌트에서 어떤 상태만을 관리할 지에 대해서 명확히 보이는 점이 장점이라고 생각한다. 하지만 확장성을 생각한다면 Provider hell이 만들어질 가능성이 높고, Provider가 감싸고 있는 컴포넌트들의 경우 상태 변경이 일어나면 안쪽의 모든 컴포넌트들이 리렌더링 된다는 점이 큰 단점이다.
zustand의 경우는 장점의 경우 낮은 러닝커브, selector 패턴을 이용한 선택적 리렌더링, provider hell 방지 등이 가장 큰 장점이라고 생각한다. 하지만 한 상태가 어떤 여러 컴포넌트에서 사용되는 지는 한눈에 확 알아볼 수 없다는 점이 살짝은 마음에 걸린다.
그래서 모든 요소들의 리렌더링이 필요한 데이터, 예를 들면 다크 모드와 같은 것들의 경우에는 context api로 사용하고 나머지의 경우는 모두 전역관리 라이브러리를 사용하는 방식도 괜찮을 것 같아서 계속해서 고민해보아야 할 문제인 것 같다.