우아한테크코스 레벨 2 미션 1 회고

레벨 2 시작 소감

새로운 환경에 적응하랴, 열심히 공부하랴 정신 없이 보냈던 레벨 1이 끝나고 어느새 레벨 2가 시작되었다. 우테코에 들어오기 이전에 멋쟁이사자처럼이나 초기 스타트업에서 생존형 프로그래밍만 해왔다보니 개발을 제대로 공부해보고 싶은 욕심을 늘 가지고 있었다. 레벨 1은 그런 욕심을 채울 수 있었던 시기였다. 레벨 2에서는 바닐라 JS만 사용하던 레벨 1과 달리 리액트를 사용하게 되었다. 바닐라 JS로 힘겹게 SPA를 만들 때에 비해 수월하게 미션을 해나갈 수 있겠다는 생각이 들기도 했고, 오랜만에 리액트를 사용하려 하니 살짝 걱정이 되기도 했다. 레벨 2의 목표는 그동안 익숙하게 사용했던 리액트나 상태 관리 라이브러리에 대한 이해도를 높여 '잘' 알고 '잘' 사용할 수 있게 되는 것이다. 앞으로 미션의 난이도는 어떨지, 페어는 누가 될지 등 불확실한 요소가 많다. 하지만 지금까지 해왔던 것처럼 잘 해결해 나갈 수 있을 거란 확신은 있다.

 

레벨 2 첫번째 미션 - 페이먼츠 💳 [PR 링크]

 

레벨 2의 첫 미션은 페이먼츠였다. 리액트를 이용하여 신용카드 정보를 입력하는 앱을 만드는 미션이었다. 카드번호, 유효기간, 소유자명 등의 입력값에 대해 유효성 검증을 해야 하고, 카드 앞자리 숫자에 따라 VISA, MasterCard 카드 브랜드 로고를 보여주어야 했다. 이렇듯 입력값에 대한 복잡한 요구사항을 깔끔하게 잘 처리하는 것이 관건이었다. 추가로 컴포넌트를 시각적으로 테스트하기 위해 스토리북을 작성해야 했고, 입력값을 다루는 상태 관련 로직을 별도의 커스텀 훅으로 분리해야 했다. 기능은 그리 복잡해 보이지 않을지 몰라도, 리액트를 처음 사용하는 미션치고는 제법 난이도가 있었다.

 

개발 관련 학습 내용

세부적인 구현 내용이나 코드는 PR 링크를 첨부하는 것으로 대체하고 어떤 내용을 학습했는지 간단히 정리하고자 한다.

1. 컴포넌트 단위에 대한 고민

레벨 1에서부터 이어왔던 컴포넌트 단위에 대한 고민을 할 수 있었다. 어떤 단위로 컴포넌트를 분리해야 할지 판단하는 일에는 정답이 없었다. 나의 판단 기준은 크게 가독성과 import 문의 개수, 이 두 가지였다. 컴포넌트를 분리해야 할지 고민될 때는 먼저 스스로 코드를 읽어보며 이해하는 데 어려움이 없는지를 생각해보았다. 복잡한 연산 로직이 포함되어 있거나 분기 처리가 복잡하고 조건문이 포함되어 있으면 가독성이 좋지 않았는데 그런 경우에는 컴포넌트 분리를 진행했다. 또한, import 문의 개수를 보고 컴포넌트의 복잡도를 판단하기도 했다. import 문이 많다는 것은 해당 컴포넌트가 의존하고 있는 로직이 많다는 것을 의미했고, 이는 해당 컴포넌트에 책임이 과도하게 몰려 있다는 의미이기도 했다. 이 경우에도 추가로 컴포넌트를 분리했다. 컴포넌트 분리 단위는 여전히 너무 애매모호하게 느껴지는 문제이다. 개발자마다 생각도 다르고 맥락에 따라 알맞은 분리 단위도 다르다. 우선은 너무 오래 고민하기보다는 직관과 나만의 판단 기준에 의거해 분리를 해보고 경험을 쌓으며 더 나은 기준을 세워 나가려 한다.

 

2. Storybook 작성

 

처음으로 Storybook을 작성하게 되었다. 프로덕션 코드에 더해 Storybook 코드까지 작성해야 하니 코드 작성량이 확실히 많아졌다.  Storybook 코드를 작성하거나 작성된 스토리들을 확인하는 과정이 재밌게 느껴지기는 했지만 생산성이 늘어났다고 확신이 들진 않았다. 그래서 Storybook에 어떤 유용함이 있는지 고민해보았다.

 

첫째, 작은 단위로 피드백을 받을 수 있었다. Storybook을 작성하면 최종 페이지나 커다란 컴포넌트가 완성되기 이전에 작은 컴포넌트가 기대하는 대로 동작하는지 빠르게 테스트할 수 있었다. 켄트 백이 TDD와 관련해 이야기한 '결정과 피드백 사이의 갭을 조절하는 일'에 해당한다고 생각했다. 복잡도가 높은 컴포넌트를 만들 때 코드가 쌓여갈수록 '잘 만들고 있는 건지'에 대해서 점점 불확실성이 커지기 마련인데 그러한 불확실성을 해소할 수 있게 해주었다. 사소해 보일 수 있지만 코드 작성 시 인지부하를 낮추는 데 도움이 되어 결과적으로 더 좋은 퀄리티의 코드를 작성할 수 있게 된다. 둘째, 비개발 직군 팀원 및 개발자 팀원과 협업할 때 유용하게 쓰일 수 있겠다는 생각이 들었다. 스토리는 코드 없이 시각적으로 컴포넌트를 확인할 수 있게 해주기 때문에 디자이너, 기획자 등 비개발 직군의 팀원도 쉽게 이해하고 사용해볼 수 있다. 또한 다른 개발자 팀원과 협업할 때 컴포넌트의 스펙을 시각적으로 쉽게 이해할 수 있도록 도와줄 수 있다. 마지막으로, 독립적으로 동작하는 컴포넌트를 설계하도록 이끌어주었다. 컴포넌트를 개발할 때 스타일이나 기능이 외부의 코드에 과하게 의존하게 되는 경우가 발생하기도 한다. 그런데 스토리를 작성하니 자연스럽게 독립적으로 잘 동작하는 컴포넌트를 작성하게 되었다.

 

이번 미션에서는 컴포넌트의 복잡도가 그리 높지 않고 협업할 팀원의 수가 적어서 Storybook의 장점을 온전히 누리지는 못했던 것 같다. 하지만 Storybook의 장점을 알게 되었으니 이후에 이것이 유용하게 쓰일 수 있다는 판단이 들면 적극적으로 도입하여 사용해 보고 싶다.

 

3. 커스텀 훅을 이용한 비즈니스 로직 분리

이번 미션에서 중요한 포인트 중 하나는 커스텀 훅을 적절히 사용하는 것이었다. 다양한 입력값 상태 관리 및 유효성 검증 로직을 커스텀 훅으로 분리했다. 이를 통해 UI 레이어인 컴포넌트 내부에 존재하는 비즈니스 로직을 최소화하여 컴포넌트는 데이터를 보여주는 일에만 집중할 수 있는 형태를 만들기 위해 노력했다. 관심사 분리를 이전보다 조금 더 능숙하게 할 수 있게 되었다. 레벨 1에서 객체지향을 열심히 공부했던 것이 이번 UI와 비즈니스 로직의 관심사를 분리하는 데에도 꽤 도움이 되었다고 느꼈다. 다만 아직까지 사용하기 좋은 인터페이스를 설계하는 능력이 부족하다고 느껴진다. 인터페이스 설계를 더 고민해서 직관적으로 이해할 수 있고 여러 곳에서 유용하게 재사용할 수 있는 커스텀 훅 인터페이스를 설계해보자.

 

개발 외 학습 내용

1. 생각 공유의 중요성

페어 프로그래밍을 하면서 팀원과 생각을 빠르게 공유하는 것이 원활한 협업을 위해 아주 중요하다는 것을 느꼈다. 자신이 어떤 생각과 고민을 하고 있는지 스스로는 알 수 있지만 옆에 있는 팀원은 내 속을 들여다 볼 수 없다. 그래서 별 고민을 하고 있지 않더라도 표정이 좋지 않아보이거나 말이 없어지면 눈치를 보게 될 수 있다. 이러한 점을 깨달은 후부터는 페어 프로그래밍 도중에 의식적으로 내 생각을 빠르게 공유하거나 고민할 시간이 필요하다고 즉시 이야기하려 노력했다. 이렇게 하니 서로 불필요하게 눈치를 보게 되는 일이 없었고, 고민을 늦지 않게 공유하여 문제를 빠르게 해결해나갈 수 있었다. 반대로 페어가 말이 없거나 고민이 되는 게 있어 보이면 적극적으로 물어보려 노력했다. 물어보면 페어가 자신의 생각이나 감정을 이야기해줘서 추측하거나 눈치 볼 필요가 없어 불필요한 에너지 낭비가 줄었다. 끝으로 커뮤니케이션과 관련해 노력한 부분에 대해서 페어로부터 긍정적인 피드백을 받아 노력에 대한 보상을 받는 기분이었다. 🙂

 

2. Chat GPT 잘 써먹기

Bootstrapping 어원과 관련된 일러스트레이션: https://www.wikiwand.com/en/Bootstrapping#google_vignette

 

더 이상 AI라는 흐름을 거스르기는 어려워 보인다. AI에게 대체되지 않는 사람이 되기 위해서 AI를 사용하지 않는 고집을 부리기보다는 AI를 잘 활용해서 생산성을 극대화할 수 있는 사람이 되는 편이 현명해 보인다. FE 코치 준이 Chat GPT 프롬프팅과 관련하여 종종 팁을 주셔서 큰 도움이 되었다. 사실 처음엔 프롬프팅이라는 개념조차 생소하게 느껴졌다. 프롬프팅은 쉽게 말하면 AI에게 지시, 혹은 질문하는 기술이다. 프롬프팅을 잘하기 위해서 부트스트래핑이라는 기법을 적용해볼 수 있다. 부트스트래핑의 본래 의미는 자신의 신발 뒤축 끈을 잡아 당겨 자신을 들어 올리는 행위이다. GPT에게 던질 질문을 개선하기 위해 GPT를 이용하는 방식이 부트스트래핑에 해당한다. GPT에게 받은 답변을 점수를 매겨 평가하도록 하고 그 점수를 올리기 위한 개선점을 다시 한 번 GPT에게 질문하는 식이다. 이를 통해 외부 도움 없이도 답변의 퀄리티를 점진적으로 향상시킬 수 있다.

 

한편, GPT에게 코드나 글 등의 결과물을 대신 만들어 달라고 요청하는 것은 그리 효과적이지 않은 방식이라는 것을 깨달았다. 적어도 현재 단계의 GPT를 이용할 때는 복잡한 결과물을 만들어 내는 경우 정확도가 그리 높지 않았다. 오히려 이상한 답변을 걸러내는 데 시간과 에너지가 더 많이 들었다. 부트스트래핑을 이용한다고 해도 결과물의 퀄리티를 드라마틱하게 향상시킬 수는 없었다. 결과물을 대신 만들어 달라고 하기보다는 문제 접근 방식이나 해결 과정 개선과 관련하여 도움을 받는 게 더 효과적이었다. 전문가와 유사한 방식으로 문제를 해결해 나가기 위해 나의 절차와 과정에 대한 피드백을 받는 방식으로 이용했다. 앞으로도 GPT를 유용하게 써먹되 GPT가 직접 문제를 해결해주길 기대하기보다는 '내가' 문제를 더 효과적으로 해결하기 위해 도움을 받는다는 생각으로 활용할 생각이다.