준프

타입스크립트에서 Type vs Interface

타입스크립트를 활용해 개발하실 때 타입과 인터페이스를 언제 사용하시나요?

관련된 글은 정말 많지만 어딘가 모르게 비어있는 듯한 느낌을 받는 건 이 글들이 기술적 차이를 주로 다루고 사용자에게 선택지를 주기 때문이라고 생각합니다. 즉, "타입과 인터페이스는 서로 비슷한 기능을 하지만 대부분 사용하는 데 큰 차이를 못 느낄거야. 그러니까 선호하는 걸 사용해."라고 말하는 듯 합니다. 결국 왜 타입을 선택했고 왜 인터페이스를 선택했는지 그 이유는 다시 스스로 만들어내야 합니다.

이번에 소개해드리는 글의 결론은 다른 글들과 비슷하지만 인터페이스와 타입 어노테이션에 대해 미묘한 공통점, 차이점을 드러내고 있습니다.

In TypeScript, think of an interface as a set of rules or requirements that an object must follow. It’s like a contract that says, “Hey, if you want to be a ‘Client,’ you must have a ‘name’ and an ‘address.’”

그리고 개발자가 OOP에 친숙하다면 인터페이스를 함수형 프로그래밍에 친숙하다면 타입을 사용하는게 아닐까? 하는 생각이 들게 만드는 문장도 있습니다.

Interfaces are also more readable when you’re thinking in terms of object-oriented programming.

In addition, many developers prefer using types because they align well with the functional programming paradigm.

길지 않지만 타입과 인터페이스 사이에서 방황하고 있다면 도움이 되지 않을까 합니다.

리액트 상호작용 시간을 4배 개선하기

이번에 소개해드리는 글은 리액트 상호작용 시간을 개선하는 경험을 공유하는 글입니다.

글쓴이는 겉으로 보기엔 단순해보이는 성능 이슈를 해결하기 위해 어떤 과정을 거쳤는지 정말 자세하게 공유하고 있습니다.

이 글을 통해 제가 얻은 인사이트는 이렇습니다.

• 보통 리액트 성능 이슈가 있다면 이렇게 깊게 먼저 들어가지 않는 편입니다. 간단하게 해결할 수 있는 방법은 없는지 알아보는 시간을 갖습니다. 하지만 글쓴이는 성능 이슈가 발생했을 때 프로파일링을 먼저합니다. 프로파일링은 쉬운 과정은 아닙니다. 어떤 함수가 성능 문제를 일으키는지 다소 깊게 파악해야 합니다. 그리고 이 경우 리액트에 대해 잘 알고 있어야 합니다. 예를 들어, performSyncWorkOnRoot가 리액트 렌더링 과정에서 호출되는 함수라는 걸 알아야 합니다.

• 또한 자신의 리액트 코드 뿐만 아니라 AG Grid라는 외부 라이브러리의 코드도 함께 살펴봅니다. 보통 외부 라이브러리에서 문제가 발생하면 파헤쳐보기 전에 우회하여 해결 할 수 있는 방법을 탐색합니다.

• 원인을 파악하기 위해 다양한 도구를 사용합니다. 크롬 개발자도구와 리액트 프로파일링 도구를 합리적인 이유를 갖고 적절한 때에 사용합니다. (이유도 함께 적어놨습니다.)

• 이 모든 과정에서 상당한 양의 '지식'이 사용됩니다.

한 가지 문제를 풀기 위해 이렇게 오랜 시간을 사용할 수 있는 건 '확신'이 필요하다고 생각합니다. 다른 방법보다 이 방법이 문제를 해결하는 데 더 확실한 방법이고, 해결할 수 있는 더 좋은 방법이라는 확신이 있어야 중간에 의구심을 품지 않고 끝까지 해낼 수 있습니다. 그리고 그 확신은 명확한 계획에서 나옵니다.

He was convinced before that the formula is correct because he derived it carefully. But now he is more convinced, and his gain in confidence comes from a different source; it is due to a sort of "experimental evidence."

<HOW TO SOLVE IT>

그리고 이렇게 해낼 수 있는 다른 이유 중 하나는 계획을 실행하기에 필요한 지식과 경험입니다. 이 글을 읽어보면 상당한 양의 지식과 경험을 볼 수 있습니다.

Good ideas are based on past experience and formerly acquired knowledge.

<HOW TO SOLVE IT>

이 글을 통해 문제를 어떻게 해결해야 하는지 한 번 더 생각해보게 되는 계기가 됐습니다. 또한 내가 다루고 있는 도구나 방법론에 대해 얼마나 알고 있고 경험했는지, 그 경험은 어떤 종류인지 돌아보게 됐습니다.

최근 시청한 영상을 추가로 남깁니다.

그 사이의 균형을 잘 유지해야죠. 예술가인 동시에 과학자가 되어야 합니다. 이미 정해진 레시피를 무시하고 모든 걸 처음부터 '이해'하려고 한다면, 아무것도 만들지 못할 겁니다. 하지만 본질을 '이해'하지 않고 아무 생각 없이 레시피만 따라 한다면, 잘못된 제품을 만들 겁니다.

그렇게 복잡하게 생각할 필요 없습니다. 컴퓨터를 새로 만든다고 해보죠. 만약 여러분에게 일을 맡긴 의뢰인이 컴퓨터 성능을 10% 높이고 싶다고 한다면, 메모리 용량을 늘리거나 부품을 추가하겠죠. 아니면 컴퓨터의 설정을 만져서 성능 효율을 최대치로 끌어올릴 겁니다. 하지만 부품을 추가하고 설정을 바꿀 수록, 구조도 복잡해지고 관리도 어렵죠. 언젠간 벽에 부딪힐 겁니다. 아무리 부품을 덕지덕지 붙여도 성능이 더 좋아지지 않는 시점이 오겠죠. 그러면 대부분 사람들은 이렇게 말해요. "어쩔 수 없어요. 이게 한계입니다." 하지만 극소수는 이렇게 얘기하죠. "지금의 구조는 더 이상 한계야. 뭘 새롭게 추가한다고 바뀔 건 없어. 새로운 구조를 처음부터 다시 짜보자." 그렇게 기존 구조를 뜯어보고 난 후에 사람들은 비로소 알게 됩니다. 아예 처음부터 새로운 구조를 만드는 것이 훨씬 빠르고 간단한 방법이에요.

이 글의 목차는 아래와 같습니다.

• 상호작용 프로파일링

• AG Grid: 불필요한 렌더링 고치기

• AG Grid: 렌더링 제거하기

• useEffect 덜 실행하기

  • areEqual의 깊은 이야기

• 여전히 남아 있는 작업

  • 더욱 세분화된 업데이트

  • useSelector vs useStore

• 잘 동작하지 않은 것

• 결과

Shift Left Testing이 어떻게 버그, 시간 그리고 돈을 아낄까?

이번에 소개해드리는 글은 Shift Left Testing이 무엇인지 소개하는 글입니다. 사실 그보다는 제품을 만드는 과정에 대해 거시적으로 살펴볼 수 있도록 합니다. 이 내용이 도움이 되었다면 함께 일하는 동료와 논의해보는 것도 정말 좋을 것 같습니다.

버그의 책임은 누구에게 있는가?

이 글은 가장 먼저 제품에서 발생한 버그의 책임은 어디 그리고 누구에게 있는지 간단하게 알아봅니다. 사실 이 문장에서 조금 뜨끔한 포인트가 있습니다. 제품을 개발하는 과정 마지막에 제품이 정상적으로 동작하고 기대한 동작을 하는지 검증하는 과정(QA)이 있다면 코드를 작성하면서 은연중에 아래와 같이 생각한다는 것입니다.

"마지막 검증 과정에서 중요한 버그는 발견되고 이후 수정 기간에 수정하겠지"

하지만 이렇게 했을 때 결과는 그리 유쾌하지 않습니다. 아래는 검증 과정에 강하게 의존하면 발생하는 문제에 대한 제 생각입니다.

1. 신뢰가 떨어집니다. 이러한 태도는 좋지 않은 질을 가진 코드를 생산해냅니다. 그리고 마지막 검증 단계에서 발견되는 버그의 갯수가 감소하지 않습니다. 결국 다른 구성원이 개발자를 신뢰하지 못하는 문제가 발생합니다.

2. 시간과 돈이 많이 듭니다 1. 신뢰가 낮다면 비용은 증가합니다. 개발자가 만든 코드에 대한 신뢰가 낮기 때문에 검증 시간과 인력이 많이 듭니다.

3. 시간과 돈이 많이 듭니다 2. 배포 하기 전 마지막 단계에서 하는 검증이기 때문에 이 때 발견된 버그는 수정할 시간이 부족하고 급하게 처리하다보면 또 다른 버그를 만들어내기 마련입니다. 만약 버그를 고치지 못했다면 제때 배포하지 못하고 다음 스프린트로 넘어갑니다.

그리고 이 글에선 아래와 같이 강조합니다.

The quality of the code is a shared responsibility among the entire team.

좋은 결과물에 대한 책임은 마지막 검증 단계, 개발자 등 특정 단계나 팀의 책임이 아닙니다. 각자가 자신의 책임이라 생각하는 태도가 중요합니다.

Shift Left Testing이란?

따라서 마지막 단계에 의존하는 검증이 아니라 개발 과정의 왼편(Left)으로 검증(Test) 과정을 이동(Shift)시킴으로써 더 나은 방법의 검증을 해야 한다고 강조합니다.

Shift Left Testing에 대해 저자는 아래와 같이 소개합니다.

Shift left testing means focusing on testing from the very beginning when we start thinking about how to approach a task.

이 방법의 자세한 수행 방법을 요약하면 아래와 같습니다.

1. 자세한 인수 조건(acceptance criteria)

2. 관계된 모든 구성원이 인수 조건을 파악함

3. 개발자는 마지막 검증 단계 전에 반드시 테스트를 해야함

4. 개발 과정에서 PM과 검증 팀으로부터 지속적인 피드백

이 방법은 실제로 업무를 하며 개선해나가는 과정과 닮아 있어 더욱 공감이 됐습니다. 이 방법을 처음 도입하거나 도입하는 중이지만 잘 안 된다면 아래 세부 내용을 살펴보는 게 도움이 되리라 생각합니다. 이 내용은 제가 추가한 내용입니다.

1. PM 또는 모든 괸계자는 자세한 인수 조건을 준비하고, 개발자는 인수 조건에 따라 개발해야 합니다. 이 글에서 소개한 것처럼 준비하는 것만으론 충분하지 않습니다. 때로 이 과정은 매우 번거롭고 힘듭니다. 저 처럼 덤벙대는 성격을 가진 사람이라면 더욱 그렇습니다. 하지만 훈련해야 합니다.

2. 인수 조건이 자세하게 준비되어야 하는 이유는 버그는 코드로부터 나오는 것 뿐만 아니라 애초에 잘못된 인수조건에서 나올 수 있기 때문입니다. (이 글에서도 이 부분을 강조하고 있습니다.)

3. 보통 전문 QA 팀이 있지 않은 조직에선 모든 관계자가 함께 검증을 합니다. 그렇기 때문에 더욱더 인수 조건을 모두 파악하고 있어야 합니다. 그래야 발견하지 못한 문제 케이스를 발견할 수 있습니다.

4. 개발자는 마지막 검증 단계 전 반드시 테스트를 해봐야 합니다. 여기엔 단위 테스트, 개발자 간의 테스트 등을 포함합니다. 이 방법은 마지막 검증보다 비용이 낮고 속도가 빠릅니다.

5. 시작부터 마지막 단계까지 지속적으로 피드백을 주고받아야 합니다. 왜냐하면 우리 모두 사람이기 때문에 각 과정에서 문제를 발견할 수 있기 때문입니다.

6. 지속적인 피드백과 개선이 필요하려면 변경에 유연한 코드를 작성해야 합니다. (이 역시 소개한 글에서 강조하고 있습니다.)

더 자세한 내용은 소개해드리는 글을 참고해보시는 걸 권해드립니다. 위 내용을 더 자세하게 설명하는 것 뿐만 아니라 실제 적용 결과를 공유하고 있기도 합니다.

뿐만 아니라 테스트와 관련해 이전에 공유해드린 '테스트는 센서다'라는 글을 다시 공유드립니다.

15가지 유용한 HTML 속성

이번엔 간단하고 가볍지만 정말 좋은 정보를 담고 있는 아티클을 소개하려고 합니다. HTML 속성하면 접근성과 관련이 있거나 잘 쓰지 않는 속성을 소개하는 경우가 있는데요, 이 글에선 '이런 속성도 있었어?'하는 부분이 종종 있습니다.

이 글에서 소개하는 속성을 나열해보면 아래와 같습니다. 자세한 내용은 글을 참고해주세요 :)

그리고 사용해보기 전 caniuse에서 사용 가능한지 확인해보는 습관도 중요합니다 !

• contenteditable

• spellcheck

• translate

• multiple

• reversed

• draggable

• accesskey

• poster

• onerror

• theme-color

• favicon

• touch-icon

• loading

• async

• defer

모던 프론트엔드 아키텍처를 위한 5가지

이 글의 제목은 스팸처럼 느껴지지만 내용은 그렇지 않았습니다. 각 주제를 간단하게 나열하고 있지만 분명 인사이트를 주는 내용들이 많았습니다. 각 주제가 어떤 내용을 설명하고 있는지, 어떤 인사이트가 있는지 목차와 함께 살펴보겠습니다.

• 디자인 시스템

• 컴포넌트 재사용

  • 컴포넌트를 분리하고 디렉터리에 관리하는 방법에 대해 소개합니다. 이 글에서 가장 눈에 띄는 부분이었습니다. 최근 스타일 및 요소의 중복(DRY)에 대해 고민하고 있었는데 그 결과와 비슷하기도 해서 나름 뿌듯했습니다.

  • 우리는 중복을 제거하기 위해 컴포넌트를 분리하는데, 각 컴포넌트의 크기가 크기 때문에 사용처마다 다른 사용방법을 대응해줘야 하는 문제가 있습니다. 그래서 그런 가능성을 줄이기 위해 최대한 독립적인 부분들, 즉 작은 크기의 컴포넌트를 사용해야 합니다.

  • 다만, 이렇게 했을 때 문제도 있습니다. 컴포넌트 구조를 파악할 때 인지부하가 발생할 수 있고 아무리 작고 독립적인 컴포넌트로 세분화 한다고 하더라도 예상하지 못한 문제를 얼마든지 마주할 수 있기 때문입니다. 관련해서 또 다른 좋은 글을 소개합니다.

• asset 최적화

  • 이미지, 자바스크립트, CSS, 폰트 및 아이콘, 비디오 및 오디오, 문서, 퍼포먼스 측정

  • 각 세부 내용은 자세한 내용을 다루고 있진 않습니다. 다만 어떤 자산에 대해 어떻게 최적화를 하면 좋은지 소개하고 자산의 종류에 어떤게 있는지 안내하는 것만으로도 큰 가치가 있습니다. 프론트엔드 사이드에서 최적화를 할 수 있는 범위가 어디까지인지 거시적으로 파악하는데 도움이 됩니다.

• 각 수준의 캐싱

  • 브라우저, CDN, DNS, 애플리케이션 수준의 캐싱에 대해 소개합니다.

  • 이 역히 자산 최적화와 비슷합니다.

• 낙관적 동시성

  • 낙관적 UI 업데이트에 대해 소개합니다. 또한 서버 요청으로부터 에러를 받았을 때 어떻게 재조정하는지 안내합니다.

  • 또한 문서 수정에 낙관적 UI를 적용하기 위해 프론트엔드에서 문서 버저닝을 하는 방법도 간단하게 소개합니다.

  • 낙관적 동시성과 관련해 이전 글을 다시 보는 것도 도움이 될거 같습니다.