DEV ENJOY🌊

Nuxt 프로젝트 Next로 이관 계획

Nuxt로 만든 사이드 프로젝트를 아래와 같은 이유로 Next로 이관하려고 한다.

• 리액트를 더 집중적으로 공부해 보고 싶다
• Vue와는 다르게 리액트는 할수록 이전에는 몰랐던 javascript의 문법/특징에 대해 알아가는 느낌
• 사용자가 많은 만큼 참고 자료가 정말 많다

컴포넌트 스타일링

이번에는 뭘로 컴포넌트를 스타일링할지 고민해 봤다. 고려 대상은 아래와 같다.

• CSS module
• CSS-in-JS
  • styled components
  • emotion

CSS Module VS CSS-in-JS

컴포넌트 스타일링을 크게 나눈다면 CSS Module와 CSS-in-JS로 나눌 수 있을 것 같다. (tailwind같은 CSS 프레임워크는 개인적으로 좋아하지 않아 제외)

• CSS Module: CSS-in-JS에 비해 성능이 좋음. 규모 있고 안정적인 서비스에 유리
• CSS-in-JS: 개발 경험이 좋음. 빠른 속도가 필요한 소규모 서비스에 유리

둘 다 사이드 프로젝트에서 사용해 봤지만, CSS Module은 컴포넌트 내에서 css 파일을 import 하고 import 한 css 파일에서 클래스명을 꺼내서 각 요소에 클래스명을 적용해 줘야 하는데, 코드가 굉장히 지저분해져서 싫었다. 내 프로젝트는 소규모이니, 큰 부담 없이 CSS-in-JS를 선택하기로 한다.

주요 참고 글 카카오 웹툰은 CSS를 어떻게 작성하고 있을까? | 카카오 엔터테인먼트 FE 기술 블로그

styled-components VS emotion

어떤 글을 봐도 뭐가 분명하게 더 좋다는 글은 없었다.
styled-components는 한번 사용해봤고 최근 emotion 패키지 다운로드 수가 높으니, 이번에는 emotion을 한번 사용해보기로 한다.

📌 주요 참고 글

• Thinking about emotion js vs styled component
• [React] emotion과 styled-component의 차이

인상 깊게 읽은 글

📃 적정기술 딜레마

📌 적정기술 딜레마 | 카카오엔터테인먼트 FE 기술블로그

언제나 개발자는 이유가 있어야 한다는 얘기를 많이 듣는다. 하지만 나같이 경험이 많지 않은 주니어 개발자들은 무엇이 적정 기술인지에 대해 정확히 알기가 어렵다. 폭풍 서치 해보는 것이 최선인데, 서치해도 명확한 정답을 얻기가 쉽지 않다.

물론 사이드 프로젝트이니까 많이 쓰는 이유가 궁금해서 한번 겪어보고 싶어서 특정 기술을 경험해 보고자 한번 써볼 수 있긴 하지만, 실무에서는 많은 상황들을 고려하여 더 보수적으로 꼭 필요할 때 기술을 사용해야 한다는 말이 와닿는다.

• 서비스 요구사항에 적합한지
  
  • 최소한 어떤 기술을 도입하기 전, 서비스 요구사항과 수준, 개발 난이도 파악이 우선이다.
• 많은 사람이 사용하고 있는지
  
  • 어떤 기술을 사용하든 문제는 발생하기 마련이고, 원활한 문제 해결은 집단 지성의 힘에서 비롯된다.
• 현재 조직에 적합한지
  
  • 사업보다 학습이 우선될 수는 없다.
• 기존 기술에 비해 획기적 개선이 있는지
  
  • 어떤 부분이든 개선점이 있어야 설득이 된다. (생산성 or 퍼포먼스)

적정 기술이란 무엇인가에 대한 고민에 가이드를 제시해 주는 고마운 선배의 글이다.

📃 프론트엔드와 SOLID 원칙

📌 프론트엔드와 SOLID 원칙 | 카카오엔터테인먼트 FE 기술블로그

자세한 예시와 함께 정말 정리가 잘 되어있다. SOLID 원칙은 처음 들었지만, 내용들은 낯설지만은 않다. 여기저기서 말하는 좋은 코드란 무엇인가에 대한 내용이 잘 정리된 느낌이다. 개발하면서 겪었던 경험들이 떠오르면서 폭풍 공감하고 감탄했다. 가슴 깊이 새기며 개발해야지!

SOLID 원칙이란

• SRP: 단일 책임 원칙 (Single Responsibility Principle)
• OCP: 요구사항이 변경될 때 기존 코드를 변경하는 것이 아니라 새로운 코드를 추가하는 방향을 추구하는 원칙 (Open/Closed Principle)
• LSP: 리스코프 치환 법칙 - 상속(is-a)으로 이어진 관계에서 예상 못할 행동을 하지 말라 (Liskov Substitution Principle)
• ISP: 인터페이스 분리 원칙 (Interface Segregation Principle)
• DIP: 의존성 역전 법칙 (Dependency Inversion Principle)

콘웨이 법칙

조직의 커뮤니케이션 구조를 닮게 된다. 곧 닮아야 한다!는 말이라고 한다. 여기까지 생각이 닿아본 적은 없는데, 이제 알았으니 앞으로는 생각해 볼 수 있겠다.

“소프트웨어 구조는 해당 소프트웨어를 개발한 조직의 커뮤니케이션 구조를 닮게 된다.” - 콘웨이

콘웨이 법칙에 입각해 소프트웨어 구조를 조직의 커뮤니케이션 구조와 유사하게 만들 수 있도록 도와주는 > 원칙이 바로 SRP(Single Responsibility Principle) 원칙 입니다.

SRP : Single Responsibility Principle

콘웨이 법칙에 입각해 소프트웨어 구조를 조직의 커뮤니케이션 구조와 유사하게 만들 수 있도록 도와주는 원칙이 바로 SRP(Single Responsibility Principle) 원칙 입니다.

중요한 점은 SRP의 ‘책임’이 의미하는 것을 소프트웨어 내부의 ‘동작’ 이나 ‘논리’가 아니라 조직 간 커뮤니케이션 영역으로 봐야 한다는 점입니다.

즉, SRP 원칙을 지킨다는 것은 컴포넌트를 설계할 때 “요구사항을 전달하는 책무 단위”로 설계한다는 것을 의미합니다.

각 영역의 요구사항을 명확히 파악하고 영역을 구분해 의존성 없는 독립적인 컴포넌트로 만들어 각 책무의 요구사항 변경에도 사이드이펙트 없이 유연하게 대처할 수 있도록 설계하고 구현하는 것이 키포인트라 볼 수 있습니다.

개발자 개인의 역량도 중요하겠지만, 기획, 디자인과의 충분한 커뮤니케이션도 아주 중요하겠다는 생각이 들었다.

LSP : Liskov Substitution Principle

리스코프 치환 법칙 - 상속(is-a)으로 이어진 관계에서 예상 못할 행동을 하지 말라.

한 번쯤은 경험해 봤을법한 예시였다. 공감하고 반성하면서 읽었다.

코드 레벨로 예를 들면 ApiErrorBoundary라는 컴포넌트로 이름 지었을 때 이를 사용하는 입장에선 ‘아, API 요청 중 발생하는 에러를 처리하는 컴포넌트구나’로 생각하고 사용하게 됩니다. 하지만 실제로 개발하다 보면 이곳에 API와 상관 없는, 아주 작은 에러처리 하나만 더 넣고싶은 유혹이 생겨 슬쩍 넣는 경우가 생길 수 있습니다. 이렇게 되면 실제 에러가 발생했을 때 매우 찾기 어려운 상황이 생기게 될 수 있습니다.

‘정의된 것과 달라 찝찝하지만 일정 상 어쩔 수 없으니 이대로 가자’로 생각한 것들은 끔찍한 기술부채로 남게 되는 경우가 많았습니다. 이런 찝찝함이 LSP 원칙 레이더에 감지된 것이라면 구조부터 잘못되어있을 가능성이 높구요. 이때 회피하지 않고 문제를 직면하며 하나하나 해결했을 때 코드나 아키텍처가 눈에띄게 명확해졌던 경험이 많이 있습니다.

마무리

끊임없이 생각하고 개선해가는 경험과 태도!

커뮤니케이션 구조를 기반으로 컴포넌트의 네이밍부터 시작해 각각에 맞는 책임, 책무를 정의하고(SRP) 변경하는 요구사항을 최소한의 코드 (추가를 통한) 변경을 통해 유연하게 대응하고(OCP), is-a를 의도했다면 그 의도에 맞게 구현되도록 힘쓰고(LSP), 컴포넌트에 꼭 필요한 인터페이스만 의존할 수 있도록 구성하고(ISP), 필요하다면 의존성을 역전시켜 독립된 컴포넌트로 만들 수 있도록(DIP) 끊임없이 생각하고 개선해가는 경험과 태도가 중요하다고 생각합니다.