학업과 직장 생활을 병행한 2024년은 저에게 많은 변화와 새로운 도전을 가져다주었습니다. 1년이 정말 빨리 지나갔는데, 이상하게 지난달에 있었던 일은 한참 전에 있었던 일처럼 느껴지네요. 정신없었던 한 해를 마무리하고 2025년을 기대하는 마음으로 지난 12월 27일 금요일, 회사에서 기년회가 열렸습니다. 기년회를 준비하며 2024년을 쭉 돌아보고 연말 회고록을 작성했는데요, 그 내용을 공유해 드립니다. 연말 회고 방법도 간단히 메모로 남겼으니 참고해 주세요! 😉

🌱 신입 개발자가 연말 회고하는 법 🌱

• 1년 간의 기록 전부 모아서 정리
  • 데일리 로그
  • 주간 회고
  • 프로젝트 회고
  • 개인 기술 블로그
  • 캘린더, 갤러리 사진
• 시간 순서대로 있었던 일 쭉 나열
• 아래 3가지 중심으로 회고
  • 작년과 비교해서 개선된 것, 새롭게 배운 것
  • 어려웠던 것, 아쉬웠던 것
  • 내년에 실천할 Action Plan
• 신년 계획 세우기 (내년 목표, TO-DO, 기대하는 것 등)
• 회사 동료나 지인과 회고한 내용 공유, 내년 목표 공표

2024년 3월 프론트엔드 개발자로서의 커리어를 본격적으로 시작하며 경험한 개발자의 길은 도전의 연속이었습니다. 올해의 경험을 되돌아보며, 3가지 키워드를 꼽아보았습니다.

1. 작업 프로세스 확립

여러 개의 프로젝트에 참여하면서, 저만의 작업 프로세스를 확립했습니다. 작업을 정돈된 흐름으로 일관되게 진행하니 동일한 시간 내에 더 많은 작업을 처리할 수 있었어요. 제가 구성한 작업 프로세스는 아래와 같습니다.

• Jira에 작업 리스팅 및 우선순위 설정

• 프로젝트 세팅
• 퍼블리싱 작업 준비
  • 레이아웃 설계
  • 공통 컴포넌트로 뺄 수 있는 것들 고민
  • 전체적인 디자인 체크 후 빠진 것들은 챙겨서 디자이너님께 요청
    • 반응형 break point
    • 컨텐츠 너비
    • 다양한 사용자 브라우저 너비와 높이에 따른 처리 방향
• 퍼블리싱 작업
• 작업 일지 작성하면서 기능 하나씩 작업 시작
  • 작업 단위는 작게
  • 어떤 작업인지 알 수 있게 Git Branch 네이밍
• 기능 하나씩 구현 끝날 때마다 셀프 리뷰 후 코드 리뷰 요청 → 피드백 수정 반영 후 merge
• 프로젝트 회고

이 프로세스를 근간으로 삼아 지속적으로 개선하고 더 나은 작업 프로세스를 만들어가려 합니다.

2. 커뮤니케이션과 협업

혼자 개발할 때와 팀으로 협업할 때의 차이는 생각보다 컸습니다. 개인 작업에서는 모든 결정을 스스로 내리고, 속도와 방향을 스스로 조율할 수 있었지만, 협업에서는 서로 다른 의견을 조율하고 소통하며 일해야 했습니다. 이 과정에서 단순히 코드를 작성하는 것뿐만 아니라 명확한 커뮤니케이션과 효율적인 협업 방식의 중요성을 크게 느꼈습니다.

협업을 위해 신입이었던 저에게 주어진 미션은 4가지 정도였습니다.

1. 회사 내부 컨벤션 적응
2. 효율적인 협업을 위한 Git 숙달
3. 적절한 질문과 상황 공유는 필수
4. 지식 전파

   2-1. 회사 내부 컨벤션 적응

   팀의 구성원으로서 가장 먼저 해야 했던 것은 회사 내부 컨벤션에 익숙해지는 일이었습니다. 저는 회사 내부 컨벤션을 실수 없이 지키기 위해 하나의 문서로 정리하고 이를 셀프 리뷰 시 체크리스트로 활용했습니다.

회사 내부 컨플루언스 문서에도 추가해서 새로운 컨벤션이 생기거나 수정될 때마다 수시로 업데이트하고 있어요! 언젠가 만나게 될 ✨미래의 New 동료✨에게 이 문서가 꼭 도움이 되었으면 좋겠습니다. 😊

2-2. 효율적인 협업을 위한 Git 숙달

혼자 개발을 했을 때는 Git을 개인적인 버전관리와 히스토리 추적 정도로만 사용했습니다. 하지만 팀으로 개발할 때는 Git이 훨씬 더 큰 역할을 해주었습니다. 처음에는 여러 명이 동시에 작업하는 환경 속에서 Git 충돌 해결에 어려움을 겪기도 했지만, 동료들의 도움으로 점점 익숙해졌습니다. 그리고 어려움을 겪은 상황과 해결법은 모두 개인 notion에 기록으로 남겼습니다. 올 한 해는 오직 기록만이 살길이었습니다. 😂 그래도 경험과 기록이 점점 쌓이니 비슷한 상황이 다시 발생했을 때 이전보다 빠르게 대처할 수 있었습니다.

2-3. 적절한 질문과 상황 공유는 필수

회사의 동료들은 제가 오랜 시간 동안 질문 없이 혼자 작업하고 있으면 종종 너무 조용해서 불안하다고 하셨습니다. ㅋㅋㅋㅋㅋ 실제로 제가 조용히 작업한 걸 들고 코드 리뷰를 받으러 가면 뭔가 크게 잘못되었다는 걸 그제야 깨달았던 적이 많았습니다. 적절한 타이밍에 질문해서 작업이 지체되지 않도록 하는 게 중요한 것 같아요. 하지만 👉 적절한 질문 👈 을 하는 건 어려웠습니다. 적절한 타이밍을 찾는 것도, 작업 방향과 문제를 명확히 설명하는 것도 쉽지 않았어요. 그래도 매일의 업무량 달성을 1순위 목표로 두고 열심히 질문했습니다.

❓ 질문 잘 하는 법 ❗️

• 질문드리기 전 개인적으로 해결해 볼 마감 시간을 정하고 그 시간까지 최대한 해결해 본다.
• 해결되지 않으면 아래의 정보와 함께 질문드린다.
  • 어떤 작업을 하고 있는지
  • 예상되는 원인은 무엇인지
  • 해결을 위해 시도해 본 것들이 있다면 무엇인지

추가로 사무실에서 질문하기엔 좀 애매한 사소한 궁금증이나 개인적인 조언은 밥 먹을 때, 퇴근할 때 등 사무실 외부에서 질문드렸습니다. 제 질문 잘 받아주셔서 진심으로 감사했어요. 🥹🥹🥹

2-4. 지식 전파의 중요성

지식을 공유하면 팀원 모두가 특정 문제를 이해하고 있어서 동일한 문제가 발생했을 때 빠르게 해결할 수 있습니다. 저희 회사에서는 컨플루언스에 [지식 전파소] 라는 페이지를 만들어서 기능 구현이나 에러 해결 경험을 문서화하여 공유하고 있어요! 지식 전파소에 다른 동료 분이 작성한 글을 보고 큰 도움을 받았던 경험이 있습니다. 도움을 받은 만큼 저도 누군가에게 도움이 될 수 있게 내년에도 적극적으로 공유해볼게요!

3. 불확실성

이제 마지막 키워드 불확실성입니다. 실무에서 스스로 통제할 수 없는 상황들이 너무 많았습니다.

• 요구사항이나 우선순위의 갑작스러운 변경
• 디자인, 기획 등 다른 팀 의존성으로 인해 발생하는 지연
• 새로운 기술 스택으로 인한 러닝 커브

불확실한 요소들이 많아질수록 작업이 언제 끝날지, 어떤 방향으로 바뀔지.. 불안은 무한대로 커졌습니다. 매일 쓰는 데일리 로그에 기분 점수를 0점으로 쓰는 날도 있었습니다. 그 날 제 데일리 로그 스레드에는 댓글이 13개 달렸습니다. ㅋㅋㅋㅋㅋㅋㅋㅋㅋ 제 힘듦에 함께 공감해주셨어요..😭😭😭

이런 상황들을 여러 번 겪으면서 내린 결론입니다.

1. 완벽한 계획보다 유연한 계획을 세우는 연습 필요 (매번 생기는 시행착오들을 최대한 예상해서 일정 계획) 2. 변동이나 불확실한 상황이 생기면 팀원이나 리더와 공유 3. 우선순위 관리 필요 (모든 문제를 한꺼번에 해결하려 하지 말고 중요하고 시급한 문제에 우선순위를 두기) 4. 모든 책임을 혼자 짊어지려 하지 말고 도움을 요청 5. 회고와 개선 (다음에 어떻게 대응할지 개선점 찾아보기 → 무엇이 예상 밖이었는가? 어떻게 더 잘 대응할 수 있었나?)

이렇게 키워드로 올 한 해를 정리하니 정말 올해가 끝났다는 게 실감 나고 내년이 더욱더 기대됩니다. 비록 올 한 해 기분 점수가 0점인 날도 있었지만, 기년회 날 제 기분은 10점을 넘어 20점이었습니다! 지나고 나면 별거 아니라는 말이 다 맞는 말인 것 같네요 😅😅😅

저와 함께 2024년을 달려온 모든 동료분들께 감사드리며, 다가오는 2025년에는 더 성장하고 배우겠습니다. 감사합니다.

🤗 링크드인이랑 GitHub에도 놀러오세요! 🤗 링크드인 👉🏻 http://www.linkedin.com/in/u-ryu GitHub 👉🏻 https://github.com/u-ryu-00

Storybook은 UI 컴포넌트 개발 도구입니다. UI 컴포넌트를 격리된 환경에서 개발할 수 있도록 하여, 컴포넌트의 동작을 개별적으로 확인하고 테스트하는 데 도움을 줍니다.

✨ 활용 사례

1. 컴포넌트 개발 Storybook을 사용하면 UI 컴포넌트를 독립적으로 개발할 수 있어, 애플리케이션 전체를 실행하지 않고도 컴포넌트를 개발하고 테스트할 수 있습니다.
2. 디자인 시스템구축 Storybook을 통해 모든 UI 컴포넌트를 한 곳에 모아 디자인 시스템을 구축하고, 일관된 UI를 유지할 수 있습니다.
3. 문서화 및 공유 Storybook의 스토리를 통해 컴포넌트 사용법과 예제를 문서화하여 팀 내에서 쉽게 공유할 수 있습니다.
4. 테스트 자동화 UI 컴포넌트가 예상대로 보이는지 확인하는 테스트가 쉽습니다.

Storybook은 UI 컴포넌트 개발을 더 쉽고 효율적으로 만들어주는 강력한 도구입니다. 독립된 개발 환경, 실시간 업데이트, 다양한 문서화 기능을 통해 개발자와 디자이너 모두에게 유용한 도구로, 특히 컴포넌트 기반의 프론트엔드 개발에서 큰 가치를 제공합니다.

📚 참고 자료

• 스토리북 튜토리얼
• 리액트를 위한 스토리북 튜토리얼

저번 포스트에서는 Docker로 MariaDB에 접속하는 법을 다뤘습니다. 이번 포스트에서는 Docker로 접속한 MariaDB를 쉽게 다루기 위해 Sequel Pro라는 도구를 사용하는 법을 기록합니다.

🥞 Sequel Pro 왜 쓰나요?

• 직관적인 UI: Sequel Pro는 직관적이고 사용하기 쉬운 그래픽 사용자 인터페이스 (GUI)를 제공하여, 명령줄 인터페이스 (CLI)보다 데이터베이스 관리를 더 쉽게 할 수 있습니다.
• 시각적 데이터 관리: 데이터베이스, 테이블, 행 등을 시각적으로 관리할 수 있어, 복잡한 SQL 쿼리를 직접 작성하지 않고도 데이터 조작이 가능합니다.

👩🏻‍💻 Sequel Pro 쓰지 않고 SQL 명령어로 데이터베이스 작업 수행하기

1. 데이터베이스 목록 확인

   SHOW DATABASES;

2. 새로운 데이터베이스 생성

   CREATE DATABASE daisy_database;

3. 사용할 데이터베이스 선택

   USE daisy_database;

4. 선택된 데이터베이스의 테이블 목록 확인

   SHOW TABLES;

   이외에도 여러 SQL 명령어를 사용하여 다양한 작업(테이블 생성, 테이블 구조 확인, 데이터 삽입, 데이터 조회, 데이터 업데이트, 데이터 삭제 등)을 수행할 수 있습니다.

🤍 Sequel Pro로 MariaDB 쉽게 관리하기

1. Sequel Pro 설치

   brew install sequel-pro

2. connect

• Name: 원하시는 이름으로 설정하시면 됩니다.
• Host: 데이터베이스 서버의 주소를 입력합니다. 로컬 서버의 경우 127.0.0.1을 입력합니다.
• Username: 데이터베이스 사용자 이름을 입력합니다. 여기서는 root 입니다. 이전 포스트에서 root로 설정했기에 root로 입력해주었습니다.
• Password: 데이터베이스 사용자의 비밀번호를 입력합니다. 이전 포스트에서 1324로 설정했기에 1324로 입력해주었습니다.

입력이 모두 끝나면 Connect 버튼을 누릅니다.

Choose Database 셀렉트 박스에서 방금 입력한 이름의 database를 선택해서 사용하면 됩니다.

Docker로 MariaDB에 접속하는 방법을 기록합니다. Docker에 대해서 궁금한 분들은 👉🏻 Docker란 👈🏻 이 글을 참고해주세요!

🫧 Docker로 MariaDB 접속하기

1. MariaDB 이미지 가져오기

docker pull mariadb

2. MariaDB 컨테이너 생성하고 실행하기

docker run -p 3306:3306 --name {컨테이너 이름 작성} -e MARIADB_ROOT_PASSWORD={비밀번호} -d mariadb

// 예시
docker run -p 3306:3306 --name daisy-mariadb -e MARIADB_ROOT_PASSWORD=1324 -d mariadb

• docker run: 새로운 컨테이너를 생성하고 실행합니다.
• -p 3306:3306: 로컬 호스트의 포트 3306을 컨테이너의 포트 3306에 매핑합니다. (mariaDB의 기본 포트 번호가 3306이어서 이를 사용함.)
• --name daisy-mariadb: 컨테이너의 이름을 daisy-mariadb로 지정합니다.
• -e MARIADB_ROOT_PASSWORD=1324: MariaDB의 root 사용자 비밀번호를 1324로 설정합니다.
• -d: 컨테이너를 백그라운드 모드에서 실행합니다.
• mariadb: 공식 MariaDB 이미지를 사용합니다.

// 실행 중인 컨테이너만 조회
docker ps

// 모든 컨테이너 조회
docker ps -a

조회해서 내가 생성한 컨테이너가 잘 뜨면 컨테이너 만들고 실행 시키기까지는 성공입니다!! ✨

3. MariaDB 접속하기

docker exec -it {컨테이너 이름 작성} mariadb -uroot -p

// 예시
docker exec -it daisy-mariadb mariadb -uroot -p

• docker exec: 이미 실행 중인 Docker 컨테이너 내에서 명령어를 실행할 때 사용합니다.
• -it: ✔️ -i (interactive): 표준 입력(STDIN)을 활성화하여 터미널에서 사용자 입력을 받을 수 있게 합니다. ✔️ -t (tty): TTY (teletypewriter)를 할당하여, 터미널과 상호작용할 수 있게 한다. 이는 사용자에게 친숙한 셸 환경을 제공합니다.
• daisy-mariadb: 명령어를 실행할 대상 Docker 컨테이너의 이름입니다. 2번 단계에서 컨테이너를 생성할 때 daisy-mariadb 라는 이름으로 생성했기 때문에 여기서는 daisy-mariadb 라는 이름의 컨테이너에서 명령어를 실행합니다.
• mariadb: 컨테이너 내에서 실행할 명령어입니다. 여기서는 MariaDB 클라이언트를 실행합니다. -uroot: MariaDB 클라이언트에 전달되는 인자입니다. -u 옵션은 데이터베이스 사용자명을 지정하며 root 사용자를 의미합니다.
• -p: MariaDB 클라이언트에 전달되는 인자입니다. -p 옵션은 비밀번호 입력을 요청하는 옵션입니다. 이 옵션을 사용하면 MariaDB 클라이언트가 접속 시 비밀번호를 묻습니다.

4. Enter password

2번 단계에서 설정한 MARIADB_ROOT_PASSWORD 비밀번호를 입력하시면 됩니다. 저는 1324로 설정했기 때문에 1324를 입력해주었습니다.

5. 접속 완료!! 👍🏻

✨ Docker로 연결한 MariaDB 쉽게 관리하는 법 보러가기! 👉🏻 Sequel Pro로 MariaDB 쉽게 관리하기

🩵 Docker란?

개발자가 컨테이너를 빌드, 배포, 실행, 업데이트, 관리할 수 있는 오픈 소스 플랫폼이다.

Docker의 핵심 개념은 이미지와 컨테이너다. Docker 이미지에는 소프트웨어 실행에 필요한 모든 것, 즉 코드, 런타임, 드라이버, 도구, 스크립트, 라이브러리, 배치 등이 포함된다. Docker 컨테이너는 이미지를 실행한 상태라고 볼 수 있다.

👩🏻‍💻 Docker 이미지란?

Docker 이미지에는 실행 가능한 애플리케이션 소스 코드는 물론, 이 애플리케이션 코드가 컨테이너 형태로 실행되는 데 필요한 모든 툴, 라이브러리 및 종속 항목이 포함되어 있다. Docker 이미지를 완전히 새로 빌드하는 것도 가능하지만, 대부분 개발자는 공통 저장소에서 해당 이미지를 가져온다.

🎁 컨테이너란?

이미지를 실행한 상태를 컨테이너라고 볼 수 있고 추가되거나 변하는 값은 컨테이너에 저장된다. 같은 이미지에서 여러 개의 컨테이너를 생성할 수 있고 컨테이너의 상태가 바뀌거나 컨테이너가 삭제되더라도 이미지는 변하지 않고 그대로 남아있다.

🪛 Docker 왜 쓰나요?

Docker를 사용하면 개발 환경을 쉽게 설정할 수 있다. 새로운 개발자가 프로젝트에 참여할 때, Docker 이미지를 실행하는 것만으로 개발 환경을 즉시 구축할 수 있다. 복잡한 환경 설정 없이, 컨테이너만 실행하면 필요한 모든 것이 준비된다.

✨ Docker로 MariaDB 접속하러 가기! 👉🏻 Docker로 MariaDB 접속하기

📚 참고 자료

• Docker란 무엇인가?
• 도커 (소프트웨어)
• Docker란?
• 초보를 위한 도커 안내서 - 도커란 무엇인가?

프로젝트를 진행하던 중 건강보험심사평가원에서 관리하는 병원 정보 데이터를 활용할 일이 생겼다. 엑셀 파일로 데이터를 다운로드 받았는데 이 중에서 필요한 데이터들을 json 형식으로 변환해서 가져다 쓰고 싶었다.

엑셀 파일의 데이터를 골라내어 json 형식으로 변환하기 위한 도구로 ChatGPT-4o를 사용했다.

ChatGPT-4o에 xls 확장자 파일을 업로드 했을 때 오류가 발생해서 xls 파일을 xlsx 형식으로 변환해서 다시 업로드 해주었더니 파일이 성공적으로 업로드 되었다! ✨

내가 원하는 결과대로 데이터가 변환되어서 출력되고 있는 모습이다.

아무래도 데이터가 많다보니 빠진 부분도 있었는데 사진처럼 추가로 요청했더니 정확한 데이터를 돌려주었다.

ChatGPT-4o에 Excel 파일 업로드 해서 json 형식으로 데이터 정리하기 성공!!! ✨✌️

🧭 절대 URL vs 상대 URL

URL의 맥락에서 절대와 상대의 차이가 무엇을 의미하는지 살펴보자.

URL의 필수 부분은 URL이 사용되는 context에 따라 크게 달라진다. 브라우저의 주소 표시줄에서 URL은 아무 맥락이 없으므로 전체(또는 절대) URL을 제공해야 한다. 프로토콜이나 포트를 포함할 필요는 없지만 URL의 다른 모든 부분은 필요하다.

URL이 HTML 페이지와 같은 문서 내에서 사용되는 경우, 상황이 약간 다르다. 브라우저에는 이미 문서 고유의 URL이 있기 때문에 이 정보를 사용하여 해당 문서 내에서 사용할 수 있는 URL의 누락된 부분을 채울 수 있다. *URL의 경로 부분만 보면 절대 URL과 상대 URL을 구별할 수 있다. URL의 경로 부분이 "/" 문자로 시작하는 경우 브라우저는 현재 문서에서 제공하는 맥락을 참조하지 않고 서버의 최상위 루트에서 해당 리소스를 가져온다. *

🩶 절대 URL의 예시

✅ 전체 URL
https://developer.mozilla.org/ko/docs/Learn

✅ 절대 경로는 / 부터 시작합니다.
/images/main/photo.jpg

🩶 상대 URL의 예시

✅ 디렉터리 트리로 돌아가기
../CSS/display

👩🏻‍💻 참고 자료

• mdn URL이란?
• 절대주소 vs 상대주소 개념 정확히 이해하기

Next.js는 이미지와 같은 정적 파일을 루트 디렉터리의 public 이라는 폴더 아래에 제공할 수 있다. 그러면 기본 URL(/)에서 시작하는 코드에서 public 내부의 파일을 참조할 수 있다.

예를 들어, public/avatars/me.png 파일은 /avatars/me.png 경로로 이동하여 볼 수 있다. 해당 이미지를 표시하는 코드는 다음과 같다.

import Image from 'next/image'

export function Avatar({ id, alt }) {
  return <Image src={`/avatars/${id}.png`} alt={alt} width="64" height="64" />
}

export function AvatarOfMe() {
  return <Avatar id="me" alt="A portrait of me" />
}

✅ Next.js에서 이미지 파일 제대로 불러오기!

1. Next.js의 루트 디렉토리에 public 이라는 이름의 폴더 생성
2. public 폴더 안에 불러오려고 하는 이미지 파일 넣기
3. / 경로를 통해 public 폴더 안에 저장된 파일에 접근해서 이미지 불러오기 폴더구조가 아래와 같은 경우 <img src="/images/example.jpg" alt="Example" /> 이렇게 불러오면 됨!

my-next-app/
├── public/
│   └── images/
│       └── example.jpg
├── pages/
│   └── index.js
└── ...

👩🏻‍💻 참고자료

• Static Assets

에러가 발생했는데 nextjs 공식 문서 링크와 함께 나타나고 있어서 공식 문서 링크로 들어갔다.

Text content does not match server-rendered HTML

👾 이 에러가 발생한 이유

애플리케이션을 렌더링하는 동안 서버에서 미리 렌더링 된 React 트리와 브라우저에서 처음 렌더링하는 동안 렌더링 된 React 트리 사이에 차이가 있었기 때문이다. (hydration)

Hydration은 React가 이벤트 핸들러를 첨부하여 서버에서 미리 렌더링된 HTML을 완전한 interactive 애플리케이션으로 변환하는 것이다.

** 위의 hydration 설명이 이해가 안된다면 따로 공부한 내용을 정리해서 글로 남겨두었으니 참고! ✍️ hydration **

👾 일반적인 원인

1. 잘못된 HTML 태그 중첩
   • 다른 <p> 태그에 중첩된 <p>
   • <div> 태그 안에 중첩된 <p> 태그
   • <p> 태그 안에 중첩된 <ul> 또는 <ol>
   • Interactive Content가 중첩된 경우 (<a>, <button>)
2. 렌더링 로직에서 typeof window !== 'undefined' 과 같은 check 사용
3. 렌더링 로직에 window 또는 localStorage와 같은 browser-only API 사용
4. 렌더링 로직에서 Date() 생성자와 같은 time-dependent API 사용
5. HTML을 수정하는 Brower extensions
6. 잘못 구성된 CSS-in-JS 라이브러리
7. Cloudflare 자동 축소와 같이 html 응답 수정을 시도하는 잘못 구성된 Edge/CDN.

   나의 경우는 3번 원인 때문에 해당 에러가 발생하고 있었다.

✨ 해결 방법

useEffect 를 사용하여 클라이언트에서만 실행하기

hydration mismatch를 방지하기 위해 컴포넌트가 초기 클라이언트 측 렌더링(CSR) 시와 동일한 콘텐츠를 서버 측에서 렌더링하는지 확인한다. useEffect 훅을 사용하여 의도적으로 클라이언트에서 다른 콘텐츠를 렌더링할 수 있다.

import { useState, useEffect } from 'react'

export default function App() {
  const [isClient, setIsClient] = useState(false)

  useEffect(() => {
    setIsClient(true)
  }, [])

  return <h1>{isClient ? 'This is never prerendered' : 'Prerendered'}</h1>
}

React가 hydration되는 동안 useEffect 가 호출된다. 즉. window 와 같은 브라우저 API를 hydration mismatch 없이 사용할 수 있다.

공식 문서만 보고서는 이해가 잘 안 갔다.. 보충 설명!

• useEffect 훅은 클라이언트 측에서만 실행된다. 이 훅은 컴포넌트가 렌더링된 후에 실행되므로, 브라우저 환경에서만 동작하는 코드(ex:window 객체에 접근하는 코드)를 안전하게 사용할 수 있다.
• useEffect 훅을 사용하여 클라이언트에서만 상태를 변경함으로써, 서버와 클라이언트의 초기 렌더링 결과를 동일하게 유지할 수 있다.
• 이는 hydration mismatch를 방지하고, React가 서버에서 받은 HTML과 클라이언트에서 렌더링된 HTML이 일치하도록 보장한다.
• 따라서 useEffect 를 사용하여 클라이언트에서만 실행하는 것이 해당 에러의 해결책이 될 수 있는 것이다.

📚 참고 자료

• Text content does not match server-rendered HTML
• hydration

💧 Hydration 이란?

웹 개발에서 hydration 또는 rehydration은 클라이언트 측 JavaScript가 정적 호스팅 또는 server-side rendering을 통해 전달된 정적 HTML 웹 페이지를 이벤트 핸들러를 HTML 요소에 첨부하여 동적 웹 페이지로 변환하는 기법이다.

HTML이 서버에서 미리 렌더링되기 때문에 "첫 번째 콘텐츠가 빠르게 표시"(유용한 데이터가 사용자에게 처음 표시되는 시점)되지만 클라이언트 측 JavaScript가 실행되고 이벤트 핸들러가 첨부될 때까지는 일정 시간이 걸린다.

hydration을 사용하는 프레임워크에는 Next.js 및 Nuxt.js가 있다.

❗️ 이해한 내용

Hydration 기법

1. SSR로 만들어진 정적 HTML 웹 페이지
2. JavaScript로 수분 보충 (ㅋㅋ)
3. 동적 웹 페이지로 변환

📚 참고자료

• Hydration (web development)

  <table>
    <colgroup>
      <col span="1" style="width: 30%">
      <col span="1" style="width: 20%">
      <col span="1" style="width: 15%">
      <col span="1" style="width: 35%">
    </colgroup>
    <thead>
    <tr>
      <th>
        Band
      </th>
      <th>
        Year
      </th>
      <th>
        formed No. of Albums
      </th>
      <th>
        Most famous song
      </th>
    </tr>
    </thead>
    <tbody>
    <tr>
      <td>
        Buzzcocks
      </td>
      <td>
        1976
      </td>
      <td>
        9
      </td>
      <td>
        Ever fallen in love (with someone you shouldn't've)
      </td>
    </tr>
    <tr>
      <td>
        The Clash
      </td>
      <td>
        1976
      </td>
      <td>
        6
      </td>
      <td>
        London Calling
      </td>
    </tr>
    <tr>
      <td>
        The Damned
      </td>
      <td>
        1976
      </td>
      <td>
        10
      </td>
      <td>
        Smash it up
      </td>
    </tr>
    <tr>
      <td>
        Sex Pistols
      </td>
      <td>
        1975
      </td>
      <td>
        1
      </td>
      <td>
        Anarchy in the UK
      </td>
    </tr>
    <tr>
      <td>
        Sham 69
      </td>
      <td>
        1976
      </td>
      <td>
        13
      </td>
      <td>
        If The Kids Are United
      </td>
    </tr>
    <tr>
      <td>
        Siouxsie and the Banshees
      </td>
      <td>
        1976
      </td>
      <td>
        11
      </td>
      <td>
        Hong Kong Garden
      </td>
    </tr>
    <tr>
      <td>
        Stiff Little Fingers
      </td>
      <td>
        1977
      </td>
      <td>
        10
      </td>
      <td>
        Suspect Device
      </td>
    </tr>
    <tr>
      <td>
        The Stranglers
      </td>
      <td>
        1974
      </td>
      <td>
        17
      </td>
      <td>
        No More Heroes
      </td>
    </tr>
    </tbody>
    <tfoot>
    <tr>
      <td colspan="2">
        Total albums
      </td>
      <td colspan="2">
        77
      </td>
    </tr>
    </tfoot>
  </table>

table {
  width: 100%;
}

table thead {
  background: #000000;
  color: #FFFFFF;
}

table tbody {
  display: block;
  height: 200px;
  overflow-y: scroll;
}

table tfoot {
  background: #000000;
  color: #FFFFFF;
}

위의 사진처럼 column의 width가 깨지는 문제가 발생한다. 이 문제를 해결하기 위해서는 아래의 css 코드를 추가해주어야 한다.

table thead tr, table tbody tr, table tfoot tr {
  display: table;
  width: 560px;
}

table thead tr th {
  width: 140px
}

table tbody tr td {
  width: 140px
}

table tfoot tr td {
  width: 140px
}

참고 자료

• mdn 표 스타일링

🗓️ Datepicker란?

사용자가 캘린더에서 날짜를 선택할 수 있는 jQuery 기반의 라이브러리

🗓️ Datepicker 위젯 적용하기

1. jQuery, jQuery UI 파일을 다운받아 웹 페이지에 로드

• jQuery는 자바스크립트 라이브러리이므로, jQuery 파일은 자바스크립트 파일(.js 파일) 형태로 존재한다. 따라서 웹 페이지에서 jQuery를 사용하기 위해서는 jQuery 파일을 먼저 웹 페이지에 로드(load)해야 한다.
• 최신 버전의 jQuery 파일은 공식 사이트에서 다운받을 수 있다.
• 최신 버전의 jQuery UI 파일도 마찬가지로 공식 사이트에서 다운받을 수 있다.
• 다운받은 파일을 서버에 저장하고 <script> 태그와 <link> 태그를 웹 페이지의 <head> 태그 내에 삽입하면 된다.
• 🚨 jQuery UI는 jQuery를 기반으로 만들어졌기 때문에 jQuery UI를 사용하려면 먼저 jQuery를 load 해야 한다. 🚨

👩🏻‍💻 예제 코드

<head>
  <link href="파일경로/제이쿼리-ui-css-파일명.css" rel="stylesheet" type="text/css"/>
  // jQuery 먼저 load
  <script src="/파일경로/제이쿼리-파일명.js" type="text/javascript"></script>
  // jQuery UI load
  <script src="/파일경로/제이쿼리-UI-파일명.js" type="text/javascript"></script>
</head>

2. datepicker를 적용할 input 요소에 대해 datepicker를 호출

👩🏻‍💻 예제 코드

<script>
  $(function () {
    $("#datepicker").datepicker({
      showOn: "both" // button > 버튼을 클릭할 때 datepicker 표시. focus > input 필드가 포커스를 받을 때 표시. both > 두 이벤트 중 하나가 발생할 때 표시.
      , buttonImage: "../images/calender.svg" // datepicker를 사용할 버튼 이미지의 URL
      , buttonImageOnly: true // 위에서 설정한 buttonImage를 button 요소 안에 렌더링 하지 않고 단독으로 렌더링
      , buttonText: "선택" // 버튼에 표시되는 글자
      , changeYear: true // dropdown으로 year 선택 가능
      , changeMonth: true // dropdown으로 month 선택 가능
      , dateFormat: 'yy-mm-dd' // 표시되는 날짜의 형식
      , dayNames: ['일요일', '월요일', '화요일', '수요일', '목요일', '금요일', '토요일'] // 일요일부터 시작하는 요일 이름 목록
      , dayNamesMin: ['일', '월', '화', '수', '목', '금', '토'] // Datepicker 내에서 열 머리글로 사용할 수 있도록 일요일부터 시작하는 최소화된 요일 이름 목록 
      , maxDate: "+5y" // 선택할 수 있는 최대 날짜 (+1D:하루후, -1M:한달후, -1Y:일년후)    
      , minDate: "-5Y" // 선택할 수 있는 최소 날짜 (-1D:하루전, -1M:한달전, -1Y:일년전)
      , monthNames: ['1월', '2월', '3월', '4월', '5월', '6월', '7월', '8월', '9월', '10월', '11월', '12월'] // 1월부터 시작하는 월 이름 목록
      , monthNamesShort: ['1월', '2월', '3월', '4월', '5월', '6월', '7월', '8월', '9월', '10월', '11월', '12월'] // Datepicker header의 month에 사용되는 월 이름 목록
      , showMonthAfterYear: true // Datepicker header에서 표시 순서가 연도-월이 되도록
      , showOtherMonths: true // 현재 월의 시작 또는 끝에 다른 월의 날짜를 표시하겠다. (선택은 불가. 이러한 날짜를 선택할 수 있게 하려면 selectOtherMonths 옵션을 사용할 것)
      , yearSuffix: "년" // Datepicker header의 연도 뒤에 표시할 추가 텍스트
    });
    // Datepicker의 default 날짜를 설정
    $('#datepicker').datepicker('setDate', 'today'); // (-1D:하루전, -1M:한달전, -1Y:일년전), (+1D:하루후, -1M:한달후, -1Y:일년후)
  });
</script>

<input id="datepicker">

🗓️ 검색할 날짜의 범위를 선택하는 경우

👩🏻‍💻 예제 코드

<script>
  $(function () {
    $("#datepicker-from").datepicker({
      showOn: "both" // button > 버튼을 클릭할 때 datepicker 표시. focus > input 필드가 포커스를 받을 때 표시. both > 두 이벤트 중 하나가 발생할 때 표시.
      , buttonImage: "../images/calender.svg" // datepicker를 사용할 버튼 이미지의 URL
      , buttonImageOnly: true // 위에서 설정한 buttonImage를 button 요소 안에 렌더링 하지 않고 단독으로 렌더링
      , buttonText: "선택" // 버튼에 표시되는 글자
      , changeYear: true // dropdown으로 year 선택 가능
      , changeMonth: true // dropdown으로 month 선택 가능
      , dateFormat: 'yy-mm-dd' // 표시되는 날짜의 형식
      , dayNames: ['일요일', '월요일', '화요일', '수요일', '목요일', '금요일', '토요일'] // 일요일부터 시작하는 요일 이름 목록
      , dayNamesMin: ['일', '월', '화', '수', '목', '금', '토'] // Datepicker 내에서 열 머리글로 사용할 수 있도록 일요일부터 시작하는 최소화된 요일 이름 목록 
      , maxDate: "+5y" // 선택할 수 있는 최대 날짜 (+1D:하루후, -1M:한달후, -1Y:일년후)    
      , minDate: "-5Y" // 선택할 수 있는 최소 날짜 (-1D:하루전, -1M:한달전, -1Y:일년전)
      , monthNames: ['1월', '2월', '3월', '4월', '5월', '6월', '7월', '8월', '9월', '10월', '11월', '12월'] // 1월부터 시작하는 월 이름 목록
      , monthNamesShort: ['1월', '2월', '3월', '4월', '5월', '6월', '7월', '8월', '9월', '10월', '11월', '12월'] // Datepicker header의 month에 사용되는 월 이름 목록
      , showMonthAfterYear: true // Datepicker header에서 표시 순서가 연도-월이 되도록
      , showOtherMonths: true // 현재 월의 시작 또는 끝에 다른 월의 날짜를 표시하겠다. (선택은 불가. 이러한 날짜를 선택할 수 있게 하려면 selectOtherMonths 옵션을 사용할 것)
      , yearSuffix: "년" // Datepicker header의 연도 뒤에 표시할 추가 텍스트
    });
    // Datepicker의 default 날짜를 설정
    $("#datepicker-to").datepicker({
      showOn: "both" // button > 버튼을 클릭할 때 datepicker 표시. focus > input 필드가 포커스를 받을 때 표시. both > 두 이벤트 중 하나가 발생할 때 표시.
      , buttonImage: "../images/calender.svg" // datepicker를 사용할 버튼 이미지의 URL
      , buttonImageOnly: true // 위에서 설정한 buttonImage를 button 요소 안에 렌더링 하지 않고 단독으로 렌더링
      , buttonText: "선택" // 버튼에 표시되는 글자
      , changeYear: true // dropdown으로 year 선택 가능
      , changeMonth: true // dropdown으로 month 선택 가능
      , dateFormat: 'yy-mm-dd' // 표시되는 날짜의 형식
      , dayNames: ['일요일', '월요일', '화요일', '수요일', '목요일', '금요일', '토요일'] // 일요일부터 시작하는 요일 이름 목록
      , dayNamesMin: ['일', '월', '화', '수', '목', '금', '토'] // Datepicker 내에서 열 머리글로 사용할 수 있도록 일요일부터 시작하는 최소화된 요일 이름 목록 
      , maxDate: "+5y" // 선택할 수 있는 최대 날짜 (+1D:하루후, -1M:한달후, -1Y:일년후)    
      , minDate: "-5Y" // 선택할 수 있는 최소 날짜 (-1D:하루전, -1M:한달전, -1Y:일년전)
      , monthNames: ['1월', '2월', '3월', '4월', '5월', '6월', '7월', '8월', '9월', '10월', '11월', '12월'] // 1월부터 시작하는 월 이름 목록
      , monthNamesShort: ['1월', '2월', '3월', '4월', '5월', '6월', '7월', '8월', '9월', '10월', '11월', '12월'] // Datepicker header의 month에 사용되는 월 이름 목록
      , showMonthAfterYear: true // Datepicker header에서 표시 순서가 연도-월이 되도록
      , showOtherMonths: true // 현재 월의 시작 또는 끝에 다른 월의 날짜를 표시하겠다. (선택은 불가. 이러한 날짜를 선택할 수 있게 하려면 selectOtherMonths 옵션을 사용할 것)
      , yearSuffix: "년" // Datepicker header의 연도 뒤에 표시할 추가 텍스트
    });
    // Datepicker의 default 날짜를 설정  
    $('#datepicker-from').datepicker('setDate', 'today'); // (-1D:하루전, -1M:한달전, -1Y:일년전), (+1D:하루후, -1M:한달후, -1Y:일년후)
    $('#datepicker-to').datepicker('setDate', 'today'); // (-1D:하루전, -1M:한달전, -1Y:일년전), (+1D:하루후, -1M:한달후, -1Y:일년후)  
  });
</script>

<label for="datepicker-from">From</label>
<input id="datepicker-from">
<label for="datepicker-to">to</label>
<input id="datepicker-to">

**jQuery API documentation에 options와 methods에 대한 설명이 자세히 나와있으니 참고해서 알맞게 custom하면 된다! 😊 **

참고 자료

• jQuery UI Datepicker
• jQuery API documentation
• TCP SCHOOL 제이쿼리 적용
• (이미지) 작가 brgfx 출처 Freepik

💡 사용자 지정 속성이란? (CSS 변수)

• CSS 저작자가 정의하는 개체로, 문서 전반적으로 재사용할 임의의 값을 담는다.
• 전용 표기법을 사용해 정의한다. (--main-color: black;)
• var() 함수를 사용해 접근할 수 있다. (color: var(--main-color);)

💡 사용자 지정 속성 왜 쓰나요?

• 첫번째 이유. 복잡한 웹사이트는 어마어마한 양의 CSS를 가지고 있는데, 종종 많은 값을 반복적으로 사용한다. 사용자 지정 속성을 사용하지 않는다면 여러 곳에 중복된 색상을 변경하기 위해 모든 CSS 파일에서 검색 및 바꾸기를 수행해야 한다.
• 두번째 이유. 의미를 가지는 식별자를 사용하기 때문에 특히 같은 색을 다른 맥락에서 사용할 때 유용하다. #00ff00 보다는 --main-text-color 가 이해하기 쉬울 것이다.

💡 변수 선언 및 호출

두 개의 붙임표로 시작하는 속성의 이름과 함께 유효한 CSS 값이라면 무엇이든지 그 값으로 지정해서 선언한다.

:root {
  --main-bg-color: brown;
}

사용자 지정 속성의 값을 사용할 때에는 일반적인 값의 자리에 var() 함수를 지정하고, 그 매개변수로는 사용자 지정 속성의 이름을 제공한다.

element {
  background-color: var(--main-bg-color);
}

💡 :root CSS pseudo-class

• 문서 트리의 루트 요소를 선택한다.
• HTML의 루트 요소는 <html> 요소이므로, :root의 specificity가 더 높다는 점을 제외하면 html 선택자와 똑같다.
• :root는 전역 CSS 변수 선언에 유용하게 사용할 수 있다.

💡 예시 코드

:root {
  --main-bg-color: brown;
}

.one {
  color: white;
  background-color: var(--main-bg-color);
  margin: 10px;
  width: 50px;
  height: 50px;
  display: inline-block;
}

.two {
  color: white;
  background-color: black;
  margin: 10px;
  width: 150px;
  height: 70px;
  display: inline-block;
}
.three {
  color: white;
  background-color: var(--main-bg-color);
  margin: 10px;
  width: 75px;
}
.four {
  color: white;
  background-color: var(--main-bg-color);
  margin: 10px;
  width: 100px;
}

.five {
  background-color: var(--main-bg-color);
}

참고 자료

• mdn 사용자 지정 CSS 속성 사용하기 (변수)
• mdn :root
• CSS Variables and How To Use Them

📚 함께 자라기

🌷HSD 2기🌷와 함께 읽을 책은 함께 자라기 이고 1회차 때 다룬 주제는 자라기 였다. 1회차, 2회차 스터디에 참여하면서 함께 자라기를 '실천'하는 자신만의 방법을 수립하고, 2024년 1년 동안 각자의 방법을 '실천'하며 성장하는 것이 이번 스터디의 목표이다. 이번 스터디를 위해 총 12분이 모여주셨는데 체크인/회고 시트가 가득가득 채워지는 모습을 보면서 든든한 마음이 들었다. 2기 분들과 엄청난 성장을 기록하는 2024년을 만들어가고 싶다.

1회차 스터디 회고를 하면서 나를 돌아보고 2024년을 어떻게 보낼지 고민하는 시간을 가졌다.

✨ 나만의 실패 극복 루틴!

1회차 스터디 때 성장 사고관 이라는 키워드가 언급되었다. 성장 사고관이란 시간과 경험을 통해 특성과 재능이 끊임없이 변화하며 성장할 수 있다고 믿는 마음가짐이다. 지난 2023년 꽤나 다양한 실패를 경험했고, 2024년에도 당연히 크고 작은 실패를 경험하게 될 것이다. 처음 실패를 마주했을 때는 그것을 어떻게 다루어야 할지 방법을 잘 몰랐던 것 같다. 여러 번 실패를 거듭한 끝에 나만의 실패 극복 루틴이 생긴 것 같아 글로 남겨보려 한다. 😂

step 1. 실패를 하고 나서 최대한 빨리 셀프 피드백을 한다. (왜 실패했는지 원인 찾기) step 2. 실패를 성공으로 바꾸기 위해 개선할 만한 Point 찾아서 Action Plan을 만든다. step 3. 매번 성공만 할 수 없음을 인정하고 실패나 좌절을 성장을 위한 기회로 받아들인다. (성장 사고관 주입) 👈🏻 _이번 스터디 덕분에 추가된 step이다. _ step 4. 실패에 지치지 않고 Action Plan 적용해서 다시 도전해본다! 🌷

실패하고 나서 피드백을 하지 않으면 Action Plan이 나오지 않고 그러면 똑같은 실패가 반복될 가능성이 크다. 실패를 외면하면 마음도 매우 불안하고 자신감도 뚝 떨어지게 된다. 하지만 실패한 후에 피드백을 하고 Action Plan 까지 세우면 실패를 했음에도 뭔가 든든하고 다음에는 더 잘할 수 있을 것 같은 자신감까지 생긴다!!! 이렇게 쓰고보니 뭔가 실패 전문가가 된 것 같지만 ㅋㅋㅋㅋㅋㅋㅋ 실패 극복 루틴 덕분에 2024년 실패도 두렵지 않다. ✌️

🌱 효과적인 의도적 수련을 위해서?

효과적이지 못한 의도적 수련의 조건을 3가지 정도로 정리해보고 이것을 잘 보완해서 효과적인 의도적 수련으로 바꿔보려고 한다.

1. 동기의 부족 -> 무언가 할 수 밖에 없는 상황을 만들자.

첫번째 포인트는 생각보다 쉽게 해결될 부분인 것 같다.

나는 개발자가 되기 위해 공부하던 시절 HTML과 CSS를 일주일만에 공부했다. 당연히 내 CSS 실력은 엉망이었다. 🫠 개발자가 되어 실무에 투입되었을 때도 내 CSS 실력은 썩 좋지 않았다. 하지만 나는 마감에 맞추어 작업을 해내야 했고 엄청난 집중력을 발휘해서 폭풍 검색을 하며 퍼블리싱을 해냈다. 동기가 분명했기 때문에 가능했던 일이라고 생각한다. 아무런 동기 없이 단순히 학습하는 것은 좋은 학습 효과를 내기 어렵다. 분명한 동기를 설정하는 것이 실천의 시작이 된다.

동기의 측면에 있어서는 HSD 스터디가 많은 부분을 충족해주고 있다. HSD 1기와 함께 했던 HTTP 스터디 때도 매주 스터디를 준비하다보니 HTTP를 깊이 공부할 수 밖에 없었다.

지금 회고를 쓰고 있는 것도 그렇다. 혼자였다면 일요일 밤에 이렇게 노트북을 켜고 글을 썼을까? 의문이다. 혼자보다는 둘이, 둘 보다는 여럿이. 좋은 동료들과 함께하면 그 시너지가 크게 작용하는 것 같다.

2. 부적절한 난이도

의도적 수련이 되려면 나의 실력과 작업의 난이도가 비슷해야 한다. 이것은 미하이 칙센트미하이의 몰입이론과도 일치하는 부분이다. 미하이는 난이도와 실력이 엇비슷하게 맞는 부분에서 인간이 몰입 을 경험한다고 한다. 그리고 바로 이때 최고 수준의 집중력을 보이고, 그 덕분에 퍼포먼스나 학습 능력이 최대치가 될 수 있다고 한다. 또한 그때 최고 수준의 행복감을 경험한다는 흥미로운 사실을 발견하기도 했다.

효과적인 의도적 수련을 위해서 '지루함'을 느끼는 영역, '몰입'을 느끼는 영역, '불안'을 느끼는 영역을 꾸준히 탐색해 보고 이것들을 '몰입'으로 이동시킬 방법을 고민해 봐야겠다. 이건 단기간에 탐색하기엔 어려울 것 같아 조금 더 시간을 두고 탐색해 보려 한다.

3. 제 때 받지 못하는 피드백

지금 당장 만들어 볼 수 있는 피드백 루프는 아무래도 셀프 피드백일 것 같다. 회사에서 slack으로 매일 daliy-log를 작성하고 있다. 출근 하자마자 오늘 달성해야 할 목표를 세우고 기록한다. 퇴근 전에는 달성한 목표를 점검하고 그것을 바탕으로 Action Plan을 세운다. 덕분에 매일 회고하고 피드백하는 루틴은 잡혀있다. 여기서 중요한 포인트는 회고를 해서 이 문제를 해결하기 위한 Action Plan을 만드는 것이라고 생각한다. 내일은 어떻게 할지에 대한 명확한 Action Plan을 도출하는 것이 회고(피드백)의 핵심이 아닐까. HSD 2기를 함께하면서 주간회고, 월간회고, 반년회고, 연간회고 등 끊임없이 회고와 피드백을 하면서 문제를 마주하고 그것을 적극적으로 개선하려는 습관을 잡아가고 싶다.

🔥 Action Plan

다음 주에도 주간회고 작성하고 셀프 피드백. 2024년에 적용해 볼 의도적 수련 고민.

끝으로 HSD 1기, 원데이 스터디, HSD 2기까지 오면서 스터디 운영에 있어 방향성이나 기본적인 틀이 많이 잡혔다고 느낀다. 아직 더 공부하고 채워야 할 부분들이 많긴 하지만 2024년을 잘 보내면서 우리 스터디가 더욱 단단해지는 시간이 되었으면 좋겠다.

사진과 같은 에러 메시지를 마주했다. 오류 아래에 공식문서 링크가 있어서 링크를 타고 공식문서로 들어갔다.

🖇️ 공식문서 링크

😂 이 오류가 발생한 이유

• next/image 컴포넌트를 활용하는 페이지 중 하나에서 next.config.js의 images.remotePatterns에 정의되지 않은 URL의 호스트명을 사용하는 src 값을 전달했다.

❤️‍🩹 오류 해결 방법

• protocol, hostname, port, 그리고 pathname을 next.config.js의 images.remotePatterns 구성에 추가한다.

  module.exports = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'assets.example.com',
        port: '',
        pathname: '/account123/**',
      },
    ],
  },
  }

👩🏻‍💻 내 코드에 적용

next.config.js 파일 전체 코드

const removeImports = require('next-remove-imports')();

/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true,
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'cwmbknpuxfbndurkpmon.supabase.co',
        port: '',
        pathname: '/storage/v1/object/public/**',
      },
    ],
  },
};

module.exports = removeImports(nextConfig);

오류가 해결되고 이미지가 정상적으로 로드된 모습이다. ✨

이런 에러 메시지를 마주했다. 아주 친절하게 공식문서 링크를 달아주어서 링크를 타고 공식문서로 들어갔다.

🖇️ 공식문서 링크

😂 이 오류가 발생한 이유

• 애플리케이션을 렌더링하는 동안 서버에서 미리 렌더링된 React 트리와 브라우저에서 처음 렌더링되는 동안 렌더링된 React 트리 간에 차이가 발생했다. (하이드레이션)
• 하이드레이션이란 React가 이벤트 핸들러를 첨부하여 서버에서 미리 렌더링 된 HTML을 완전한 인터렉티브 애플리케이션으로 변환하는 것을 말한다.

❤️‍🩹 오류 해결 방법: Using suppressHydrationWarning

타임스탬프와 같이 서버와 클라이언트 간에 불가피하게 콘텐츠가 다를 수 있다. 요소에 suppressHydrationWarning={true}를 추가하여 hydration mismatch warning을 무음으로 설정할 수 있다.

<time datetime="2016-10-25" suppressHydrationWarning />

👩🏻‍💻 내 코드에 적용

<div className="text-sm text-gray-500" suppressHydrationWarning>
  {new Date(created_at).toLocaleDateString()}
</div>

오류가 해결되고 블로그 글 상세보기 페이지가 로드된 모습이다. ✨

(3회차) HTTP의 약점 🖇️ (5회차) 웹 공격 기술

5회차 스터디의 주제인 웹 공격 기술을 학습하면서 3회차 때 공부했던 HTTP의 약점 3가지를 다시 한 번 떠올리면서 복습해볼 수 있었다.

HTTP의 약점 3가지는 다음과 같다.

1. 암호화하지 않은 평문이기 때문에 도청 가능하다.
2. 통신 상대를 확인하지 않기 때문에 위장 가능하다.
3. 완전성을 증명할 수 없기 때문에 변조 가능하다.

이처럼 HTTP 보안 상의 약점이 있기 때문에 HTTP를 사용하는 서버_와 _클라이언트 그리고 서버 상에서 동작하는 _웹 애플리케이션_이 공격 대상이 될 수 있다.

학습 목차 설정 (웹 공격 기술 학습 → 공격 실습 → 공격 사례)

웹 공격이나 보안과 관련된 실무적 경험이 없는데다 책에서도 자세히 설명하고 있지 않아서 학습이 쉽지 않았다. 그래서 다음과 같이 학습 목차를 설정하고 목차대로 웹 공격 기술을 학습했다.

1. 웹 공격 기술 학습 (이론)
2. 웹 공격 실습 (해킹 연습을 위한 사이트 활용)
3. 공격 사례 조사

학습 목차가 정해지고 나니 학습 속도도 빨라지고, 이해도 수월해졌다.

마지막 회차인만큼 멤버들만을 위한 프라이빗 ZEP에서 스터디!

마지막 스터디를 위한 ZEP을 꾸미고 그곳에서 조금은 특별한 온라인 모임을 가졌다! ✨ 멤버분들이 다들 좋아해주셔서 다행이었다. 홀맨님 특별 세션 시간에 각자 자리에 앉아 경청하는 모습부터 인증샷을 위해 무대 중앙으로 다같이 모인 모습까지 너무 귀여웠다 ㅋㅋㅋㅋㅋ 무대 위의 여러분들이 모두 주인공이었어요!! 마지막 5회차 스터디를 즐겨주셔서 감사해요! 🙇🏻‍♀️💜

스터디 기획 및 운영을 해보면서..❤️‍🔥

냉큼 되는 일이 없구나 다시 한 번 더 느꼈다. 😂 정말 많은 시간과 에너지가 필요했고, 처음 해보는 영역이었기 때문에 더 어렵고 힘들었던 것 같다. 그래도 짧은 시간 내에 많은 것을 경험할 수 있었기에 몰입해서 성장할 수 있었다. 그래서 마지막 스터디가 끝나고서 한 없이 행복했고 오랜만에 엄청난 희열을 느낄 수 있었다. 🤩

❤️‍🔥 성과?! 경험?! ❤️‍🔥
1. HSD official 인스타그램 계정 OPEN 및 운영
2. HSD 디스코드 서버 OPEN 및 운영
3. HSD ZEP OPEN
4. HSD 스터디 정책, 커리큘럼 짜기
5. HSD 스터디 브랜딩 (네이밍, 로고 디자인, 정체성 등)
6. 스터디 Member 모집 및 선발
7. HTTP deep dive
8. 스터디 리딩 (퍼실리테이터) + 시각화 자료 제작 (keynote ppt)
9. 매주 스터디에 대한 피드백 + 회고 글 작성 (회고의 생활화 ^_^)
10. 운영진들끼리 긴밀한 소통 (notion, 점심시간 적극 활용)

🔥 Action Plan

• 나는 어떤 개발자인지 고민해본다.
• 고민한 내용을 바탕으로 이력서 작성 + 퍼스널 브랜딩 컨텐츠 제작

📍 HTTP/0.9

- GET 메소드만 지원
- HTTP 헤더가 없어서 HTML 파일만 전송 가능 / 상태코드도 없었음.
- HTML 파일 자체를 응답으로 보내줌.

초창기의 HTTP. HTTP/0.9 버전에서는 GET 메소드만 지원하고 HTTP 헤더가 없어서 HTML 파일만 전송 가능했다. 상태코드도 없었다. 응답 메시지를 보면 HTML 파일 자체를 응답으로 보내주고 있는 것도 확인할 수 있다.

*HTTP/0.9 버전은 HTML 문서를 전송하기 위한 단순한 프로토콜이었다. *

📍 HTTP/1.0

- GET, HEAD, POST 메소드 지원
- 각 요청 안에 버전 정보가 포함되어 전송되었음.
- 헤더의 도입 / 상태코드 추가
- HTTP 헤더(Content-Type)의 도움으로 HTML 이외의 파일도 전송할 수 있게 됨.
- Short-lived Connection (디폴트)

✔️ Short-lived Connection

HTTP/1.0에서 디폴트

HTTP/1.0 버전에서는 short-lived Connection(단기 커넥션)이 디폴트였다. 단기 커넥션은 커넥션 하나 당 하나의 요청, 하나의 응답 처리가 가능한 것을 말하는데 서버에 자원을 요청할 때마다 매번 새로운 연결을 해주어야 했다.

예를 들어 웹 페이지를 요청하면 html과 그에 딸린 css나 js 및 이미지 등등 수많은 자원들이 다운로드 되어 화면에 뜰텐데 각 자원들마다 따로따로 매번 연결하고 다운받고 끊고 다시 연결하고 다운 받고 끊는 것이다. 그래서 초기의 HTTP는 느릴수밖에 없었다.

📍 HTTP/1.1

- 첫 번째 표준화 버전
- 연결 상태 유지(디폴트) & 파이프라이닝

✔️ Persistent Connection (keep-alive)

HTTP/1.1에서 디폴트

HTTP 1.1 버전에서 지속적 접속이 디폴트였다. 지속적 접속 덕분에 한 번 맺어졌던 연결을 끊지 않고 지속적으로 유지하여 성능을 개선할 수 있었다.

✔️ HTTP pipelining

기본적으로 HTTP 요청은 순차적이다. 현재의 요청에 대한 응답을 받고 나서야 다음 요청을 실시한다. 이 경우 다음 요청을 보내는 데까지 상당한 딜레이가 발생할 수 있다. 그래서 파이프라이닝 기술이 도입되었다. 파이프라이닝은 같은 커넥션을 통해서 응답을 기다리지 않고 요청을 연속적으로 보내는 기능이다. 그런데 이 파이프라이닝도 문제가 있다. 첫번째 요청에 대한 응답이 오래 걸릴 경우 그 뒤의 응답도 같이 늦게 되어서 결과적으로 time이 길어지게 되는 비효율적인 상황이 발생하게 된다.

📍 HTTP/2.0

- 이진(binary 프로토콜)
- 응답 다중화(multiplexing)
- 헤더 필드 압축 + 중복 제거
- 서버 푸시

✔️ 이진(binary 프로토콜)

HTTP/1.1은 텍스트 기반 프로토콜이기 때문에 사람이 읽기에는 편하지만 불필요하게 데이터가 커지는 문제가 있었다. HTTP/2에서는 보내야 할 데이터를 바이너리로 변환하는 계층이 있기 때문에 단순 텍스트를 전송하는 것보다 훨씬 더 효율적으로 데이터를 전송할 수 있다.

✔️ 응답 다중화(multiplexing)

HTTP/1.1에서는 TCP 연결에서 한 번에 하나의 요청만 처리 가능하며 요청 별 순서를 반드시 지켜야 했다. HTTP/2에서는 하나의 TCP 연결에서 여러 요청을 동시에 처리할 수 있다.

HTTP/2에서는 순서를 지키지 않고 준비되는 대로 응답

✔️ 헤더 필드 압축 + 중복 제거

HTTP/1.1에서 헤더는 아무런 압축 없이 그대로 전송되었다. 이를 개선하기 위해 HTTP/2.0에서는 HTTP 메시지의 헤더를 압축하여 전송한다. 또한 HTTP/1.1에서는 연속적으로 요청되는 HTTP 메세지들에게서 헤더 값이 중복되는 부분이 많아 메모리가 낭비되었는데, HTTP/2.0에서는 이전 메시지의 헤더 내용 중 중복되는 필드를 재전송하지 않도록 하여 데이터를 절약할 수 있게 되었다.

✔️ 서버 푸시

HTTP/2에서는 클라이언트의 요청에 대해 미래에 필요할 것 같은 리소스를 미리 보낼 수 있다. 예를 들어 클라이언트로부터 HTML 문서를 요청하는 하나의 HTTP 메시지를 받은 서버는 그 HTML 문서가 링크하여 사용하고 있는 이미지, CSS 파일, JS 파일 등의 리소스를 스스로 파악하여 클라이언트에게 미리 push해서 미리 브라우저의 캐시에 가져다 놓는다.

참고 자료

• 그림으로 배우는 HTTP&Network Basic 도서 9장
• mdn HTTP의 진화
• Inpa Dev 👨‍💻:티스토리 HTTP 0.9 ~ HTTP 1.1 까지 알아보는 통신 기술
• mdn Connection management in HTTP/1.x
• 웹 개발자라면 알고 있어야 할 HTTP의 진화 과정
• http/1.1 vs http/2
• Amazon Lightsail에 HTTP2 적용하기
• [HTTP] Keep-Alive 와 pipelining 그리고 Multiplexed Streams을 공부하다가 알게된 버전열 HTTP(0.9 ~ 2.0) 정리
• HTTP/2 소개
• Inpa Dev 👨‍💻:티스토리 HTTP 2.0 소개 & 통신 기술 알아보기

✨ 좋았던 점

(1회차) HTTP의 역사 🖇️ (4회차) HTTP를 기본으로 하는 프로토콜

4회차 스터디 내용을 학습하면서 HTTP의 역사에 대해 깔끔하게 정리해 볼 수 있어서 좋았다. 책에는 HTTP/2.0과 SPDY, WebSocket 등 HTTP를 기본으로 하는 프로토콜 이야기만 담겨 있었지만 이것들이 나오게 된 배경과 역사를 이해하기 위해서는 HTTP 0.9 / 1.0 / 1.1 에 대한 이야기가 꼭 필요할 것 같았다. 이에 1회차에서 아주 간단히 다루었던 HTTP의 역사에 대한 내용을 끌어와서 4회차에서는 깊은 수준으로 다루었다. 이미 알고 있는 내용을 새로운 내용과 계속해서 연결하는 방식으로 스터디를 구성하고 있는데 덕분에 각각의 회차들이 흩어지지 않고 하나의 흐름으로 잘 합쳐지고 있다. 나의 학습법을 공유하려고 시작한 스터디이지만 나도 스터디 덕분에 의식적으로 제대로 된 학습을 하려 신경쓰고 있다는 게 느껴진다. ✌️

스터디 멤버분들께서 4회차 스터디에서 공유해주신 의문점과 추가 개념 ❤️‍🔥

• 마크다운과 마크업! 이름이 비슷한데 어떤 관련성이 있을까요?
• Simple Text Oriented Messaging Protocol
• Server-Sent Events
• 그 외 다수

미처 생각해보지 못했던 의문점을 제시해주시거나 본인의 경험을 아낌없이 나눠주셔서 4회차도 반짝반짝한 눈으로 경청했다. 🌟

🫠 개선된 point & 여전히 아쉬운 point

스터디 리딩

- 시각자료 활용, ppt 구성이 아쉬웠음.
- 어려운 내용을 쉽게 설명하기 위한 고민이 부족했음.
- 스터디 멤버들의 참여를 이끌어내는 과정에서 어색했던 부분이 있었음.

2회차 스터디 다음 날 피드백 시간에 정리했던 아쉬웠던 point다. 이 내용들을 생각하면서 개선할 부분을 명확히 정하고 4회차 스터디를 준비했다. 알아들을 수 있게, 간결하게 정보를 전달하려고 많이 노력했다. 그렇게 하기 위해서 스터디 내용 자체에 대한 공부도 꼼꼼하게 하고, 적절한 시각자료를 찾기 위해 구글링도 엄청 했다. 그래서 그 부분은 확실히 개선 되었다고 스스로 느낀다. 하지만 아직도 능동적으로 상황을 대처하는 센스와 감각은 많이 부족하다. 침묵의 시간이 너무 길어진다거나 말끝을 흐리는 등의 태도는 여전히 아쉬운 point로 남았다. 그래도 여기서 멈추지 않고 발표나 퍼실리테이팅 기회를 끊임없이 만들고 그때 그때 상황을 대처하는 센스와 감각을 익혀가면 된다고 생각한다! ✨

🔥 Action Plan

• 3회차 스터디 내용과 5회차 스터디 내용을 연결지어 하나의 흐름으로 정리하기
• 실제 사례와 5회차 스터디 내용을 함께 학습하기
• 4회차 스터디에서 다루었던 HTTP의 역사와 관련된 TIL 작성 후 공유

✅ TO-DO

• 5회차 스터디 학습 및 학습자료 완성하기
• 5회차 스터디 기획 및 준비
• 스터디 2기 기획

🗓️ 올 한 해를 돌아보고 내년에 해야 할 일을 착착 정리해봅니다.

✨ 2023년 시작 & 개발

1년 내내 다니던 회사와의 계약이 끝나고 좋은 기회가 되어 올해 1월 말부터 개발 공부를 시작하게 됐다. 7월 말까지는 정말 개발 공부만 했다. 6개월 간의 과정은 상상 이상으로 쉽지 않았고 그만두고 싶다는 생각도 여러 번 했었다. 하지만 6개월만 버티자고 다짐하고 또 다짐하며 최종 프로젝트까지 무사히 마무리했다.

작고 귀여운 최종 프로젝트의 결과물 ✨

👩🏻‍💻 첫 개발 프로젝트

9월부터 11월까지 인생 처음으로 개발 프로젝트를 맡아서 하게 됐다.

프로젝트를 다 끝내고 멋지게 회고 발표도 했다. ✌️

첫 번째 프로젝트이다 보니 일정 지키기도 버거웠던 탓에 배운 점, 깨달은 점을 TIL로 기록하지 못하고 흘려보낸 것 같아 아쉬웠다. 앞으로의 프로젝트에서는 새롭게 알게 되는 점들을 조금씩 매일 매일 정리하고 회사 슬랙으로 공유하자는 action plan과 함께 첫 프로젝트를 마무리했다.

👾 FEConf 2023 참석

티켓팅 실패했는데 너무 가고 싶어 보였는지 회사에서 같이 일하는 개발자분이 양도해주셨다 ㅎㅎ 덕분에 신나게 즐기고 왔다! 🙇🏻‍♀️

컨퍼런스는 롯데타워 31층에서 진행되었다. 롯데월드가 한 눈에 들어오는 뷰! ✨

세션은 1시부터 시작이었지만 입장은 12시부터 가능해서 12시에 맞춰서 참석했다. 토스, 숨고, 당근, 현대, TWIP 등 다양한 기업들이 부스를 운영하고 있었는데 일찍 도착한 덕분에 여유롭게 모든 부스를 구경할 수 있었다. 다양한 팀들이 모여 즐겁게 부스를 운영하시는 게 느껴져서 좋은 에너지를 정말 많이 얻고 왔다. ❤️‍🔥

A 트랙, B 트랙 옮겨다니면서 세션도 열심히 들어주고!

컨퍼런스 행사를 다 마치고 나니 밤이 되었다. 🌝

🫧 『튜링의 사과』 클린코드 특강

클린코드 특강을 들으러 성수동 『튜링의 사과』도 방문했다.

튜링의 사과는 개발 관련 도서를 구매하거나 주말에 refresh 하고 싶을 때 종종 방문했다.

🌷 HTTP 스터디 기획 & 리딩

2023년의 끝자락에 스터디 기획과 리딩의 경험이 주어져서 열정 넘치는 한 해의 마무리를 했다. 좋은 동료들과 함께 할 수 있어서 항상 감사한 마음이 크다. 🙏

🔥 2024년 Action Plan

• 프로젝트 진행하면서 배운 점, 깨달은 점을 조금씩 매일매일 정리 (TIL) -> 최소 10회 공유
• 나의 성과를 정리하고 적극적으로 나누기 -> 프로젝트가 끝날 때마다 회고하고 발표
• 발표나 퍼실리테이팅 기회를 만들고 능동적으로 상황을 대처하는 센스와 감각 익히기

✅ 2024년 TO-DO

• Next.js로 기술 블로그 만들기
• 개발 프로젝트
• 스터디 기획 및 운영
• 대학 졸업