1. 레벨 1 미션 목록 📄

레벨 1에서는 바닐라 자바스크립트로 웹 UI를 구현하였다. 처음부터 뭔가 거창하게 배우겠다는 마음보다는, 하나하나 만들어가면서 내 코드를 좀 더 읽기 좋게, 다루기 쉽게 만드는 데 집중했던 것 같다. 그러다 보니 자연스럽게 ‘이건 왜 이렇게 짰지?’, ‘이 부분은 굳이 객체로 만들어야 했나?’ 같은 고민을 하게 되고, 그러면서 내가 작성한 코드에 대해 책임을 져가게 되었다.

이전엔 그냥 작동하면 됐지 싶었는데, 지금은 작동하는 것보다 “어떻게 작동하게 했는지”가 더 신경 쓰이기 시작했다. 물론 아직도 모르는 것도 많고, 헷갈릴 때도 많지만, 그래도 전보다는 확실히 단단해졌다는 느낌이 든다.

오늘은 레벨 1을 마치며 느끼고 배운 하드 스킬과 소프트 스킬에 대해 짧게 회고해보고자한다.

1.1. PR 링크 🔗

1주차: 자동차 경주

• 1단계: https://github.com/woowacourse/javascript-racingcar/pull/338

2-3주차: 로또

• 1단계: https://github.com/woowacourse/javascript-lotto/pull/352
• 2단계: https://dev-dino22.github.io/javascript-lotto/

4-5주차: 점심 뭐 먹지

• 1단계: https://github.com/woowacourse/javascript-lunch/pull/206 > https://github.com/woowacourse/javascript-lunch/pull/225 (리뷰어의 merge 실수로 인해 2개로 나뉘어진 PR)
• 2단계: https://github.com/woowacourse/javascript-lunch/pull/255

6-7주차: 영화 리뷰

• 1단계: https://github.com/woowacourse/javascript-movie-review/pull/197
• 2단계: https://github.com/woowacourse/javascript-movie-review/pull/246

1.2. 배포한 미션 웹 링크 🔗

로또

• https://dev-dino22.github.io/javascript-lotto/

점심 뭐 먹지

• https://dev-dino22.github.io/javascript-lunch/

영화 리뷰

• https://dev-dino22.github.io/javascript-movie-review/

---

2. 기술 회고 ✏️

자동차 경주, 로또 미션에서는 객체와 class, 도메인과 UI의 관심사 분리 등에 대해 깊게 고민해볼 수 있었다. 그리고 점심 뭐 먹지, 영화 리뷰 미션에서는 컴포넌트와 함수, API 요청 및 비동기와 이벤트 루프에 대해 공부해볼 수 있었다.

매주 미션을 진행하며 리뷰어에게 리뷰를 받고 크루들과 소통하며 너무 많은 것들을 배웠기에 이 회고에 학습한 모든 것을 정리할 순 없겠지만,

기억에 남는 핵심적인 학습을 키워드 중심으로 짧게 돌아보고자 한다.

2.1. 객체와 class

2.1.1. class의 오남용

프리코스 때부터 별 고민 없이 관습적으로 써왔던 class의 사용에 대해 다시 돌아보게 되었다.

객체 !== class 이며, class !== 객체지향 프로그래밍 이다. 자바스크립트는 프로토타입 기반의 언어이다. 자바스크립트에 class가 등장하게 된 배경은 자바와 같은 객체지향 언어를 하다가 온 개발자가 익숙한 문법으로 작성할 수 있게 하기위해서였다. 일종의 syntax sugar 인 셈인데, 자바스크립트의 class는 기존 프로토타입 기반 상속 매커니즘을 추상화한 문법이기 때문에 자바의 class와 상당히 다르다고 한다.

(관련 링크: https://developer.mozilla.org/ko/docs/Web/JavaScript/Guide/Inheritance_and_the_prototype_chain)

이처럼 자바스크립트는 본래 프로토타입 기반의 언어이고 class 문법 또한 이를 추상화한 것에 지나지 않기 때문에, class를 사용하지 않고도 충분히 객체지향 프로그래밍이 가능하다.
무분별한 class 사용은 의미없이 가독성 떨어지고 비효율적인 코드를 만들 수 있다.

이러한 개념에 대해서 리뷰어와 소통하고 개인적으로 학습하면서, 기존의 내 코드는 별 고민없이 프리코스 때 남들이 그렇게 썼으니까, class를 남발하며 작성하였음을 알게되었다. 그리고 앞으로 개발할 때 어떤 상황에서 class를 써야하는지에 대해 나만의 기준을 세우게 되었다.

• 복잡한 상태를 가지는지?
• 인스턴스 만들어 여기저기 재사용을 해야하는지?
• 상속/조합 이 필요한 상황인지?

2.1.2. class의 상속과 조합

class의 상속과 조합 활용에 대해서도 학습하게 되었다. 상속은 코드 재사용 측면에서 강력한 문법이지만, 잘못 사용하면 오히려 코드의 유연성을 떨어뜨릴 수 있다는 점을 배웠다. 상속보다 조합(Composition)이 더 적합한 경우도 많다는 것을 느꼈고, 로또 2단계 리팩토링에서 조합의 개념을 적용해보았다.

2.1.3. 모델의 역할과 중간 계층 객체

로또 미션까지 MVC 패턴을 적용하면서 Model과 View 사이의 역할을 Controller가 어떻게 잘 분리하고 중재할 수 있을지 고민해보게 되었다.

기존의 나의 코드에서는 모델을 마치 상태를 가진 데이터 저장소처럼 작성하고 사용하였다.
하지만 모델은 자신의 역할을 책임지고 메세지를 던지는 주체여야한다고 생각하게 되었다.

또한 이렇게 작성하니 이전보다는 컨트롤러의 과중한 부담이 덜어지긴 했지만, 그럼에도 컨트롤러가 여전히 지닌 책임이 너무 많다는 생각이 들었다.

그래서 컨트롤러와 모델의 역할에 대해 계속 고민하고 여러 피드백들을 보면서 중간 레이어 객체를 만들게 되었다.

모델들의 의존성 주입을 받아 컨트롤러와 소통하는 모델이며 이를 구현하기 위해 배웠던 조합(Composition)을 로또 미션에 적용해보았다.
의존성 주입으로 결합도를 낮추는 시도와 캡슐화로 응집도를 높이려는 노력이었다.

LottoMachine이라는 중간 계층 모델을 만들어 Lotto 모델을 의존성으로 주입해 주면서 추후 미국 로또 추가와 같은 로또의 형식 자체가 변경될 경우에도 LottoMachine은 계속 활용할 수 있도록 확장성을 고려하여 설계하였다. 이렇게 나의 모델은 결합도를 낮출 수 있었다.
또한 도메인 모델들과 컨트롤러의 책임을 분리하기 위해 모델의 캡슐화에 대해서도 고민하였다.

그렇게 나의 모델은 자신의 데이터는 자신이 책임지고 관리하며, 필요한 데이터만 가공해서 내보내므로 프라이빗 필드를 get해야 하는 상황을 피할 수 있게 되었다.

2.2. 테스트 코드 작성

2.2.1. TDD

기능을 구현하기 전에 테스트부터 먼저 작성하는 TDD 방식은 처음에는 낯설고 버거웠다. 그래도 점차 구현보다 먼저 요구사항을 정리하고, 작은 단위로 명확하게 기능을 나누는 사고 방식이 길러졌던 것 같다. 테스트가 잘 통과되면 마치 게임 퀘스트에 통과한 느낌이라 묘한 즐거움도 있었다. 리팩토링할 때도 불안감 없이 코드를 고칠 수 있어 구현과 테스트를 번갈아가며 점진적으로 완성해가는 흐름이 생각보다 생산적이었다.

하지만 테스트를 먼저 작성해야 한다는 압박감 때문에 구현보다 테스트를 위한 고민에 시간을 더 많이 쓰는 느낌이 들기도 했다. 특히 처음 접하는 문제나 연결이 복잡한 흐름의 경우, 테스트 코드를 먼저 어떻게 짜야 할지 막막해서 손이 멈추는 순간도 많았다. 또, 테스트 코드 작성 자체가 익숙하지 않다 보니 오히려 테스트가 리팩토링을 방해하거나, 코드의 유연함을 해치는 것처럼 느껴질 때도 있었다.

TDD는 분명 강력한 도구지만, '무조건 TDD를 해야 한다'는 생각보다는 상황에 따라 적절하게 활용하는 유연함이 필요할 것 같다는 생각이 들었다. 특히 로직이 복잡하고 안정성이 중요한 부분에 집중적으로 적용하고, 그렇지 않은 부분은 기능 구현에 먼저 집중하는 식의 균형 잡힌 접근이 더 현실적이라는 걸 느꼈다.

2.2.2. 단위 테스트 / E2E 테스트

초기에는 단위 테스트 중심으로 jset를 이용하여 작은 함수의 동작만 테스트했다. 테스트가 실패할 경우 무엇이 잘못되었는지 쉽게 알 수 있었기에 기능 구현과 리팩토링을 하는 때 모두 유용하게 사용할 수 있었다. 추가로, utils나 validator에 대한 테스트 코드를 작성하는 것도 개인적으로 괜찮았던 것 같다. 도메인 로직에 해당 함수들을 사용할 때 오류가 난다면, 도메인의 문제이고 유틸 함수들은 문제 없다고 믿고 작성할 수 있다는 관점에서 말이다. 그런데 반대로 꼭 작성해야하냐는 리뷰어의 의견도 있었던 걸로 기억한다. util 에 문제가 있는 거라면 어차피 모든 도메인 로직에서 일괄적으로 오류가 터질텐데, 오히려 범용적으로 사용하는 util이야 말로 간접적으로 항상 테스트가 되고있는 것 아니냐는 말이었다. 일리가 있다고 생각하지만, 그래도 도메인 로직이 모두 완성되기 전, 구현 단계에서는 util이나 validator 코드를 '믿고' 쓸 수 있다는 것만으로 시간 단축이 꽤 된다고 생각하기 때문에 나는 뭐...작성해도 괜찮은 것 같다.

웹 UI 미션으로 넘어오면서는 사용자 흐름을 검증하는 E2E 테스트도 cypress로 작성하게 되었다. 특히 영화 리뷰 미션에서는 실제 사용자가 페이지를 어떻게 탐색하고, 어떤 액션을 하는지를 기준으로 테스트를 구성하면서 기능이 제대로 연결되는지를 점검할 수 있었다. 또한 서버의 응답도 테스트하고, fixture로
다양한 테스트 방식을 경험하면서 테스트는 단순한 보조 수단이 아니라 설계와 구현의 기준점이 될 수 있다는 걸 배웠다.

2.3. 컴포넌트

2.3.1. 컴포넌트를 나누는 기준

점심 뭐 먹지와 영화 리뷰 미션을 통해 컴포넌트를 어떤 기준으로 나눌 것인지 깊게 고민해보고 나만의 기준을 세울 수 있었다. 초반에는 단순히 UI 요소 하나하나를 컴포넌트로 분리하거나, 화면상에서 나뉘는 영역을 기준으로 컴포넌트를 쪼갰다. 하지만 점차 기능의 응집도와 관심사를 기준으로 나누는 것이 유지보수와 확장성에 더 유리하다는 것을 체감하게 되었다.

컴포넌트는 자신의 역할을 명확하게 가지고 있어야 하고, 내부 상태와 외부에서 주입받는 데이터 간의 경계를 분명히 해야 재사용성이 높아진다는 것을 알게 되었다. 이를 기반으로 MovieList, ScrollObserver, StarRatingForm 등의 컴포넌트를 각각의 목적에 따라 나누고, 각자 이벤트 등록부터 렌더링까지 자신이 책임지도록 구현했다. 이러한 코드를 짜기 위해 리액트의 props 전달을 모방한 인자전달에 따른 구조 생성, 상태 변화에 따른 리렌더링을 위한 콜백 함수의 이해 등등 나 혼자 했다면 이해하기 너무 힘들었을 개념과 시도들이 많았는데, 마침 이런 방식을 해보고싶던 차에 이런 프로그래밍에 능한 페어와 만나게되어 도전해볼 수 있었다. 사실 당시의 나에겐 어려운 도전이긴 했어서 바로 체득하진 못했었지만 계속 이 때 배웠던 개념을 기반으로 리팩토링을 하고 차근차근 활용도 해보면서 이젠 드디어 이해도 되고 나만의 방식으로 작성도 할 수 있게된 것 같다! 우테코는 정말 코치분들 뿐만 아니라 크루들에게도 많이 배워서 혼자 학습할 땐 엄두도 못낼 시도들을 해볼 수 있다는 점이 너무 감사하고 좋은 것 같다.

2.3.2. 컴포넌트의 관심사 - 기능 조직 v.s. 목적 조직 (+응집도)

기능 조직과 목적 조직. 점심 뭐 먹지 리뷰어 해먼드에게 처음 들었던 생소한 개념이다.

컴포넌트 고민을 시작했던 점심 뭐 먹지 미션에서는 리뷰어 덕분에 정말 생소하고 낯선 관점에서부터 코드를 고민해볼 수 있었다.

2.4. 비동기와 웹 API, 이벤트 루프

2.4.1. 비동기

비동기 처리 흐름에서는 fetch, async/await, then/catch를 활용해 API와 통신하고, 오류를 잡는 흐름을 처음으로 경험해볼 수 있었다. 특히 영화 리뷰 미션에서는 서버 요청 타이밍과 로딩 처리, 에러 핸들링까지 하나의 흐름으로 설계해야 했기 때문에 자바스크립트의 이벤트 루프와 비동기 큐, 콜스택에 대한 이해가 필요했다.

자바스크립트가 단일 스레드 환경에서도 브라우저의 멀티 스레드를 활용해 비동기를 효과적으로 처리하는 구조라는 것을 알게 되었고, 그 원리에 기반한 UI 구성은 단순히 작동하는 코드 이상으로 사용성과 안정성에 직접적으로 연결된다는 것을 느꼈다.

2.5. 서버 API

2.5.1. 도메인 객체

서버에서 받은 데이터를 그대로 사용하는 것이 아니라, 클라이언트 관점에 맞게 변환하고 추상화하는 중간 계층의 필요성을 체감하게 되었다. 서버 응답 구조가 프론트엔드에서 필요한 형태와 맞지 않거나 네이밍이 일치하지 않는 경우, 서버 API를 변경하게될 경우 등등의 케이스를 대비해 이를 적절히 가공하는 도메인 객체를 별도로 두어 응집력 있는 데이터 구조를 구성하는 것이 핵심 포인트였다.

추가로, 하리의 피드백에서 '서버 네이밍에서는 스네이크 케이스를 많이 쓰고 클라이언트 네이밍은 카멜케이스를 쓰는 경우가 많아, 네이밍을 변환해주는 유틸함수를 만들어 쓰기도 한다'라는 흥미로운 의견을 받을 수 있었다. 이번 미션에서는 시간에 쫓겨 제출하느라 해당 유틸 함수를 만들진 못했지만...방학동안의 리팩토링이나 다음 미션에서 도전해볼만한 재밌는 코드인 것 같다.

2.6. 이벤트

2.6.1. 이벤트 위임

반복적인 querySelector와 addEventListener 와 같은 DOM 조작은 비용이 많이 드는 작업임을 알게 되었다. 그래서 자바스크립트의 이벤트 버블링을 통해 적절한 부모 요소에서 이벤트를 위임하는 방식으로 DOM 조작을 최소화하는 것이 성능상 좋다. 이를 내 코드에 점진적으로 반영해가며 최적화된 이벤트 핸들링에 대해서도 고민을 많이 하게 되었다.

2.6.2. 이벤트 관리

원래 나는 html 친화적으로(?) 최대한 활용하며 작성해보고 싶어서 dataset을 이용해 이벤트 메서드를 붙여주고 전체 DOM에 click 이벤트를 걸어 하나의 ClickEvent.js 파일에서 모든 이벤트 메서드들을 관리했었다. 도전적인 측면에서 나쁘진 않았다고 생각하지만, XSS 공격에 취약하다던가 프로그램 품이 커질 수록 유지보수성이 떨어진다던가 하는 등등의 이유로 이러한 관리방식은 결국 버리게 되었다.

그리고 대신 목적 조직에 대한 키워드를 학습하며 컴포넌트가 마치 객체가 자신의 역할을 자신이 책임지듯, 자신의 이벤트를 붙이고 핸들링하는 식으로 변경하였다.
개인적으로 우리가 로또 미션까지는 도메인 로직과 UI 로직의 분리, 관심사 분리에 학습 목표를 세우고 공부했었기 때문에 이러한 방식이 처음엔 거부감이 들었던 것 같다. 하지만 해먼드의 목적 조직 피드백도 있었고 이런 방식으로 작성했던 써밋에게 의견을 물어봤을 때 돌아온 답변에 설득되어서 코드 구조를 바꾸게 되었다.

내 기존 코드처럼 이벤트 등록/이벤트 관리/컴포넌트 등을 따로 관리하다보면 해당 컴포넌트가 삭제될 경우 최소 3개 이상의 파일을 수정하고 건드려야하는 번거로움이 있다. 하지만 컴포넌트가 자신의 역할을 다 책임진다면 컴포넌트를 삭제할 때도 그 컴포넌트 파일 하나만 딸깍 지워주면 될 것이다. 그래서 유지보수 측면에서도 장점이 있다고 말했다. 음, 설득됐음.

2.6.3. addEventListener & removeEventListener

하리의 피드백 덕분에 자바스크립트에서 addEventListener로 붙여준 이벤트는 계속 중복 등록될 수 있고 해당 요소가 DOM에서 사라지더라도 이벤트가 사라지진 않기에 removeEventListener를 제때 해주지 않으면 메모리 누수로 이어질 수 있다는 것을 알게 되었다. 또한, 이벤트를 등록한 대상의 이벤트를 정확히 지워주려면 이벤트 리스너 두 번째 인자로 들어가는 콜백 함수가 익명 함수가 아닌 기명 함수로 전달되어야 제대로 집힌다는 것을 알았다. 해당 개념을 학습하면서 클래스 내에서 이벤트를 붙여줄 때 클래스 내의 메서드를 쓰겠다고 this를 붙여주면 나중에 this 바인딩이 깨져 의도치 않은 동작이 될 수 있다는 것도 학습할 수 있었다.

---

3. 감정 회고 💭

우테코에서는 단순히 하드 스킬 학습 뿐만 아니라, 매주 페어 프로그래밍, 유연성 강화 워크숍과 같은 다양한 활동을 하기 때문에 소프트 스킬의 역량도 키울 수 있다. 우테코 환경자체가 크루원들끼리의 커뮤니케이션이 매우 활발하고 친화적이며 모든 크루가 열정을 갖고 몰입된 우테코 생활에 임하기 때문에 나도 자연스럽게 자극받고, 혼자였다면 시도하지 않았을 성장의 기회를 얻게 된다.

이런 배경으로 인해 정말 바쁘게 지나가버린 레벨1에서 연극조 크루들과 자주하는 이야기가 있다.
'개발 공부 뿐만 아니라 인생 공부를 하게 해주는 우테코! 사람을 만들어준다!ㅋㅋ'

이런 우스갯소리를 진담처럼 하는만큼, 우테코 생활을 하며 느끼고 내면적으로 성장한 바가 크기 때문에 감정 회고도 짧게 해보려한다.

3.1. 레벨 1에서의 의미있는 변화

일단 어떻게든 혼자 해결하며 남에게 물어보기는 절벽 끝에 매달려 외치는 최후의 SOS였던 프리랜서의 오랜 습관이 고쳐졌다. 이건 사실 프리랜서여서라기보다 이런 성향 때문에 프리랜서를 택한 것도 크기 때문에 정말 나의 오랜 성향에 변화가 생긴 셈이다.

구체적으로 말하자면 지금은 모르는 게 생기면 크루들에게도 바로바로 물어보고 고민도 해보고 리뷰어와도 활발한 소통을 하는 모습으로 바뀌었다.
다른 사람의 시간을 쓸데없이 뺏는 것 같아서, 모르는 것을 물어보기 머쓱해서 등등의 이유로 눈치를 보며 혼자 끙끙댔던 과거와 비교해보면, 지금의 습관이 훨씬 긍정적인 것 같다.

더 짧은 시간 내에 빨리 해결하고 많이 배우며 성장할 수 있었기 때문이다.

3.1.1. 의미있는 경험을 할 수 있었던 이유

크루들이 있었기 때문이다! 개발을 시작한지 얼마 되지 않아 헛소리도 많이하고 아주 기초적인 질문들도 자주 하였는데 단 한 명도, 단 한 번도 짜증내거나 무시한 사람은 없었다. 모두가 친절하게 자신의 고민처럼 깊게 생각하고 알려주었고 덕분에 기죽지 않고 모르는 건 공부하면 된다는 마인드를 가질 수 있었다.

3.2. 유연성 강화를 위해 시도했던 것

쭈뼛쭈뼛 크루들에게 모르는 걸 물어보러가던 그 때 기분이 생각난다. ...그거 사실 엄청난 용기였어... 정말 혼자 도저히 모르겠어서 물어보고싶은데 물어봐도 될까 고민을 1시간을 하고 있었거든, 바로 옆자리에서...ㅋㅋ

하지만 지금은 모두가 나의 gpt. 감사합니다 크루들...특히 레벨 1 내내 언제나 선뜻 도움을 주고 힘을 주었던 우리 연극조, 데일리미팅조에게 압도적 감사를 . . .🥹
나도 얼른 도움줄 수 있는 크루원이 되어야겠다.

그리고 첫주차에는 리뷰어와 소통도 제대로 하지 않았었는데
지금은 저번 미션도, 이번 미션도 1단계 피드백에서 코멘트 70개가 넘어가는 매우 큰 변화가 생겼다.

코딩이라는 게 이렇게 코드리뷰를 활발하게 주고받을 때 많이 배우고 성장할 수 있는 것 같아서, 개발자들의 활발한 커뮤니티가 이해되었다.

---

4. 앞으로의 계획 및 다짐🫡

4.1. 방학 때

4.1.1. 공부 목록

• 미션 구현하느라 급급해 쌓여만 갔던 학습 부채 해소하기...복습하자.
• 주렁과 코어 자바스크립트 완독 목표

4.1.2. 프로젝트

• 캉골과 토이 프로젝트 (대략 4일 정도?)

4.1.3. 테코톡 발표 준비

• 아직 레벨2에 할지 3에 할지 안 정했지만...슬슬 준비 시작해야될 듯. 레벨1도 미션에 허덕였는데...미리미리 준비해둬서 나쁠 것 없을 것 같다.
• 지금 아이디어로는 프론트엔드이고 모바일안드로이드도 같이 있는 선릉캠이니만큼 UI/UX와 연관된 주제는 어떨까싶다. UIUX도 내 학습 목록에 있기도 하고.

4.2. 레벨 2 때

4.2.1. 새롭게 설정하는 레벨2 일상 루틴

• 매일 짧게라도 오늘 뭘 했는지, 어땠는지 메모해놓기. 특히 감정. 시간이 많이 지나서야 회고를 쓰게될 때 참고하기 좋을 것 같다.

4.2.2 예정된 스터디

(유지)

• 코딩테스트 스터디
• PR 리뷰 스터디
• 블로그 회고 스터디

(New!)

• 모던 리액트 딥다이브 스터디