돌멩이 하나/셀프 크리틱

1-2년 차에 공부해야 할 키워드

미래에서 온 개발자 2025. 1. 1. 22:13

작년 12월 무렵 한 해 동안 공부해야 할 키워드 목록을 다음과 같이 뽑았었다. 

 

✅ 디자인 패턴

TypeScript 

클린 코드

Git

 예외 처리 및 에러 핸들링 

프론트엔드의 테스트 전략 및 테스트 코드 작성 방식

아키텍처

렌더링 패턴: CSR, SSR 등 

Next.js

JavaScript Deep Dive

팀, 협업 

 

공부하면서 도움이 되었던 자료들은 다음과 같다. 

 

1. 디자인 패턴

https://www.patterns.dev/

 

Patterns.dev

Learn JavaScript design and performance patterns for building more powerful web applications.

www.patterns.dev

https://refactoring.guru/ko/design-patterns

 

디자인 패턴들

 

refactoring.guru

 

2. TypeScript

장기효, <쉽게 시작하는 타입스크립트> 

https://www.yes24.com/product/goods/119410497

 

쉽게 시작하는 타입스크립트 - 예스24

8000명 이상의 수강생이 인정한 인프런 인기 강의를 책으로 만나다!‘캡틴판교’와 함께 타입스크립트를 쉽게 시작해 보자!타입스크립트는 자바스크립트에 타입을 부여한 언어로, 타입 시스템

www.yes24.com

 

3. Git 

기계인간 이종립 님의 <당신의 2번째 git 강의>

https://www.codesoom.com/courses/git

 

Git 강의 - Git 마스터 패키지(4주) | 코드숨

당신의 두 번째 Git 강의. Git의 내부 구조 학습을 통해 원리부터 응용까지 배워봅니다.

www.codesoom.com

 

4. Next.js 

Learn Next.js

https://nextjs.org/learn

 

Learn Next.js | Next.js by Vercel - The React Framework

Next.js by Vercel is the full-stack React framework for the web.

nextjs.org

 

5. JavaScript Deep Dive

이웅모, <모던 자바스크립트 딥다이브>

https://m.yes24.com/Goods/Detail/92742567

 

모던 자바스크립트 Deep Dive - 예스24

『모던 자바스크립트 Deep Dive』에서는 자바스크립트를 둘러싼 기본 개념을 정확하고 구체적으로 설명하고, 자바스크립트 코드의 동작 원리를 집요하게 파헤친다. 따라서 여러분이 작성한 코드

m.yes24.com

 

6. 팀, 협업

김창준, <함께 자라기>

https://m.yes24.com/Goods/Detail/67350256

 

함께 자라기 - 예스24

‘함께’는 협력을 말하고, ‘자라기’는 학습을 말한다. 무엇이건 실제 바깥세상(야생)에 임팩트를 남기려면 혼자 힘으로만 되는 게 없다. 함께 해야 한다. 주변 사람들과 함께. 매일 부대끼는

m.yes24.com

 

 

클린 코드와 아키텍처 관련해서는 여러 아티클들을 살펴보았으나 성에 찰 만큼은 아니기에 체크 표시를 하지 못했다. 단순히 올 한 해가 아니라 앞으로 개발을 업으로 삼고 일하는 동안 가져가야 할 키워드라는 생각도 든다. 

 

테스트 코드 관련해서는 아쉬움과 회한이 많이 든다. 올 하반기 무렵부터는 테스트 코드의 필요성을 정말 절실히 느꼈다. QA 과정만으로 더이상 서비스와 코드의 안정성을 담보할 수 없는 순간들이 많아졌다. 매번 월별 회고마다 아쉬운 점으로 테스트 코드를 도입하지 못한 점, 공부하지 못한 점을 꼽았으나 결국 마지막 퇴사할 때까지도 테스트 코드를 제대로 다루지 못했다. 

 

프론트엔드에서 테스트 코드가 정말 필요한가 라는 주제는 늘 갑론을박이 있는 것 같다. 내가 맡았던 프로젝트는 정식 런칭은 아니었지만 실제 사용자가 우리 서비스를 그들의 업무에 사용하고 있었고, 이와중에 신규 기능이 계속 추가되었다. 신규 기능을 release 하기 전에 항상 QA 과정을 거치지만 A 기능을 배포한 후, B 기능을 개발하면서 기존에 잘 동작하던 A 기능 중 일부가 제대로 동작하지 않는 일이 빈번하게 발생했다. 새로운 기능 QA가 추가되거나 버그 수정을 할 때마다 매번 몇 백  개에 달하는 기존 QA 테스트 케이스를 전부 다 사람이 하나하나씩 해볼 수 없는 일이다. 

 

실제로 퇴사 전 마지막 운영 배포 시에도 이와 관련해서 배포 후 바로 버그가 나왔다. 배포에 포함되는 신규 기능에 대한 QA 테스트 케이스 통과 후에 여러 건의 버그를 수정하면서 코드가 변경되었고, 신규 기능 QA 테스트 시나리오에서 pass였던 부분이 fail로 바뀐지 모르는 채로 운영에 올라갔던 것이다. 

 

모든 프론트엔드 프로젝트에 테스트 코드가 필요하다고 생각하지는 않는다. 몇 달 전에 스터디원과 이 주제로 얘기를 나눈 적이 있었는데, 하나의 프로젝트가 점점 거대해지면서 리팩토링이 필수불가결하게 되는 시점이 올 때 테스트 코드가 필요해지는 것 같다고 얘기한 적이 있다. 반면 프로젝트 성격이 데이터(모델)은 고정적이고 UI만 계속 바뀐다면 굳이 테스트 코드가 필요하진 않은 것 같다. 하지만 테스트 코드를 만든다면 모킹을 어디서부터 어떻게 해야 하는지 등 아직까지는 그냥 모든 것이 막막한 느낌이다. 언젠가는 이 막막함에 조금의 탈출구라도 생길 것인지...