감사합니다 :)

주니어 때는 주어진 요구사항을 잘 구현하는 것에 집중했지만, 경력이 쌓이면서 기술적 의사결정을 주도하는 역할을 맡게 되었습니다. 단순히 '이렇게 하면 된다'는 방식을 넘어, '왜' 그렇게 해야 하는지에 대한 논리적 근거를 명확히 제시해야 할 필요성을 느꼈습니다. 저는 이 과정에서 제가 가진 지식의 기반이 흔들리고 있음을 깨달았고, 이러한 기술적 리더십 역량을 강화하기 위해 컴퓨터 과학의 이론적 배경을 다시 배우기로 결심했습니다.

이를 통해 저는 단순한 코드 작성을 넘어, 팀을 설득하고 최적의 아키텍처를 설계하는 데 필수적인 지식을 갖추고자 했습니다. 그리고 이러한 목표에 가장 적합한 교육을 제공하는 인하대학교 소프트웨어융합공학과 를 선택하게 되었습니다.

입학 생활

1학기 시작 전, 신입생 오리엔테이션을 시작으로 대학 생활을 시작했습니다. 1학기에는 '문제해결을 위한 글쓰기', 'Python을 활용한 데이터 다루기', 그리고 '일반 수학'을 수강했습니다. 오랜만에 수학 문제를 다시 풀었지만, 정승제 선생님의 '50일 수학'을 통해 기본 개념을 다진 덕분에 수업을 더 수월하게 따라갈 수 있었습니다. 온라인 수업이 많았던 1학기에는 아침 6시에 기상하여 강의를 듣고, 퇴근 후 남은 과제를 처리하는 루틴을 만들며 학업을 병행했습니다.

방학 동안에는 2학기 수업 준비와 자격증 취득에 도전했습니다. 정보처리기사 실기 시험과 SQLD 시험에서 아쉽게도 한 문제 차이로 불합격했지만, 비록 합격하지 못했더라도 실무에서 당연하게 사용하던 데이터베이스의 정규화, 인덱싱 개념이나 운영체제와 네트워크 이론을 체계적으로 정리할 수 있는 좋은 기회였습니다. 이 경험을 바탕으로 부족한 부분을 보완하여 다음 시험에 다시 도전할 계획입니다.

현재 2학기에는 1학기보다 심화된 수학, 영어, 알고리즘, 객체지향 프로그래밍 과목을 수강 중입니다. 수학은 미적분, 벡터와 행렬, 확률과 통계 등을 배우며 Python 프로그래밍 실습을 병행하고 있습니다. 영어는 원어민 회화 수업을 듣고 있습니다. 처음에는 어려움이 있었지만, 주 2회 개인 보충 수업을 통해 완벽한 문장이 아니더라도 주저 없이 소통을 시도하는 자신감을 얻었습니다. 이를 통해 기술 문서를 더 원활하게 읽고, 글로벌 커뮤니티에도 참여하는 것을 목표로 하고 있습니다.

특히 알고리즘 수업은 고등학교 때 배웠던 자료구조를 다시 접하는 기회입니다. 당시에는 문제를 푸는 것에 집중했다면, 지금은 시간 복잡도와 공간 복잡도를 고려하며 실제 서비스의 성능을 어떻게 최적화할지 고민하고 있습니다. 수업 내용을 바탕으로 개념을 스스로 설명하고, 알고리즘적 사고를 적용해 문제를 해결하는 과정을 블로그에 기록하며 꾸준히 학습할 계획입니다.

앞으로의 계획

저는 이론적 지식과 실무 경험을 결합해 현재 맡은 서비스의 성능을 최적화하고, 확장 가능한 아키텍처를 설계하는 개발자가 되고 싶습니다.

또한, 영어 의사소통 능력을 키우고 관련 자격증도 취득할 계획입니다. 이를 통해 최신 기술 트렌드와 해외 기술 문서를 빠르게 습득하고, 글로벌 개발자 커뮤니티에서도 적극적으로 소통하며 지식의 폭을 넓히고자 합니다.

아울러, 기초 수학을 넘어 선형대수학과 통계학을 심화 학습하여 데이터 분석이나 AI/머신러닝 등 미래 기술에 대한 기반을 다지고, 프론트엔드와 융합할 수 있는 새로운 도메인을 개척하고 싶습니다.

바쁜 일상이지만, 학업을 통해 얻는 지식과 에너지는 저를 더욱 몰입할 수 있는 개발자로 만들고 있습니다. 앞으로도 이론과 실무의 시너지를 바탕으로 회사의 기술적 발전에 기여하고, 장기적으로 꾸준히 성장하는 개발자가 되겠습니다.

"이벤트 버블링과 캡처링의 차이는 뭔가요?"

2. 답변하기

[질문에 대한 답]

"이벤트가 발생하면 기본적으로 이벤트 전파가 일어나는데 이벤트 전파 방향에 따라서 이벤트 버블링이냐, 이벤트 캡처링이냐고 결정 됩니다."

• 이벤트 버블링은 거품이 아래에서 위로 올라온다는 것을 비유해 자식 -> 부모로 올라가는 이벤트 전파 방향을 의미 합니다.
• 이벤트 캡쳐링은 버블링의 반대로 위에서 아래로 내려온다는 것을 의미 합니다.그래서 부모 -> 자식으로 이벤트가 전파 되는 방향을 의미 합니다.
• 브라우저는 기본이 이벤트 버블링이 발생합니다. 이를 설정하는 방법은 이벤트를 등록할때 3번째 인자로 options를 설정하는데 그 부분을 설정하면 이벤트 전파 방향을 정할 수 있습니다.

[스스로 질문의 범위 확장해보기]

• 이벤트를 막을 수 있는 방법에는 preventDefault()와 stopPropogate()가 있습니다. 둘의 차이는 preventDefault는 이벤트 기본동작을 막는것이고, stopPropogate는 이벤트 전파를 막는것 입니다.

• 이벤트를 체크하는 방법에는 e.target과 e.currentTarget이 있습니다. target은 최초로 이벤트가 발생한 요소이고, currentTarget은 지금 현재 이벤트의 요소 입니다.
• 이벤트를 등록하는 것은 굉장히 많은 메모리를 잡아먹습니다. 그래서 상위요소에만 이벤트를 등록하고, 하위 요소에서 이벤트가 발생하면 이벤트 전파로 이를 처리하면 적은 메모리로 이벤트를 처리할 수 있습니다.
• css중에 이벤트전파를 막는 클릭 이벤트를 발생시키지 않은 css가 있습니다. pointer-events: none

3. 답변부분 교정하기 & 새롭게 알게 된 사실

1) css의 pointer-events: none은 '이벤트 전파'를 막는다보다는 해당 요소가 마우스 이벤트의 대상이 되지 않게 합니다. 또 이로 인해 이벤트 전파가 막아지는것은 아니며, 이벤트 버블링은 여전히 발생합니다.

2가지 케이스에 대해서 살펴보겠습니다.

1) 클릭해도 아무일도 안일어남 => div가 이벤트를 차단해서 button까지 이벤트가 도달되지 않음

<div style="pointer-events: none;">
  <button onclick="alert('clicked')">버튼</button>
</div>

2) button에서 이벤트가 발생할 수 있기 때문에 alert()이 동작하고, 버블링도 발생합니다. 하지만 div 요소는 pointer-events:none 이기 때문에 제외되고 버블링이 발생합니다.

<div style="pointer-events: none;">
  <button style="pointer-events: auto;" onclick="alert('clicked')">버튼</button>
</div>

1. 기본동작(Default Behavior) 이벤트 정리해보기

2. 합성이벤트 (Synthetic Event)

• Synthetic Event는 React가 브라우저의 일관성과 메모리 향상(절약)을 위해서 만든 이벤트 시스템입니다.

  1) 실제로 React는 기본 이벤트를 랩핑해서 이를 일관된 형태의 구조로 제공합니다. 그래서 event 타입을 찍어보면, 'SyntheticEvent'라고 보입니다. 2) React는 이벤트 등록을 document에 딱 1번만 등록하여 이벤트 위임하는 형태로 이벤트를 처리 하기 때문에 메모리 부분에서 좋다고 볼 수 있습니다.

3. Event Pooling

" 이벤트 객체(SyntheticEvent)를 재사용하는 기법 "

이렇게 된다면.. 발생할 수 있는 문제점?

이벤트 핸들러 안에서 비동기 코드나 setTimeout, Promise.then 등에서 SyntheticEvent 객체를 사용하려고 하면 ❗이미 초기화돼서 접근이 안됨.

function App() {
  const handleClick = (e) => {
    setTimeout(() => {
      console.log(e.type); // ❌ 여기서 오류가 날 수 있음! e는 이미 null 처리됨
    }, 100);
  };

  return <button onClick={handleClick}>Click me</button>;
}

이와 같이 하는 이유는 이벤트가 발생할때마다 새로운 이벤트를 생성하는데 이벤트가 메모리를 많이 잡아 먹음. 그래서 SyntheticEvent 초기화해서 다시 계속 재사용하는 방향으로 메모리 효율을 향상시킵니다. 하지만, React 17부터는 event pooling 방식을 사용하지 않습니다.

4. 최신 지식 습득하기 (React 19+)

• 이벤트 핸들러의 경우에는 컴포넌트가 다시 렌더링 될때마다 새로 만들어진다. 또 비동기 함수를 사용하면 stale closure문제를 만들 수 있다.

• 그래서 컴포넌트내에서 간단하게 이벤트를 처리하는게 아니라면, useCallback으로 감싸서 stale 클로져 문제가 발생하지 않도록 하는 것이 좋다.

• 예전에는 useCallback 대신 useEvent로 해서 항상 최신상태의 event 정보를 가져오는 hook이 제공될거라고 했는데, 현재 React 19 공식문서에는 없다.

• visibility: hidden과 opacity : 0은 모두 해당 요소가 화면에 렌더링되지만 투명하게 보이게끔 만들어준다. 하지만, 둘다 여전히 자리를 차지한다.
• 둘의 차이점이라면 visibility:hidden은 뒤에 있는 요소를 클릭할 수 있지만, opacity: 0은 불가능하다는 것.*

2. display:none

2) display: none은 해당 요소를 DOM 트리까지만 가져오고 렌더트리에서는 제외해준다. 즉, 레이아웃에 포함되지 않는다. 그래서 해당 요소가 자리조차 차지하지 않게 된다. 하지만, DOM 트리까지 해당 요소를 가져가야 하기 때문에, 해당 요소, 예를 들면 컴포넌트를 생성하기 위해 필요한 계산 과정은 전부 거쳐야 한다. *즉, 리렌더링에 따른 자원소모는 피하지 못하는 방법이라는 뜻이다. *

3. 결론

=> 그래서 사실 최적화 측면에서 가장 적합한 방법은 조건부 렌더링이다. 조건부 렌더링을 사용하명 condition에 해당하지 않을때는 아예 렌더링을 하지 않기 때문에 해당 컴포넌트를 생성하는 계산자체가 필요없게 된다.

4. 추가 설명

• 렌더 트리란, CSSOM과 DOM이 결합된 것을 말한다. 이 렌더 트리는 표시되는 각 요소의 레이아웃을 계산하는데 사용되고 픽셀을 화면에 렌더링하는 페인트 프로세스에 대한 입력으로 작동합니다. 최적의 렌더링 성능을 얻기 위해서는 이러한 각 단계를 최적화하는 것이 중요하다.
• 렌더트리는 페이지를 렌더링하는데 필요한 노드만 포함합니다.
• 단, display:none은 렌더트리에 포함되지 않는다. (visibility는 빈상자로 렌더링됨)
• 렌더트리가 준비되면 '레이아웃' 단계를 진행할 수 있다.

[참고자료]

https://iborymagic.tistory.com/116 https://web.dev/articles/critical-rendering-path/render-tree-construction?hl=ko

• if-match 헤더를 이해하기 위해서 "ETag 해더"를 먼저 이해하는 것이 좋다.

2. ETag 해더란?

• ETag 해더는 웹서버가 제공하는 컨텐츠들에 각각 부여되는 일종의 식별자 같은 정보이다. (ETag 정보를 표기한다)
• 사람에게 지문 또는 주민 등록 번호와 같이 개개인을 구별할 수 있는 정보가 있는 것 같이 ETage도 그런것이다.
• 웹서버는 클라이언트에서 컨텐츠를 제공할때 ETag 정보도 같이 전달한다. 클라이언트와 프록시서버들은 이 정보를 다음요청(subsequent request)에 사용한다.

사용예시)

1) PUT URI IF-Match : AABB : "If-Match: AABB"라는 헤더를 포함한 PUT(변경) 요청을 보낸다. 2) 서버는 200 OK, Etag는 CCDD 라고 응답해준다. 3) 다른 클라이언트가 이 사실을 모르고, PUT URI IF-Match : AABB라고 요청을 보냈다. 4) 서버는 ETag AABB가 존재하지 않는다고 412 Precondition(전제조건) Failed를 응답한다.

추가적으로, If-Match에 *를 사용하면, 서버가 가지고 있는 ETag 정보와 상관없이 요청을 처리한다.(조금더 정확하게는 컨텐츠의 내용은 모르겠고, 파일이 존재하기만 한다면 요청을 처리해줘라는 뜻이다)

3. If-Modified-Since

• If-Modified-Since 해더를 이해하기 위해서는 Last-Modifined 헤더의 의미를 먼저 알아야 한다. Last-Modifined 헤더는 컨텐츠가 마지막으로 수정된 시간을 나타낸다.

[최초 요청 예시]

1) GET URL 프록시 서버에 요청 2) origin 서버에 GET URL 요청 3) origin 서버는 200 OK, Last-Modified: Fri, 31 Jul 2017 07:00:00 GMT 라고 응답한다. 4) 프록시 서버는 자신의 디스크나 RAM에 저장한 후 클라이언트에게 응답한다.

[두번째 요청 예시]

1) GET URL 프록시 서버에 요청 2) 프록시 서버는 origin 에게 GET URL 요청 if-modified-since: Fri, 31 Jul 2017 07:00:00 GMT라고 요청한다. 3) origin 서버는 동일한 컨텐츠임을 확인하고 변경된 바가 없으니 직접 제공하라는 메시지인 304 Not Modified를 응답한다. 4) 프록시 서버는 자신의 디스크나 RAM에 저장한 후 클라이언트에게 응답한다.

• If-Modified-Since 헤더는 캐시동작에 있어서 유효한 컨텐츠를 클라이언트에게 제공할 수 있게 해주는 중요한 정보이다.

만약, If-Modified-Since 정보에 오류가 있는 경우에는 어떻게 될까? 잘못된 경우라면 형식이 잘못되었다던지, 서버의 현재시간보다 더 늦은 경우라던지, 이런 경우에 웹서버는 If-Modified-Since 정보를 무시하고 , 컨텐츠 전체를 서비스하게 된다.

4. IF-None-Match

• If-Match 헤더와 반대의 의미라고 이해하면 된다.
• 결국, IF-Match, IF-None-Match 헤더는 서버가 제공하는 컨텐츠의 변경 여부를 확인하기 위해서 사용되는 해더이다.
  • IF-Match : 컨텐츠가 변경되지 않고 같다면...
  • IF-None-Match : 컨텐츠가 변경되었다면...
• if-match는 200또는 412 전제조건이 잘못되었다는 응답을 리턴한다.
• if-none-matc는 200 또는 304 Not Modified를 리턴한다.

[참고자료] https://withbundo.blogspot.com/2017/07/http-13-http-iii-if-match-if-modified.html

• 어떤 데이터를 한 번 받아온 후에 그 데이터를 불러온 저장소보다 가까운 곳에 임시로 저장하여, 필요시 더 빠르게 불러와서 사용하는 프로세스를 의미한다.
• 엔지니어 입장에서는 재사용을 충분히 많이 할 수 있는 데이터만 선별적으로 캐싱하여, 성능과 비용을 아끼는 것이 중요하다.

2. 브라우저 캐시(HTTP 캐시, 웹 캐시)란?

• 브라우저나 HTTP요청을 하는 클라이언트 애플리케이션의 의해 내부 디스크에 이루어지는 캐시이며, HTTP 캐시라고도 불린다.
• 이러한 캐시는 단일 사용자를 대상으로 하는 사설 캐시(Private Cache)이며, 해당 사용자의 정보만을 저장한다.
• 브라우저에서 캐싱을 처리하는 속성에는 대포적으로 ETag, Cache-Conrol이 있다.

3. Cache-Control

• Cache-Control은 HTTP/1.1의 헤더로, 캐시에 대한 동작을 지정한다.
• 캐시의 유효 시간(생명주기)와 관련된 내용을 명시하는 헤더이다.

1) no-Cache

• request 해더 : 캐싱된 응답값을 받지 않고, 원 서버로부터 응답을 받겠다.
• response 해더 : 캐싱된 데이터를 항상 유효한지 확인하도록 하겠다. 캐싱을 하긴 하지만, 원본 서버에는 항상 갔다 오겠다(실제로 아무 캐시를 지정하지 않으려면 no-store로 설정해주어야 한다)

2) no-Store

• request, response 모두 동일하게 캐시를 사용하지 않겠다라는 의미로 사용한다.
• no-store는 로컬에 저장하는 것 자체를 금지한다.
• 데이터에 민감한 정보가 포함되어 있어 저장 불가 하도록 처리할때 사용한다.

3) max-age

• 캐시 유효시간, 초 단위 설정
• Max-age=60 : 60초 동안 캐시를 유지하겠다는 의미이다.
• 다만, Max-age 60초가 지났다고 해서 해당 리소스에 대한 캐시를 완전히 버리지 않는다. 서버에 한번 물어보고(조건부 요청), 리소스 변경이 없다면 해당 캐싱된 리소스를 그대로 사용한다.
• 흔히, 캐싱되지 않아야 하는 민감한 리소스에 대해서는 max-age=0을 사용한다.

4) age

• Origin server의 응답이 프록시 캐시 서버에 머문 시간, 초 단위(sec)

5) expire

• max-age는 유효시간을 초단위로 설정하였지만, expire는 만료일자를 지정한다.
• cache-control 해더에도 Max-age로 유효시간을 명시하는 것이 더 추천되기 때문에, 현재는 사용이 권장되지 않고 하위호한을 위해 사용한다.
  • 만약, max-age와 동시에 사용되면 expire는 무시된다.

6) public

• 응답 헤더에 사용할 수 있다.
• 모든 캐시 서버에 캐시 될 수 있고 사용자 제한 없이 모든 사용자에게 응답이 전달 될 수 있다.

7) private

• public 캐시에 저장불가
• 최종 사용자 개인의 브라우저 환경에서만 캐싱하고, 외부 캐시 서버(CDN등의 범용캐시 서버)에서는 캐싱할 수 없다. ex) 로그인을 해서 내정보가 들어있는 페이지 접근지, 내 브라우저가 아닌 만약 다른 외부서버에까지 내정보가 캐싱되는 경우를 방지해준다. 응답 메시지를 어디에 캐시할 것인지를 지정하지 위해서 사용할 뿐, 그 자체로 개인정보를 보호하는 장치가 되지는 않는다.

8) s-maxage

• 공유 캐시에 해당하는 캐시에만 적용되는 수명이며, 개인 캐시에서는 무시된디ㅏ.
• 헤더의 age필드와 비교해서 캐시의 유효성을 판단한다.

9) must-revalidate, proxy-revalidate

• must-revalidate : 캐시 만료 후 최초 조회 시 origin server에 검증
• proxy-revalidate : 위의 내용을 공유(public)캐시에만 적용한다.

10) ETag

• HTTP 응답 해더로 리소스의 특정버전에 대한 식별자라고 하며, 원본 서버가 리소스를 식별하기 위해 부여하는 고유번호이다.
• ETag는 캐시 유효성 검사를 위해 사용되며, 캐시된 리소스가 원본 리소스와 일치하는지 확인하는데 사용된다.

11) Pragma

• HTTP/1.0 하위 호환성을 위해 사용되는 헤더로, 캐시 제어를 위해 사용된다.
• 권장하지 않는다.

4. 크롬 브라우저를 기준으로 웹 브라우저는 크게 2가지 방법으로 캐싱을 한다. (브라우저 자체 알고리즘에 따름)

1) 메모리캐시 : RAM에 데이터를 저장해놓는 방식 2) 디스크 캐시 : 하드 디스크에 파일로 저장해놓고 파일을 읽어서 저장하는 방식

• 디스크 캐시보다는 메모리 캐시가 더 빠르다. 디스크 캐시는 하드디스크에 접근하는 시간을 개선하기 위해 RAM에서 가져오며, 메모리 캐시는 더 빨리 가져오기 위해 RAM에 접근하지 않고, CPU 칩안에 있는 (L1, L2, L3) 캐시 메모리에 저장한다.

캐시의 유효기간의 지난 후 재접속하는 경우에는 status가 200이 아니라 304(Not Modified)로 응답한다.

5. 캐시 무효화에 대한 전략

방법1) cache-control: no-cache, Cache-Control: max-age=0 (0초 동안 캐시)

• no-cache 옵션을 사용했다고 해서, 캐시가 사용되지 않는 것이 아니다!!!
• 캐시해도 되지만, 항상 origin server검증하고 사용해야한다.
• 서버로 부터 304 응답을 받으면 캐시를 사용한다.

방법2) cache-control: no-store

• no-store는 캐시를 사용하지 않겠다는 의미이다.
• no-cache, max-age보다 엄격하게 캐시를 완전히 비활성화 한다.

방법3) cache-control: must-revalidate

• 캐시 만료 전에는 캐시를 사용하며, 캐시가 만료된 후에는 원서버에 검증을 요청한다.

방법4) pragma:no-cache

• 해당 방법은 HTTP 1.0 하위호환을 위해 사용한다.

[참고자료]

• https://goddaehee.tistory.com/325
• https://yozm.wishket.com/magazine/detail/2341/
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control

1. 서비스 안전성

• 우리는 현재 리소스가 부족하여 검수를 할 수 있는 상황이 아니였다. 하지만 1주 단위의 빠른 배포가 필요했다. 안전성을 확보하고자 테스팅툴을 알아보고 있었다.

2. 디자인 시스템 의사결정 퀄리티 향상

• AS-IS는 디자이너 한명이 의사결정을 하는 구조로 이루어졌다. 나는 디자인 시스템에 참여하는 진입장벽을 낮추고 의사결정의 퀄리티를 높이고 싶었다.

3. 공유에 대한 누락사항 및 의사전달 비용 절감

• 현재는 글로만, 어떻게 변경되었는지를 전달하고 있다. 하지만, chromatic을 이용하면 시각적으로 어떤 부분이 달라졌는지를 정확하게 전달 할 수 있었다. (무려 픽셀이 어떻게 달려졌는지까지도..)

2. chromatic 시작하기

1) https://www.chromatic.com/ 계정을 생성하세요

2) git을 연동하세요 3) 프로젝트에 chromatic을 설치하세요 4) chromatic 명령어를 실행하세요

3. 우리팀은 chromatic 도입 적응기를 다음과 같이 가졌어요

1) chromatic에 대해서 도입 방향에 대해서 팀내에서 발표 및 회의를 진행했어요 2) 그리고 약 1달의 도입 기간을 갖기고 하여 디자인 검수를 chromatic으로 진행하였습니다 3) 하지만 적용 당시에 어려움이 생겼습니다

4. chromatic 적용의 어려움(디자인팀 VS 개발팀(FE))

(1) chromatic으로 테스트를 진행하려면, 컴포넌트를 테스트할 수 있는 story가 구현되어 있어야 했는데, story가 기존에 등록되어 있지 않아 변경사항이 모두 'new'로 잡혀 변경된 부분만 잡아내지 못하는 상황 => chromatic에 대한 story 작업을 push하고 컴포넌트 변경사항을 분리해서 chromatic에 변경사항에 변경사항만 잡히도록 브랜치를 관리 할 것.

(2) 디자이너가 생각하는 story와 개발자가 말하는 story가 다름. => 디자이너가 생각하는 story는 figma에 정의된 케이스만 작성되어야 함. 개발자가 생각하는 story는 "테스트 케이스" 테스트 케이스는 디자인에서 정의해준 외의 것들을 필요에 의해서 테스트를 생성할 수 있음. "외의 것들"에 대해서 디자이너나 다른 기획자들이 보고 혼동할 수 있기 때문에 개발자의 테스트 케이스와 디자이너가 정의해준 예시를 구분해서 작성할 것.

(3) 디자이너는 결국 stroybook에서 개발자도구를 이용해 검수를 진행 함. chromatic에서 어떻게 검수해야 되는지 1개월의 도입기를 거쳤지만, 불편하고 디자인 업무의 프로세스와는 맞지 않다고 생각하심. => chromatic은 마치 개발자 입장에서 PR을 날리는 구조로 되어 있음, 개발자 입장에서 PR은 이미 존재하는 개념이고, 프로세스 상의 이질감이 크게 없음, 하지만 디자인의 입장에서 storybook에서 검수를 진행하고, jira에 댓글만 달면 끝나는 일인데, chromatic의 새로운 툴이 또 도입되어 chromatic도 봐야하고, storybook도 봐야하고, jira도 봐야 하는 이슈가 발생함

5. 그렇다고, chroamtic이 갖는 장점이 있는데 버릴만 한가?

1) 안전성.. 2) 공유방법 개선.. 3) 히스토리 관리.. 4) 디자인 시스템 규모 확장 가능성..

6. 그래서 우리팀은 이렇게 결론 내렸어요

결론은 디자인팀은 "chromatic 도입 반대" 입니다. 하지만, 장점이 많으니 개발팀에서 내부적으로는 사용해도 좋다 였습니다.

하지만.. 돌릴 때 마다 발생하는 비용지원에 말씀은 없으셨다.

결국 chromatic도입은 이렇게 흐지부지 되어 버렸다.

7. 그 후 나의 도전기

• 비용이 너무 비싸서 시각적 회귀테스트를 간단하게 직접 구현해보았습니다.
• 라이브러리는 Puppeteer를 사용했고, 목표는 총 3가지로 하였습니다. 1) figma하고 비교해서 차이가 있는지 => 단순 페이지 비교 2) 이전 버전하고 비교해서 차이가 있는지 => 단순 페이지 비교 3) 액션을 통한 화면 비교(button 클릭 후 결과페이지 비교)

작성중인 페이지 입니다 :)

GitHub : https://github.com/min-99/react-boilerplate

1. Node를 설치하세요

• React는 Node.js기반입니다. Nodes.js가 없으면 React가 실행될 수 없어요.
• https://nodejs.org/en 홈페이지에 접속하여 LTS버전을 설치해주세요.

node --version // v20.11.1 - 버전이 뜨면 설치 성공

2. yarn berry 설치하기

• 필수는 아니지만 npm보다 yarn의 속도가 빠르기 때문에 깔아주는 것이 좋습니다
• mac은 home brew설치 후 다운로드 진행
  • hone brew : https://brew.sh/
  • yarn : https://classic.yarnpkg.com/en/docs/install/#mac-stable

yarn --version // - 버전이 뜨면 설치 성공

brew upgrade yarn // 업데이트 

• yarn berry : https://velog.io/@min_99/%ED%8C%A8%ED%82%A4%EC%A7%80-%EB%A7%A4%EB%8B%88%EC%A0%B8-%EC%A0%95%EB%A6%AC-2%ED%8E%B8yarn-berry

3. 리액트 프로젝트 생성 + typescript 적용

1) 작업을 진행할 폴더로 이동하세요

cd {작업을 진행할 폴더}

2) 프로젝트 생성

 npx create-react-app {프로젝트 이름} --template typescript

3) tsconfig 파일 세팅

// tsconfig.ts 파일
"compilerOptions": {
  "target": "ES6", // es6로 변환되도록 설정
    ...
}

4) 프로젝트 실행시켜보기

yarn start

4. ESLint 적용하기

• 보푸라기, 먼지 같은 것을 린트(Lint)라고 부른는데 이런 것들을 제거하는 기능
• create react app으로 만든 프로젝트에는 이미 eslint 기능이 내장 되어 있습니다. 더 편리하게 사용하기 위해서 ESLint 확장팩을 사용하세요.

1) ESLint 확장팩을 설치하세요 (https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint)

2) 저장할때 자동으로 수정되는 모드를 사용하세요(in VSCode) code > preferences > settings 로가서 환경설정 화면으로 간 다음 auto fix on save 검색 후 on 설정

5. Prettier 적용하기

• 코드 포맷팅에 좀 더 초점을 맞춘 기능
• ESLint의 역할 중 포맷팅과 겹피는 부분이 있지만, prettier는 좀 더 많고 일관적인 스타일로 코드를 다듬습니다.
• eslint와 달리 코드 품질과 관련된 기능은 하지 않습니다.
• eslint와 prettier를 둘다 사용하게 되면 충돌이 나게 되어 eslint 규칙을 끄는 것이 필요합니다.

How? 어떻게 꺼요?

• ESLint와 통합 방법을 제공하는 eslint-config-prettier를 설치합니다.

yarn add eslint-config-prettier

// package.json extends 부분에 prettier를 추가합니다.

"eslintConfig": {
    ...
    "extends": [
      ...
      "prettier"
    ],
  },

ESLint는 중복된 포매팅 규칙을 프리티어에게 맡기고 코드 품질에 관한 검사만 하게됩니다.

6. Styled-component 적용하기

• css in js 관련 라이브러리
• 즉, js파일에서 css를 작성하는 것입니다.
• js 파일에서 css를 작성할 수 있고 이를 바로 컴포넌트화 시킬수도 있게됩니다.

yarn add styled-components
yarn add @types/styled-components

// eslint, prettier 잘동작하는지, 충돌 안나는지 확인 할 것 // .husky도 적용할 것

1. 레거시 시스템에 대한 문제(=내가 해결하고 싶었던 문제)

제가 관리하는 서비스는 페이지 구성이 굉장히 복잡한 서비스 였습니다.

얼마나 복잡한데요?

• admin에서 구성한 데이터로 UI를 구성하고, 구성한 UI를 클릭할때 마다 아래의 UI가 바뀌어야 하는 페이지 였습니다. 한마디로 데이터 의존성이 굉장히 높은 페이지 였습니다.

또, 페이지를 제어하는 javascsript 로직은 모두 하나의 객체에 담겨 있었고, 무엇인가를 수정해야 한다면, 그 컴포넌트를 건드리고, 참조하는 로직이 사방곳곳에 정의되어 있어 배포시 사이드 이펙트가 자주 발생하였습니다.

javascript도 수정이 어려웠지만, css구조도 인라인 스타일, html 내부의 css, css파일에 있는 디자인 정의가 혼합되어 있었습니다. 또 서로 관계없는 컴포넌트인데 UI가 비슷하다는 이유로 같은 클래스를 공유하여 디자인 수정도 쉽지 않았습니다.

2. 그러면 왜 React인데요?

위의 문제를 해결하기 위해서는 React의 코드 스타일과 동작방식, 저희 서비스의 적합성 부분에서 React가 더 이득이라고 생각했습니다.

1. React는 선언형 코드 스타일이기 때문에 가독성이 좋아집니다.

=> 기존에는 들여쓰기와 닫는 태그도 정상적으로 되어 있지 않는 html을 분석해야 했다면, React의 컴포넌트 설계와 선언형 스타일로 코드 파악에 유리하다고 생각합니다.

2. 컴포넌트를 재사용할 수 있습니다.

=> 그때 당시 같은 컴포넌트가 많았는데 이를 컴포넌트화 하고 싶었습니다.

3. DOM을 직접건드려야 하는 일이 줄어 듭니다.

=> 기존에는 직접 dom에 접근하여 변경해야 됬고, 이 로직이 사방 곳곳에 있었다면 이제는 데이터의 변경하는 곳을 한곳으로 정리할 수 있고, 변경하는 곳은 액션의 네이밍으로 쉽게 찾을 수 있습니다.

[React외의 추가적인 리펙토링 방향 및 추천사항]

4. typescript 사용

• javascript만 사용할 경우보다 타입을 강제하기 때문에, 타입때문에 발생하는 이슈사항들을 사전에 많이 잡을 수 있습니다.

5. css 작업방식 개선

• styled-component 라이브러리를 사용하여 컴포넌트자체에 css를 같이 정의하는 방향으로 기존의 다양한 css 선언방식을 통일하고 클래스가 겹치는 등에 대한 이슈사항이 없습니다.

6. 패키지 매니져 사용

• 기존에는 CDN방식으로 라이브러리를 가져다 사용하고 있었는데, 패키지 매니져를 사용함으로서 버전관리에 용이하고 안전성측면에서도 향상 됩니다.

7. 테스트 용이

• 기존에는 php, css, javascript가 모두 섞여 있어서 TEST가 필요한 결제 페이지에서 테스트를 돌리기가 어려웠습니다. 결제부분에 서비스 핵심로직이 모두 다 있기때문에 안정성을 향상 시키려면 개선이 필요했습니다.

8. 제가 서비스하는 모듈은 Client 모듈에 가까웠습니다.

• php에 javascript로 구성되어 있었지만,javasciprt는 AJAX로 자기에게 요청을하고 php는 실제 API 서버로 API요청하고 데이터를 넘겨주는 역할만 하고 있었습니다.

그때 당시, 제가 담당하고 있는 모듈은 추가 기능 개발이 필요했고, 고객을 더 받기 위해서는 서비스 안전성과 성능 개선이 필요하였습니다. (lighthouse 기준으로 PC가 평균 40점, Mobile이 평균 20점 정도 되는 성능을 가지고 있었습니다) 조금 더 안정적으로 서비스를 개선하기 위해서는 해당 개선 작업이 필요하다고 느껴 담당자로서 왜 필요한지에 대해서 리더분에게 PPT 발표를 진행하였습니다

이후, TF팀을 결성하여 1차와 2차로 나눠 리팩토링 작업과 프로토타입 개발을 진행했습니다. 그 결과, Lighthouse 기준으로 PC 평균 점수는 40점에서 88점으로 향상되어 48점 상승했으며, Mobile 평균 점수는 20점에서 78점으로 향상되어 58점 상승하는 개선 효과를 보였습니다. 또한, 제시된 개선 사항을 반영하여 최종적으로 모든 항목이 90점 이상으로 개선되었습니다.

1. span과 div를 명확하게 설명할 수 있다.
2. inline과 inline-block 요소를 명확하게 설명할 수 있다.

1. <span>과 <div> 차이

• div 태그는 의믜적으로 관계가 없을 때 주로 사용한다. 오직 내용을 묶는 역할이라고 보면 된다. 하지만, span 태그와 비슷한 역할을 하는데 차이가 있다.

무슨 차이?

• div는 줄바꿈 되지만, span 태그는 옆으로 붙는다.
• 즉, div는 기본적으로 block요소, span은 inline 요소이다.
• 그렇기 때문에 텍스트를 표현할때 div는 사각형 박스 구역으로 공간을 차지하지만, span은 문장 단위로 지정한다.
• 노란색 : div
• 민트색 : span

2. inline과 inline-block 비슷한거 아닌가요?

• inline 요소는 대표적으로 <span>
• block 요소는 대표적으로 <div>

1) inline

• width, height 적용불가

• margin, padding-top, padding-bottom 적용불가

• *line-height는 원하는 대로 적용불가 *

• 요소 : span, a, br, em, strong, input, label, img

  ** <span>태그는 text내에 특정 부분에만 스타일을 간단히 주고 싶을 때 주로 사용한다. **

2) block

• block은 무조건 한줄을 점유하고, 다음 태그는 다음줄로 넘어간다.
• verical-align 적용불가
• text-align 적용불가
• 요소 : div, table, h1 ~ h6, p, form, ul, li, ol, dl, dt, dd, pre, blockquote

3) inline-block

• inline + block이 섞인 형태, 같은 라인에 여러 태그를 붙일 때 주로 사용한다.
• inline의 단점을 커버하는 것이 inline-block이라고도 볼 수 있다.
• width, height 적용가능
• margin, padding-top, padding-bottom 적용가능
• line-height는 원하는 대로 적용가능

코드를 짜면서 기억하면 좋은 점

• 블럭요소내부에는 블럭요소와 인라인 요소를 포함 할 수 있다.
• 인라인 요소 내부에는 블럭요소를 포함 할 수 없다. => 이는 보여지는데는 아무런 문제가 없지만, 유효성에 어긋난다.

코드리뷰를 하면서 span태그안에 블럭요소를 넣고, 위치를 지정하는 코드를 보면서 잘못되었다는 것은 알았는데 명확하게 설명할 수가 없어서 답답했다. 설명할 수 없다는 건 정확하게 모른다는 것! 너무 오래전에 배워서 정말 당연하다고 생각했던 것 같다. 정리를 기록하면서 이러한 부분들이 많이 매꿔지길 바란다👍🏻

[참고자료] https://sdsupport.cafe24.com/reference/html/block-inline.html https://mainia.tistory.com/3289 https://blog.naver.com/leesd88/220682157303

• yarn berry는 yarn v2이상을 부르는 명칭입니다.
• 이에 따라서 기존의 yarn v1은 yarn classic이라고 부르게 되었습니다.

[사용방법]

npm install -g yarn
yarn set version berry

2. Plug'n'Play

• 기존의 무거웠던 node_modules를 생성하지 않고 패키지들에 대한 정보를 .zip파일로 관리 합니다.
• 패키지 의존성 정보를 .zip 파일로 압축하여 .yarn/cache 폴더에 저장하고 의존성을 찾을 수 있는 정보를 .pnp.cjs파일에 기록합니다.
• .pnp.cjs는 의존성 트리를 중첩된 맵으로 표현하지 때문에 디스크 I/O없이도 패키지가 어떤 라이브러리에 의존하는지, 어디에 위치하는지를 바로 알수 있습니다.
• 따라서, 패키지의 위치를 정확히 알 수 있기 때문에 시간도 단축되고, 중복 설치도 방지 할 수 있습니다.

3. Zero Install

• yarn PnP는 의존성을 압축 파일로 관리하기 때문에 의존성의 용량이 작습니다.
• 예를 들어, 일반적인 node_modules는 1.2GB 크기이며 13만 5천개의 파일로 구성되어 있는 반편, yarn PnP의 의존성은 139MB크기의 2천개의 압축파일로 구성됩니다.
• 용량과 파일의 수가 적기 떄문에 의존성을 Git으로 관리 할 수 있습니다.
• 이처럼, yarn berry에서 의존성을 버전관리에 포함하는 것을 zero-install이라고 합니다
• zero-install을 사용하면, git-clone 이후 별도의 설치 필요없이 바로 사용할 수 있습니다.

  [Zero Install 장점]

  1) 새로 저장소를 복제하거나 브랜치를 바꾸었을 때 yarn install을 실행하지 않아도 됩니다. 2) CI에서 의존성을 설치하는 시간을 크게 절약할 수 있습니다. 3) 오프라인 캐시 기능으로 인터넷이 연결되지 않아도 패키지를 사용할 수 있습니다.

[참고자료]

https://toss.tech/article/node-modules-and-yarn-berry https://usage.tistory.com/147

1. 자바스크립트 런타임 환경인 노드(Nodes.js)의 패키지 매니져에 대해서 알아보자.
   2. 대표적인 패키지 매니져 npm , yarn, yarn berry에 대해서 알수 있다.

1. npm이 뭔가요?

• Node Package Manager로, Node의 기본 패키지 매니져 입니다.

• 이러한 패키지 매니져가 없다면, 저희는 github에 접속해서 소스코드를 다운로드 받아야 합니다. 또 버전 변경시에 다시 접속해서 소스코드를 재 다운로드를 받아서 재 업로드 해줘야 됩니다..ㅎ

• 패키지 매니져의 탄생으로 관리의 문제가 개선되었지만, 완벽한 방법이란 없는 것.. 사용하다 보니 문제점이 발견이 되고, 이로 인해, npm , yarn, yarn berry,, 이렇게 발전을 하게됩니다

npm! 무엇이 문제였나?

1. 😵 환경세팅하는 사람들마다 버전이 다 제각각이야!! (일관되지 않은 버전관리)

1) 시멘틱 버저닝

• 노드 모듈들은 기본적으로 시멘틱 버저닝 이라는 기법을 사용하여 모듈의 버전을 나타냅니다.
• 시멘틱 버저닝 : 1.0.0처럼 세가지 숫자로 구분하고 각 자리에 현재 버전이 이전버전과 어떤 관계가 있는지 암시하는 방법입니다.

2) 캐럿(^) 기호

• 캐럿 기호를 이용해서 첫번째 숫자를 제외한 두자리(마이너,패치) 버전까지는 변경을 허용

3) 버전 불일치 따라서, npm install 명령어로 모듈을 설치하면 최신버전을 다운받게 됩니다.

버전 변경이 허용되기 떄문에 모듈간의 버전이 일치하지 않는 문제가 발생할 수 있다.

2. 🥵 고정되지 않은 설치 순서

• 개발자의 환경에 따라 모듈들의 설치 순서가 변경 될 수 있다.
• 이미 만들어진 프로젝트에서 모듈을 추가로 설치하게 될 경우 npm install 명령어를 통해 처음부터 설치하는 사람과의 설치순서가 달라질 수 있다.

  npm은 개발자들이 어떤 순서로 모듈을 추가했는지 알 수 없기 때문에 모듈 이름을 사전순서대로 정렬하여 순차적으로 설치한다.

3. 🤬 순차적인 설치로 인한 긴 소요시간(너무 오래걸려!!)

• npm은 모듈을 한번에 하나씩 순차적으로 설치합니다. => 설치해야 되는 모듈이 많을수록 총 설치 시간이 길어지게 됩니다.

npm의 문제를 해결하여, yarn 출시!

1. 버전문제를 해결하다

• 버전고정을 위해 yarn.lock 파일을 사용한다.
• yarn.lock 파일로 개발자들의 항상 같은 버전의 모듈을 사용할 수 있도록 보장한다

[npm도 버전문제에 대한 개선방향을 내놓다!]

• npm shrinkwrap
• 하지만, npm의 경우 고정이 필요할 때마다 명령어를 입력해야 한다
• yarn의 경우, 의존성이 달라질때마다 lock파일을 자동으로 추가하기 때문에 편리합니다.

2. 설치 확인을 위한 checksum

• yarn은 checksum을 이용하여 패키지가 제대로 설치 되었는지 확인 합니다.
• yarn.lock 파일을 확인해보면 resolved 주소뒤에 해시값이 추가되어 있는데, 이 해쉬값이 바로 checksum 입니다.
• checksum은 패키지 파일의 무결성(정보가 변형되거나 손상되지 않았다)을 확인하는 안전장치 역할을 합니다.

3. 캐시를 통한 속도 개선

• yarn은 한번 다운로드한 패키지라면 캐시를 해두기 때문에 다음부터는 매우 빠른 속도로 설치 할 수 있다.
• 병렬 다운로드를 지원하기 때문에 모듈을 한번에 설치하여 속도가 빠르다.

✋🏻잠깐!

npm 왈 : 나도, 개선진행할께!

시간이 지나고 npm도 많은 부분이 개선되었습니다. package-lock 파일을 통해서 버전을 고정하고, 속도면에서도 yarn과 큰 차이가 없는 수준까지 따라왔습니다.

하지만, 두 패키지 매니저에도 문제가 존재했습니다.

1. 너무 무거운 node_modules!!!

• npm에서 구성하는 node_modules폴더는 매우 큰 용량을 차지 합니다.

• npm은 이 무거운 폴더를 경량화시키기 위해 호이스팅을 도입하였습니다.

• 용량을 줄이는 가장 간단한 방법은 중복을 제거하는 것입니다.

• node_modules의 중복된 패키지를 최소화하기 위해 각 패키지가 의존하는 패키지들을 최상단으로 끌어올립니다. 이렇게 되면 중복된 패키지가 최상단에 하나만 존재하게 되어 불필요한 중복을 제거할 수 있게 됩니다.

2. 유령 의존성

• 하지만 이렇게 되면, 나는 설치한 적이 없지만 사용하는 패키지가 의존하고 있다는 이유만으로 사용하지 않는 패키지도 설치하게 됩니다. 이러한 현상을 유령 의존성이라고 부릅니다.
• 따라서 비효율적인 설치와 유령 의존성 등은 여전히 npm과 yarn에게 숙제로 남아 있었습니다.
• 하지만, yarn은 이러한 숙제를 해결한 v2를 공개(2020년 1월)했습니다

[참고자료]

• https://toss.tech/article/node-modules-and-yarn-berry
• https://usage.tistory.com/147

React기준(Next.js 환경)으로 사용법이 작성되었습니다.

1. 핵클이 뭐에요?

• https://hackle.io/ko/service/
• 웹 사이트, 모바일 앱, API 등 클라이언트와 서버에서 동작하는 모든 기능을 테스트 및 분석할 수 있는 플랫폼

2. 핵클 회원가입을 진행하여 키를 확인 하세요.

• 운영 SDK(소프트웨어 개발 키트)키와 개발 SDK키를 확인하세요
• SDK키 종류에는 '클라이언트 측'과 '서버 측'이 존재합니다.

3. SDK키로 뭐해요?

1. 테스트 그룹 분배
  - 어떤 테스트 그룹(A,B,C)에서 테스트가 진행되었는지 핵클에 집계가 됩니다
2. 기능 플래그
  - 사용자에 대해 특정 기능의 출시여부를 핵클에 집계가 된다
3. 사용자 이벤트 전송
  - 사용자가 어떤 행동을 했는지 핵클에 집계가 된다
4. 데이터 세부 분석
  - 사용자에 대해 분석 기준값을 수집하여 심도 있는 분석이 가능하다
5. 타겟팅
  - 특정 유저에게만 A/B 테스트에 참여할 수 있게 한다

4. 개발 세팅하자

1) 설치 진행

yarn add @hackler/react-sdk

2) SDK 초기화(설정)

- `HackleReactSDKClient`를 SDK키로 초기화하세요. (디버그 모드 ON)

GTM을 사용하여 연동을 진행할 경우, Hackle SDK 초기화를 하고, SDK를 GTM 에서 접근할 수 있도록 window에 추가 선언이 필요합니다.

import {createInstance, HackleProvider} from "@hackler/react-sdk";

// 설정정보를 포함하여 초기화
const config = {
  debug: true
};

// YOUR_BROWSER_SDK_KEY 자리에 SDK 키를 넣습니다.
const hackleClient = createInstance("YOUR_BROWSER_SDK_KEY")

function MyApp({Component, pageProps}) {
  return (
    <HackleProvider hackleClient={hackleClient} supportSSR>
      <Component {...pageProps} />
    </HackleProvider>
  )
}

export default MyApp

• 명시적으로 대시보드를 업데이트 하는 방법(60초에 1번만 호출가능) : hackleClient.fetch();

3) 핵클에 사용자 정보를 넘겨보자!

• userId를 넘길 수도 있고, 유저에 대한 속성 데이터를 넘길수도 있다

• 속성 데이터 예시 : 나이 : 20대이다, 성별: '여' 이다.

  1) userId 설정 방법

     - hackleClient.setUserId(userId);
     - 로그인 시 한번만 설정하면 됩니다.
     - 이미 로그인이 되어있는 사용자의 경우에는 로그인한 정보를 가지고 오는 시점에 호출하면 됩니다

  2) 사용자 속성 설정 방법

    import { PropertyOperationsBuilder } from "@hackler/react-sdk"
  
    const operations = new PropertyOperationsBuilder()
         .set("age", 42)
         .set("grade", "GOLD")
         .build();
  
    hackleClient.updateUserProperties(operations);

로그아웃시, 아래의 로직을 실행하여 데이터 수집을 막을 것

• 사용자 ID
• 사용자 속성

  hackleClient.resetUser();

4) 사용자가 어떻게 행동하는지 살펴보자!

// 이벤트 수집
hackleClient.track('purchase')

// 이벤트를 속성과 함께 수집
const event = {
  key: "purchase",
  properties: {
    amount: 4200,
    pay_method: "CARD",
    is_discount: false,
    product_ids: [42, 43]
  }
}
hackleClient.track(event);