사전 스터디를 잘 마무리하고 개강 첫 날.... 난 아직도 그 날의 우리팀 분위기를 잊을 수 없다...

이전 교육 과정이나 팀 활동을 할 때마다 팀운이 좋지 않아 힘들었던 나는 이번 항해 만큼은 좋은 팀원분들과 함께 하고 싶다는 열망이 컸다.

1팀을 처음 만나고 든 생각은 아 또 망하겠는데 였다. (지금은 너무 좋다 !!) 사람이 6명 있는 방이 그렇게 조용할 줄은 몰랐고, 심지어 우리팀 학습 메이트님도 부재중이었는데... 태영님이 없었다면 큰일날 뻔했다. 또 사전 스터디를 함께 했던 분이 계셔서 다행이었다.

어쩌다보니 또 팀장으로 지목 당했다. 자신이 너무 없었지만 이왕 하게 된 거 제일 잘하고 싶었다. 항해를 들어오면서 했던 다짐 중 하나가 항해 기간을 되돌아 봤을 때 후회하지 않도록 열심히 하자 이었기 때문에.... 많은 분들이 잘 했다며 칭찬 해주시는 것을 보면 나쁘지 않게 했나보다.

생각해보면 항해를 하면서 자신 없던 부분을 디벨롭할 수 있었던 것 같다. 팀장, 발표, 공개 페어 코딩 등 두려워하고 있던 영역에 많이 도전해보며 경험도 쌓고 한 단계 성장 할 수 있었다.

특히 공개 페어 코딩은 정말 하길 잘했다고 느낀다.

Q&A 질문 중 페어 코딩을 해달라는 질문이 있었는데, 사실 그 질문은 학습 메이트분께서 하셨다고 한다.

코치님께서 질문 주신 분을 찾는 순간 나보고 해보라는 메세지가 왔고, 처음에는 나의 형편 없는 코드를 다른 분들에게 보여주는 것이 너무 부끄러워 하기 싫다고 얘기를 하려다가 빅테크 기업에서 활동하고 있는 프론트엔드 개발자에게 피드백 받아볼 수 있는 기회가 흔치 않을 것이라는 생각 + 더 이상은 두려움 때문에 피하고 싶지 않아서 도전했다.

정말 잘한 선택이었고, 해보지 않은 것에 도전하는 걸 꺼려했던 나는 이 경험을 기점으로 두려움을 피하지 않는 쪽으로 조금은 바뀔 수 있었다.

항해를 하면서 좋았던 또 다른 부분은 좋은 개발자 동료, 좋은 사람들을 많이 알아갈 수 있었다는 점이다. 항해를 하기 이전까지는 주변에 아는 개발자 동료가 없어 개발 이야기를 나눌 사람이 없었는데, 항해에서는 코드를 치다가 궁금한 부분이 있거나 막히는 부분이 있다면 바로바로 이야기를 나눌 수 있는 동료들이 많이 있었다. 초반에는 "너무 기본적인, 쉬운 내용을 여쭤보는 것이 아닐까?", "나만 모르는 것은 아닐까?" 하며 물어보는 것을 주저했었다. 하지만 주변에서 재현님이 모르면 다 모른다며, 배우러 온 곳인데 질문 하는 것이 뭐가 무섭냐며 겁먹지 말고 질문을 해보라는 이야기를 많이 해주셨다.

그렇게 며칠을 고민했던 부분을 용기내어 질문을 올렸고, 늦은 시간까지 함께 고민해주고 좋은 자료도 공유 받을 수 있었다. 처음이 무섭지 한 번 해보고 난 뒤 부터는 겁 없이 질문 할 수 있었다.

같이 항해를 했던 분들이 나를 정말 많이 바꿔주었다. 정말 항해하길 잘했다 :)

항해를 하면서 힘들고 탈주를 하고 싶었던 적도 있었다. 내가 고민하지 못했던, 생각하지 못했던 부분들을 다른 분들은 당연하게 고민하고 생각하고 계셨다. 나만 뒤쳐지도 있다는 생각에 “아 왜 나는 이런 생각을 하지 못했지?” 라고 하며 자기 자신을 갉아먹고 있었고, 잠을 줄여가며 과제를 하기도 했다. 어느 순간부터는 학습이 아닌 pass를 위한 과제를 하고 있는 나를 발견할 수 있었다. 내가 항해를 하며 절대 패스에 집착하지 말자며 다짐하고 들어왔음에도 불구하고 말이다. 그렇게 3주차 쯤, 항해를 탈주하고 싶다는 생각이 강하게 들었다. 자존감은 너무나도 떨어져 있었고 남은 기간 동안 얼마나 더 암울해질지 가늠할 수가 없었기 때문이다.

나는 우리 팀 학습메이트님이 없었다면 항해를 탈주했을 것이다. 학습메이트님과 페이스 체크를 할 수 있는 기회가 생겼고 다른 분들과 비교하지 말고 배워보는 건 어떠냐는 말씀이 나에겐 엄청 큰 도움이 됐다.

항상 부정적으로 남들과 비교하던 내가 “이렇게도 생각할 수 있구나? 신기하다!” 와 같이 긍정적으로 생각할 수 있는 사람으로 조금은 바뀔 수 있었던 계기가 되었다. 부정적인 생각을 걷어내고자 노력하며 뭐가 됐든, 되든 안 되든 내가 할 수 있는 최선을 다해서 끝까지 해보자는 마음을 가지고 한주한주를 보내고자 했다.

누군가 나에게 항해를 하며 얻은 가장 큰 수확이 뭐냐고 물어본다면 나는 주저하지 않고 좋은 사람을 많이 알아가는 것이라고 말할 수 있다. 물론 FE 개발자로서 갖춰야 할 지식 키워드, 코치님과의 멘토링도 너무 좋았고 도움이 많이 됐지만 항해는 개발자 지인이 없던 나에게 좋은 개발자 동료를 만들어 주었고, 개발자를 떠나서 너무 좋은 사람들을 만날 수 있게 해주었다.

나에게 항해란 두려움을 극복하게 해주었고, 단점을 보완할 수 있게 해주었고, FE 개발자로서 어떤 지식을 쌓으며 나아가야 할 지 알려주었으며 좋은 사람들을 만나게 해주었다. 25년 제일 잘한 일이 아닐까? ㅎㅎ

나를 포함하여 함께한 항해 플러스 7기 분들이 앞으로도 좋은 일만 생기고 행운이 가득한 여정을 이어갔으면 좋겠다.

정말 고생 많으셨습니다 :)

이 제목을 정한 이유

이 제목은 최종 발표 때 사용했던 제목이기도 합니다. 발표 제목은 「여러분의 항해는 안녕하신가요?」였습니다.

사실 이 문장은 과거 다른 교육 과정에서 본 글에서 인용한 것입니다. 프로그래머스 데브코스에 참여하던 시절, 다른 트랙의 한 분이 “여러분의 데브코스는 안녕하신가요?”라는 제목으로 상당히 강도 높은 비판 글을 남기고 떠났던 적이 있었습니다.

그 글이 워낙 인상 깊게 남아 있었고, 저는 반대로 항해에 대한 긍정적인 경험을 담아보고 싶어 이 제목을 선택하게 되었습니다.

항해 플러스를 신청하게 된 이유

길고도 짧았던 10주 동안, 저는 항해 플러스라는 교육 과정에 참여했습니다.

항해에 신청한 이유는 단순했습니다. 회사에서 일이 많지 않았고, 입사 후 6~7개월 동안 스스로 성장하고 있다는 느낌을 받지 못했기 때문입니다.

정체된다는 감각은 곧 불안으로 이어졌고, 사이드 프로젝트나 개발 동아리를 찾아보기도 했습니다. 그러던 중 항해 플러스 후기 글을 접하게 되었습니다. 처음 든 생각은 이거였습니다.

아, 이거 너무 빡세 보이는데?

하지만 동시에, 묘하게 재밌어 보였습니다. 실력에 대한 자신감은 없고, 불안해하면서도 정작 열심히 하고 있지는 않았던 제게 이 과정이 하나의 전환점이 될 수 있겠다는 생각이 들었습니다. 왜인지는 모르겠지만 “이건 무조건 해야 한다”는 생각이 강하게 들었습니다.

결제 과정은 꽤나 우여곡절이 많았습니다. 항해 플러스 결제를 위해 신용카드를 처음 만들었고, 12개월 할부면 한도에서 매달 조금씩 빠져나가는 줄 알았다가 전액이 한 번에 한도에 잡힌다는 사실을 뒤늦게 알게 되기도 했습니다. 결국 한도가 더 높은 카드를 하나 더 만들게 되었고, 두 번째 카드 배송을 기다리던 중 스파르타 측에서 “신청서는 작성하셨는데 아직 결제가 안 되어 있어서요. 혹시 특별한 사유가 있으실까요?” 라는 전화를 받기도 했습니다. 지금 생각해보면 한 명의 수강생이라도 놓치지 않으려는 영업적인 이유였을지도 모르겠습니다. 하지만 당시의 저는 “와, 여기는 진짜 한 명 한 명을 신경 써주는구나”라며 괜히 감동을 받았던 기억이 납니다.

그렇게 저는 항해 플러스 7기에 합류하게 되었습니다.

사전 스터디, 그리고 팀장이 되기까지

정규 과정이 시작되기 전, 저는 사전 스터디부터 참여했습니다. 보통 스터디를 시작하면 팀장을 정하게 됩니다. 사전 스터디 채널이 생성되고 인삿말을 남기는 분위기였는데, 이상하게도 먼저 말을 꺼내면 팀장을 맡게 될 것만 같은 기분이 들었습니다. 그래서 일부러 인사를 미루고 있었습니다. 이유는 단순했습니다. 팀장을 하고 싶지 않았기 때문입니다. 지금은 팀장을 잘 해줬다는 말을 종종 듣지만, 항해 이전의 저는 팀장이라는 역할에 대해 속이 메스꺼워질 정도의 거부감이 있었습니다.

팀장을 피하게 된 이유

대학교 재학 당시, 저는 멋쟁이사자처럼이라는 개발 동아리를 운영한 경험이 있습니다. 학교에 멋사가 처음 생겼던 1기에는 운영진으로 참여했고, 다음 기수에는 학교 대표를 맡게 되었습니다. 운영진으로 활동할 때는 비교적 수월했습니다. 주변에서 잘 도와주었고, 큰 부담을 느끼지 않았습니다.

문제는 대표가 된 이후였습니다. 신규 동아리라는 특성상 동아리의 모든 기반을 새로 만들어야 했고, 다음 기수부터는 조금 더 안정적으로 운영되길 바라는 마음에 운영진을 대폭 늘리는 결정을 내렸습니다. 제가 생각한 운영진 규모는 10명이었고, 공교롭게도 지원자 수 역시 정확히 10명이었습니다. 별도의 검증 과정 없이 “운영진 하시죠”라는 말로 모두 함께 시작하게 되었습니다. 시작부터 문제였습니다. 회의에 참석하지 않는 운영진이 있었고, 회의 자리에서는 대부분의 이야기를 제가 혼자 하고 있었습니다. 대답조차 돌아오지 않는 상황도 많았습니다. 결국 저는 이 사람들과는 제가 그리고 있던 방향의 활동을 함께할 수 없다고 판단했고, 운영과 기획의 대부분을 혼자 결정하고 진행하게 되었습니다. 대표라는 자리는 점점 버거워졌고, 동아리 이야기가 나오는 것 자체가 괴로워졌습니다. 제일 힘들었던 순간은 중앙 해커톤이었습니다. 운영진 두 명이 사전 연락 없이 행사에 불참했고, 하필 그 두 사람은 같은 팀이었습니다. 그 팀의 부원들은 코드 한 줄 제대로 작성해보지 못한 채 밤을 새워야 했습니다.연락은 닿지 않았고, 제가 할 수 있는 일은 아무것도 없었습니다. 저는 저의 리더십에 굉장한 의구심을 품게 되었고, 나의 1년은 실패했나? 라는 의문에 나의 1년은 큰 실패였다고 확신해버린 순간이었습니다. 그 이후로 저는 팀장, 대표, 회장 같은 역할을 의식적으로 피하게 되었습니다. 또 실패할까 두려웠고, 다시 그런 감정을 겪고 싶지 않았기 때문입니다.

나의 멋쟁이사자처럼은 안녕하지 않았다. 매우.

다시 회고글로 돌아와보면, 이런 이유로 저는 사전 스터디 채널에서도 최대한 조용히 있으려고 했습니다. 킥오프 일정 이야기를 꺼내는 순간 팀장이 될 것 같다는 생각이 들었기 때문입니다. 하지만 이상하게도 아무도 킥오프 일정에 대해 이야기를 하지 않았습니다. 다음 주부터 스터디를 진행하려면 일정을 빨리 정해야 하는 상황이었는데도 말입니다.

결국 조바심이 나서 제가 먼저 킥오프 일정을 제안하게 되었습니다. 그리고 킥오프 당일, 예상했던 일이 현실이 되었습니다. “오늘 팀장을 정해야 하는데, 혹시 하고 싶으신 분 계신가요?” 라고 여쭤봤을 때

“재현님이 하시면 되겠는데요…”

그렇게 저는 팀장이 되었습니다.

미팅이 끝난 뒤, 불안함과 막막함이 한꺼번에 몰려왔습니다. 팀원들에 대한 불안이 아니라, 내가 잘 해낼 수 있을까에 대한 두려움이었습니다. 하지만 이전의 경험과는 달리 사전 스터디는 굉장히 원활하게 진행되었습니다. 함께하는 분들이 모두 좋으신 분들이었고, 해야 할 일도 많지 않았습니다.

아쉬움으로 남은 한 가지

한 가지 아쉬운 점이 있다면, 사전 스터디 기간 동안 팀원분들과 조금 더 일찍 이야기를 나누지 못했다는 점입니다.

스터디 진행 방식은 단순했습니다. 매주 랜덤으로 발표자를 정해 발표를 진행하고, 발표가 끝나면 바로 마무리했습니다. 저는 사실 대화를 좋아하는 편이라 스터디가 끝난 뒤에도 이런저런 이야기를 나누고 싶었지만, 시간이 늦기도 했고 직장을 다니는 분들께 부담이 될까 봐 항상 “수고하셨습니다”라는 말과 함께 바로 종료했습니다.

마지막 스터디 날, 그대로 끝내기엔 너무 아쉽다는 생각이 들었습니다. 이대로 친해지지 못하고 끝내버리기엔 우연한 이 인연이 소중했기에 용기를 내어 이야기를 꺼냈고, 놀랍게도 처음 대화를 나눈 게 맞나 싶을 정도로 대화는 자연스럽게 이어졌습니다. 1~2시간 가까이 이야기를 나눴던 것 같습니다. 중간에 팀원분들이 내가 대화하고 싶은게 느껴졌다는 이야기도 들었습니다...ㅎㅎ 애니 이야기를 많이 했는데, 그때 당시 귀멸의 칼날에 빠져있던 저는 귀멸의 칼날 이야기를 엄청 했던 기억이 납니다. 저는 애니를 많이 보지는 않았어서 애니 초보 취급을 받기도 했습니다.

그렇게 애니 고수분들의 추천작을 급하게 따라 적기도 했습니다. 저기서 아직 체인소맨 밖에 보지를 못했는데, 진격의 거인을 다 보고 나서 하나하나씩 봐야겠습니다.

마무리하며

돌아보면 항해 플러스 시작부터 도전의 연속이었습니다. 제가 피하고 있던 감정과 역할을 다시 마주하게 만든 도전이었습니다. 이후 글에서 항해 플러스 정규 과정의 이야기를 정리해보려 합니다.

테오가 노리신 걸까요...??!? 👀

들어가면서

이번 주차에서는 디자인 패턴과 함수형 프로그래밍 그리고 상태 관리 설계 라는 주제를 가지고 학습을 진행했습니다.

이번 과제를 통해, 응집된 코드를 역할과 관심사에 따라 분리하는 작업의 중요성을 체감했습니다. 약 1,100줄 규모의 서비스 코드를 리팩토링하며 계산 로직과 액션 로직을 분리하고, 도메인별 커스텀 훅을 구성해 로직을 모듈화했습니다. 또한 전역 상태 관리를 도입하여 props drilling 문제를 해소하는 과정에서, 전역 상태 관리가 필요한 이유에 대해 다시 고민할 기회를 얻었습니다.

처음 1,100줄 가량의 App.tsx 파일을 마주했을 때 가장 먼저 든 생각은 ‘파악하기 어렵다’는 점이었습니다. state, 함수, UI 로직이 한 파일에 모두 응집돼 있어 각 함수의 역할이나 UI가 어떤 state를 참조하는지 빠르게 이해하기 어려웠습니다. 이에 우선 Header, Notification, Page의 세 영역으로 코드를 분리한 뒤, Page 단에서 하위 컴포넌트를 세분화하는 방식으로 구조를 재정리했습니다.

프로젝트의 핵심 도메인을 cart, product, coupon, notification 네 가지로 정의하고, 각 도메인별 로직을 최대한 분리하는 방향으로 리팩토링을 진행했습니다. 도메인별 state와 액션 함수는 커스텀 훅으로 분리하고, 계산 로직은 유틸 함수로 이동시켜 함수 목적을 명확히 구분하고자 했습니다.

이러한 분리 작업을 통해 도메인별 비즈니스 로직과 UI 로직의 구조가 훨씬 명확해졌습니다. 특정 엔티티의 기능을 수정할 때 해당 영역의 파일만 확인하면 되기 때문에 유지보수 효율성 역시 크게 개선될 수 있음을 체감했습니다.

아울러 전역 상태 관리의 도입 이유에 대해서도 생각해볼 수 있었습니다. 과제를 할 때만 해도 전역 상태 관리를 props drilling 해소를 위한 수단으로만 인지하고 있었지만, 다른 분들의 PR을 보면서 핵심 목적이 계층 분리에 있다는 관점을 접하게 되었습니다. UI 컴포넌트가 도메인 props에 직접 의존하지 않고 전역 store에서 필요한 상태를 조회함으로써 UI와 도메인이 분리된다는 점이 인상적이었습니다. 또한 서버 상태와 클라이언트 상태를 구분해 관리하기 위해 전역 상태 관리를 도입한다는 의견도 살펴보며, 전역 상태 관리의 필요성에 대해 다양한 관점에서 고민할 수 있었습니다.

👍 Keep

좋은 말 듣기

준일님께 좋은 말을 들었어요 !!!!!!!! 저는 항상 제 실력에 대해 의문을 가지고 있었고 불안함이 컸으며 다른 분들과 비교하며 "나는 왜 이렇게 못할까?"하는 생각을 정말 많이 했는데, 준일님께 저런 좋은 말을 들으니 "내가 잘 하고 있는건가?" 하는 생각을 조금은 할 수 있었습니다. 항상 주눅 들어 있던 저에게 조금은 희망찬 이야기를 들을 수 있어서 좋았어요 ㅎㅎ

다음에도 다른 분들께 좋은 피드백을 들을 수 있도록 열씸히 해야겠어요 !! 🔥

‼️ Problem

지치지 않기

7주간 항해를 하면서 익숙해진 것인지 지친 것인지 잘은 모르겠지만, 이번주에 특히 무기력해지는 순간들이 많았습니다. 쉬는 시간을 주기적으로 가져가며 페이스를 잃지 않도록 해야겠어요

🔥 Try

지식 공유회 발표 해보기?

항해를 통해 스스로 부족하다고 느꼈던 부분을 보완하고자 했습니다. 지식 쌓기, 글 작성하기(문서, 회고 등등), 네트워킹 등 많은 부분을 달성했지만, 남은 목표 중 하나인 발표를 한 번 도전해볼까? 하는 생각이 듭니다. 내 발표가 다른 분들께 도움이 될까?, 준비가 미흡하면 어떡하지? 등과 같은 이유로 발표하는 것을 꺼려했는데.... 코치님들과 많은 분들이 강조해온 회고를 해볼 겸, “여러분들의 항해는 안녕하십니까?”라는 주제로 한 번 시도해볼까? 싶은 생각이 듭니다..!

7기 분들 모두 10주간의 항해 과정을 돌아보며, 스스로 만족했던 부분과 아쉬웠던 부분을 정리해보는 시간을 가져볼 수 있도록 하고 싶은 마음이 있답니다..ㅎㅎ
따라서 좋은 방향이든 나쁜 방향이든 “이번 항해가 정말 뜻깊었다”라는 생각으로 7기 활동을 마무리할 수 있도록 하는 발표를 조심스럽게 구상해보고 있어요....!!

마무리하면서

이번주는 항해분들과 함께했던 시간이 많았던 것 같습니다. 사전 스터디 팀원분들과 인생 곱창, 인생 슈붕을 배우며 모각코도 했고, 1팀과도 모각코를 했으며 금요일에는 1팀, 2팀분들과 맛있는 저녁도 먹고 밤샘 모각코도 했습니다...ㅋㅋㅋㅋ 적다보니 지칠만 했던 것 같네요😂 이정도면 모각코를 안 하면 죽는 병에 걸린 게 아닐까요? 하지만 혼자 할 때보다 다른 분들과 모각코를 할 때 집중도 더 잘되고, 개발 이야기도 많이 할 수 있어서 유익한 시간이었다는 것은 분명해요 ㅎ.ㅎ

7팀에서 모모모(모르는 것을 모르는 사람들의 모임)라는 좋은 활동을 기획, 공유 해주셔서 과제에 대한 고민, 막히는 부분들 해결하는데 많은 도움이 되었습니다. 7팀 감사합니다 !!🔥

이제 항해도 3주밖에 남지 않았는데, 남은 3주는 정말 천천히 아주 천천히 지나갔으면 좋겠습니다.

항상 열심히 해왔던 것 처럼 이번주도 후회하지 않도록 빠이팅 나 자신🔥

월요일이라 신난 저희의 모습입니다. 하핫 (저희의 모습을 남겨준 오스카이 감사합니다) 목요일에 밤샐 거라는 사실도 모른 채 해맑게 뛰어다니는 모습이 귀엽지 않나요?

이제 과제하는 것이 익숙해졌는지, 월요일이 오히려 즐거워졌습니다. 이거… 미쳐가는 걸까요?

들어가면서

6주차에는 UI 컴포넌트 모듈화와 디자인 시스템이라는 주제로 과제를 진행했습니다.

평소 관심이 있었던 분야인 디자인 시스템에 대해서 다뤄볼 수 있었고 키우고 싶었던 능력인 컴포넌트 분리에 대해서 고민해볼 수 있었습니다. 1주일이라는 시간이 너무나도 짧게 느껴졌던 만큼 나중에 과제를 다시 진행해보며 더 깊은 고민을 해보고 싶습니다 :)

컴포넌트 분리에 대해

<button onClick={onClose} className="alert-close">
    ×
</button>

버튼에 alert-close 클래스가 특정 위치에서만 사용되는 상황이라, 이를 공통 버튼 컴포넌트의 variant로 분리할지, 아니면 AlertCloseButton과 같은 전용 컴포넌트로 분리할지 고민이 되었습니다.

모각코 참여자들과 코치님의 피드백을 들으면서, 이 고민에 정답은 없지만 제 나름의 컴포넌트 분리 기준을 세워볼 수 있었습니다.

저는 공통 버튼 컴포넌트를 기본으로 두고, 추가 기능이나 별도 디자인이 필요한 경우에는 새로운 컴포넌트를 생성해 공통 버튼을 래핑하는 방식을 선택했습니다. 공통 컴포넌트 내부에 ‘닫기’와 같은 특수 기능 옵션을 추가하면, 해당 컴포넌트가 정말 공통용으로 유지될 수 있을지 의문이 들었기 때문입니다. 따라서 공통 버튼은 최대한 범용적으로 유지하고, 기능·디자인이 확장되어야 하는 경우 별도 컴포넌트로 분리해 공통 컴포넌트의 재사용성과 유지보수성을 확보하는 방향을 택했습니다.

import { cn } from "@/lib/utils";
import { Button } from "./button";

export const CloseButton = ({ ...props }: React.ComponentProps<"button">) => {
  return (
    <Button
      variant="none"
      size="none"
      className={cn([
        "text-[24px] w-[24px] h-[24px] shrink-0 leading-1 outline-none focus:outline-none rounded-full",
        props.className,
      ])}
      {...props}
    >
      {props.children || "×"}
    </Button>
  );
};

디자인 토큰에 대해

제가 과제를 하면서 고민했던 부분 중 하나는 디자인 토큰을 3단계 토큰 구조로 관리 해야할까? 였습니다. 그 전에 3단계 토큰 구조에 대해서 간략하게 적어봅시다.

Primitive Tokens

: 색상값이나 크기값 등의 기본값을 가지는 가장 기본적인 토큰. 3단계 토큰 구조의 첫 번째 계층

--blue-200 : #1976d2;

Semantic Tokens

: Primitive 토큰을 값으로 가지는 두 번째 계층. Primitive에 의미와 사용 목적을 부여한 계층. 의미론적 네이밍이 특징입니다. (브랜드 컬러 등등)

--color-primary: var(--blue-200);

Component-Specific Tokens

: 특정 컴포넌트에서만 사용하도록 범위를 더욱 좁힌 토큰. 이를 통해 디자인 토큰의 변화와 컴포넌트를 분리합니다.

--color-btn-primary: var(--color-primary);

디자인 토큰을 3단계 레이어로 나누면, 브랜드 컬러 등 변경 사항이 생겼을 때 코드 전체를 수정할 필요 없이, 디자인 토큰 값만 변경하여 전체에 적용할 수 있습니다.

디자인 토큰을 3단계 토큰 구조로 관리 해야할까?

저는 과제를 하면서 디자인 토큰을 레이어화 해서 관리해야 할까? 라는 의문이 들었습니다. 색상, 사이즈와 같은 단위의 Primitive 디자인 토큰만으로도 저는 충분히 프로젝트를 관리할 수 있을 것 같다는 생각이 들었습니다.

예를 들어

// Primitive
--blue-200: #1976d2;

// Semantic
--color-primary: var(--blue-200);

// Component
--color-btn-primary: var(--color-primary);

라는 레이어 토큰이 있을 때 Primitive - Semantic 단계까진 이해할 수 있지만 Component 단계까지 쪼갠다면 너무 과하지 않을까? 라는 생각이 들었습니다. 컴포넌트 사용단에서 "여기엔 primary 색상이 들어가야해!" 라고 한다면 bg-primary, bg-blue-200 으로 하면 충분하지 않을까? 하는 생각이 자꾸만 들었습니다. Primitive / Semantic / Component 레벨로 디자인 토큰을 관리할 때의 장점이 아직 명확하게 와닿지 않습니다. 디자인 시스템을 직접 만들거나 사용해본 경험이 없고, 규모가 큰 프로젝트를 해보지 못해서 생기는 경험 부족으로 인한 의문점이기도 한 것 같습니다.

과제 제출이 끝난 이후, 다른 분들의 PR을 보면서 어느정도 납득할 수 있었습니다. 참고 PR 디자인 토큰을 나누는 이유는 프로젝트에서 사용하는 색상, 사이즈 등을 체계적으로 구조화하여, 변경이나 추가 사항이 발생할 때 원활하게 관리하기 위해서라고 느꼈습니다. 특히 규모가 크거나 장기적으로 진행되는 프로젝트에서 빛을 발할 수 있을 것 같았습니다. 다음에 회사에서 신규 프로젝트를 진행하게 된다면, 디자인 시스템을 구축해보는 경험을 쌓아보고 싶다는 생각이 들었습니다.

👍 Keep

모각코 하기

저는 혼자 코딩을 할 때보다, 같이 모여서 코딩을 할 때 집중이 더 잘 되는 것 같습니다. 과제에 대해 이야기도 나눠보면서 인사이트를 얻어가기도 하고, 많은 분들과 네트워킹도 할 수 있는 것 같아 모각코 하길 정말 잘한 것 같습니다.

초반에는 저희 팀끼리 모각코를 하려고 했지만, 어느새 제가 다른 팀 분들을 모셔오게 되면서 모각코가 7기 문화 중 하나로 자리 잡은 것 같습니다. "이번주에는 모각코 안 하나요?" 라는 질문도 들을 정도였어요.

항상 제가 먼저 저질러 놓고 팀원분들께 양해를 구하곤 했는데, 늘 긍정적으로 받아주셔서 정말 감사드립니다. 멀리서, 또는 다른 팀임에도 모각코에 참여해주시는 모든 분들께도 정말 감사드려요! 이번주, 다음주, 항해가 끝날 때까지 모각코 함께해요!!~! 😊

‼️ Problem

시간 분배 잘 하기

이번에도 초반에는 고민할 시간을 가질 수 있었지만, 시간 분배에 실패하면서 후반부로 갈수록 AI 활용 빈도가 높아져 고민의 빈도가 많이 줄었습니다. 항해가 끝난 후에는 꼭 과제를 다시 풀어보는 스터디에 참여해야겠어요.

🔥 Try

과제 할 일 분석하기

과제 전체 내용을 파악하며, 이번 과제의 핵심 키워드는 무엇인가?, 이번 과제에서 내가 해야 할 일은 무엇인가?와 같이 시작 전 할 일을 명확히 정리하고 싶습니다. 이전에는 얼추 이해했다고 생각하고 과제를 시작하다 보면 어느 순간 내가 무엇을 하고 있는지 방향을 잃는 경우가 있었기 때문에, 다음 7주차에는 과제 분석 내용을 별도로 문서화하여 전체 그림을 보는 연습을 해보려 합니다.

마무리하면서

이번주 PR에서 정말 재밌는 PR을 발견했습니다. 소설을 써도 될 만큼의 필력을 가지고 계시더라구요. 소설보다 더 흥미롭게 읽었습니다. 저는 당돌한 신입 디자이너로 등장하더라구요...ㅎㅎ PR 내용뿐만 아니라 기술적으로도 많이 배울 수 있었던 과제 결과물이었던 것 같습니다.

항해 플러스 7기에는 실력 있는 분들이 정말 많은 것 같습니다. 초반에는 그들과 비교하며 “왜 나는 이렇게 부족하지?” 라는 생각에 저 자신을 갉아먹곤 했지만, 지금은 그들의 강점을 배우려는 방향으로 관점을 전환하려고 노력하고 있습니다. 많이 보고 적극적으로 질문하면서, 언젠가는 저도 항플 7기 분들처럼 뛰어난 실력을 갖춘 개발자로 성장하고 싶습니다.

5주차엔 나만의 React 만들기라는 주제로 과제를 진행했습니다. React의 핵심 개념에 대해 직접 구현해보고 내부 동작을 학습할 수 있었던 주차였습니다.

저는 easy 단계를 선택했고, 이 단계에서 가상 DOM을 직접 구현하고 이벤트 위임 방식을 통한 이벤트 핸들러 적용, diff 알고리즘을 적용해 렌더링 성능을 개선하는 과정을 경험할 수 있었습니다.

추후에는 hard 단계도 도전하여 react의 훅이 어떻게 이전의 상태를 관리하고 유지할 수 있는지, 컴포넌트의 라이프 사이클을 어떻게 관리할 수 있는지에 대해서 학습해보려 합니다.

가상 DOM

DOM의 형태를 본따 만든 JS 객체

실제 DOM이 다음과 같이 구성되어 있을 때

<li>
  <input type="checkbox" class="toggle" />
    todo list item 1
  <button class="remove">삭제</button>
</li>

가상 DOM은 아래와 같이 구성되어 있습니다.

virtualDom('li', null,
    virtualDom('input', { type: 'checkbox', className: 'toggle' }),
    'todo list item 1',
    virtualDom('button', { className: 'remove' }, '삭제')
),

가상 DOM의 문제점은 가독성입니다. 따라서 이를 해결하기 위해 등장한 것이 JSX라고 합니다.

이벤트 위임

각 요소마다 이벤트를 붙이는 것이 아닌, 이벤트 위임 방식으로 이벤트를 등록하는 이유는 무엇일까요?

제가 내린 결론은 아래와 같습니다.

• 각 요소마다 이벤트를 등록해야 하는 번거로움 + 메모리 낭비 방지 (메모리 사용을 줄이고 성능을 향상시키는 효과적인 방법)
• 새로운 요소가 추가 되더라도 매번 이벤트를 추가하지 않아도 됨 (동적으로 생성되는 요소들의 이벤트를 효율적으로 관리할 수 있음)

diff 알고리즘

실제 DOM과 가상 DOM을 비교하여 변경된 부분만 찾아내어 실제 DOM에 반영하는 알고리즘

oldNode와 newNode를 비교하여 변경된 부분만 찾아 실제 DOM에 반영함으로써 렌더링 성능을 향상시킨 것을 알 수 있었습니다.

updateElement(target, newNode, oldNode)라는 업데이트 함수가 있을 때

1. oldNode만 있는 경우

• oldNode를 target에서 제거합니다.

2. newNode만 있는 경우

• newNode를 target에 추가합니다.

3. oldNode와 newNode 모두 string 타입일 경우

• oldNode와 newNode의 내용이 다르다면 newNode의 내용으로 교체합니다.

4. oldNode와 newNode의 type이 다른 경우 (둘 중 하나가 string 타입이더라도 해당됩니다.)

• oldNode를 제거하고 해당 위치에 newNode를 추가합니다.

5. oldNode와 newNode의 type이 같은 경우

• oldNode와 newNode의 attribute를 비교하여 변경된 부분만 반영합니다.
  • oldNode attribute 중 newNode에 없는 것은 모두 제거
  • newNode의 attribute에서 변경된 내용만 oldNode의 attribute에 반영

이 과정을 자식 태그까지 반복하여 내용을 업데이트하게 됩니다.

👍 Keep

과제의 핵심 키워드 파악하기

지난 주차들과는 달리, 이번 주차 과제를 진행하면서 과제에서 핵심 키워드는 무엇일까?에 대한 고민을 계속 하려고 했습니다. 무작정 코드를 치는 것이 아닌, 과제의 목적을 파악하고 키워드에 대해 학습하려는 노력을 많이 했던 것 같습니다.

지난 주차의 아쉬움이었던 과제 통과를 위한 무작정 코딩에서 벗어나, 과제 핵심 키워드에 대해 고민해봄으로써 어제보다 나은 오늘의 내가 되었다는 점에서 의미 있는 한 주였습니다.

‼️ Problem

목요일 모각코 금지 🚫

이번주는 화요일, 목요일 총 2번의 모각코를 진행했는데요... 목요일 모각코는 하면 안되겠다는 생각이 들더라구요...ㅎㅎ 화요일은 집중도 잘되고 시간 대비 효율이 잘 나와 만족스러웠는데 목요일은 밤샘이 강제되는 느낌 + 마감 전날이라 오히려 집중이 잘 안되는 느낌이랄까요... 조금은 힘들었던 것 같습니다.

과제의 압박이 덜한 월, 화에 모각코하기 !

🔥 Try

hard 도전하기

easy 단계를 수행한 만큼 hard 과제도 진행하며 코치님께서 제공해주신 모든 학습 키워드 학습하기 !!!! 🔥🔥🔥🔥

마무리하면서

이번주는 중간 네트워킹이 진행되었던 주차이기도 했는데요 !! 좋은 자리를 만들어주신 매니저님과 학습 메이트님들께 감사의 말씀을 전합니다 👍 너무 재미있었고 유익했던 시간이었어요 ㅎ.ㅎ 좋은 기회로 4팀과 크라임씬 약속도 다녀올 수 있었는데 너무너무너무너무너무너무너무 재밌었습니다 😁 (다음에 또 초대해주세요 !)

학습뿐만 아니라 많은 네트워킹 기회를 가질 수 있다는 점도 항해 플러스의 큰 장점인 것 같습니다. 함께하는 분들을 알아가며 많은 자극을 받을 수 있어 좋은 것 같습니다. (항해 플러스 하길 너무너무 잘했다 !!!! 🔥)

모각코 모집 토크 중인 저희의 모습을 마지막으로 5주차 회고도 마무리 해보겠습니다 😊
(우리 제법 귀여울지도....?? 이와중에 머리에 싸커킥 날리는 영코....ㅠ)

참고 자료

• https://junilhwang.github.io/TIL/Javascript/Design/Vanilla-JS-Virtual-DOM/#_4-diff-%E1%84%8B%E1%85%A1%E1%86%AF%E1%84%80%E1%85%A9%E1%84%85%E1%85%B5%E1%84%8C%E1%85%B3%E1%86%B7-%E1%84%8C%E1%85%A5%E1%86%A8%E1%84%8B%E1%85%AD%E1%86%BC
• https://devocean.sk.com/blog/techBoardDetail.do?ID=165601&boardType=techBlog

4주차는 프레임워크 없이 SPA 만들기 라는 주제를 가지고 과제를 진행했습니다. 바닐라 JS로 SPA의 기능을 구현해보면서 리액트가 해결하고자 하는 문제를 이해하고 해결해보는 과제였습니다.

이번 과제에서 핵심 키워드는 렌더링 라이프 사이클, Router, Store를 구현해보는 것이었습니다.

이번 주차의 전략은 일단 돌아가게 구현 후 리팩토링 하면서 라이프 사이클, 라우터, 스토어를 구현하는 것이었으나, 일단 돌아가게 구현하는데 시간을 오래 사용하여 과제의 핵심 키워드에 대해 제대로 된 학습을 하지 못했습니다. 하지만 과제 주차가 끝났다고 해서 다시 못하는 것도 아니고, 항해 과정이 끝나고 나서도 과제를 다시 해볼 수 있기 때문에 추후에 핵심 키워드에 대해 충분히 고민하며 다시 진행해보려고 합니다.

👍 Keep

스스로 압박하지 않기

과제를 완벽하게 해내야 한다는 압박감, 다른 분들께서 과제에 대해서 이야기 하는 걸 들으면서 "나는 왜 이런 생각을 못해냈지?" 하는 무능함 등 3주차까지는 이러한 요소들로 인해 자신감이 많이 떨어져있던 상태였습니다. 오죽하면 항해 플러스를 하차해야하나 싶을 정도로 멘탈이 좋지 않았어요. 다행히 학습 메이트님과 페이스 체크를 할 수 있는 기회가 생겼고, 이러한 고민들을 털어 놓으면서 조금은 부담감을 내려놓을 수 있었습니다. 이번 주가 끝나면 과제 내용을 다시 안 볼 것도 아닐 뿐더러 나는 왜 못하지? 보단 "이러한 생각도 할 수 있구나 ~" 하며 다른 분들의 지식을 흡수해가는 것이 더욱 바람직한 방향이라는 것을 깨달을 수 있었습니다. 학습 메이트님 뿐만 아니라 코치님들께서도 1주 만에 모든 내용을 흡수하기는 쉽지 않다며 너무 부담감을 가지는 것보단 자신의 속도에 맞게 진행하며 학습은 언제든지 할 수 있는 것이니 부담을 가지지 말라는 조언을 많이 해주셨습니다.

어제보다 더 나은 오늘의 내가 되었다면 그것으로 충분하다 !!

‼️ Problem

시간 분배 잘 하기

이번 주차에서 아쉬웠던 점은 시간이 부족하여 핵심 키워드에 대해 많은 고민을 해보지 못한 것이었습니다. 남은 주차에서는 요일 별 계획을 세워 주차 별 핵심 키워드에 대해 고민을 해볼 수 있는 시간을 확보해보려고 합니다 !

🔥 Try

의미있는 내용 공유 해보기

과제 리뷰를 하며 아쉬웠던 점은 많은 고민을 해보지 못해 생산성 있는 이야기를 많이 하지 못하는 것입니다. 각자가 겪은 고민에 대해 이야기해보고 같은 고민을 한 사람들과 생산성 있는 이야기를 해보는 것이 목표입니다 :)

마무리하면서

무작정 사용해왔던 리액트의 내부 원리에 대해서 알아볼 수 있었던 주차였습니다. 리액트가 어떤 문제를 해결하고자 했고 어떤 방식으로 해결해냈는지 생각해보며 문제 해결을 수월하게 해낼 수 있는 개발자로 한 걸을 내딛을 수 있었습니다.

꼭 과제를 다시 진행해보며 핵심 키워드에 대해 충분히 고민해보고 그 결과를 블로그 등의 문서로 남겨보는 것을 목표로 남겨두며 4주차 회고도 마무리 해봅니다 !

들어가면서

3주차엔 완성도 있는 테스트 전략 수립하기 이라는 주제를 가지고 과제를 진행했습니다. Playwright를 활용한 e2e 테스트, Storybook + Chromatic을 활용한 시각적 회귀 테스트를 작성해보는 경험을 할 수 있었고, 테스트 코드를 도입해야 하는 상황에서 주어진 상황에 따른 최적의 테스트 전략을 선택할 수 있는 능력을 기를 수 있었습니다. 또한 FE 개발에서 사용되는 테스트의 종류에 대해서 배울 수 있었습니다.

단위 테스트

• 정의 : 함수나 메서드 등 작은 단위를 독립적으로 검증하는 테스트 (주어진 input에 대해 올바른 output을 내는지)
• 장점 : 빠른 실행 속도
• 단점 : 모듈 간 상호작용 or 전체 시스템에 대한 검증이 어려움

통합 테스트

• 정의 : 여러 모듈, 컴포넌트가 올바르게 상호작용 하는지 확인, 핵심 비지니스 기능의 로직 검증
• 장점 : 모듈 간 검증 가능
• 단점 : 모킹에 의존하게 되면 신뢰도가 낮아질 수 있다

E2E 테스트

• 정의 : 사용자 관점에서 시나리오 기반 전체 워크플로우를 검증
• 장점 : 사용자 시나리오 기반 테스트이다 보니, 핵심 비지니스 기능에 대한 시각적 확인 가능
• 단점 : 실제 API 사용을 위해선 백엔드와 협의가 필요, 테스트 실행 시간 증가

시각적 회귀 테스트

• 정의 : 공통 컴포넌트 등의 UI의 변경 사항을 시각적으로 검증
• 장점 : 직접 개발 환경을 실행하지 않아도 작업 내용을 실시간으로 확인 가능
• 단점 : 비용과 관리에 대한 부담이 존재

스냅샷 테스트

• 정의 : HTML DOM 구조를 직렬화하여 이전 스냅샷과 비교 검증
• 장점 : 빠른 컴포넌트 구조 변경 사항 확인
• 단점 : 의도된 변경 사항인지 매번 확인 필요, 스냅샷 업데이트 남발 가능성

각 프로젝트의 특성과 상황을 분석하여 적합한 테스트 전략을 세우는 것이 중요하다는 것을 이번 과제를 하면서 배울 수 있었습니다 :)

👍 Keep

최적의 테스트 코드 전략에 대해 고민해보기

이전까지는 무작정 테스트 코드를 도입하는게 좋을 것 같다는 막연한 생각을 해왔지만, Chapter 1을 마무리하면서 든 생각은 상황에 맞는 최적의 테스트 전략을 세워 효율을 극대화 하는 것이 중요하다는 것을 배울 수 있었습니다.

‼️ Problem

테스트 코드를 손으로 다 작성해야 한다 vs 테스트 코드 작성은 AI에게 맡긴다

이번 과제를 진행하면서 들었던 생각 중 하나는 내가 직접 하나하나 테스트 코드를 치기엔 시간이 오래 걸릴 것 같고, AI에게 위임하자니 실력 향상 안됨 + 100% 신뢰가 가능할까? 입니다. 실력 향상 안됨은 현재 배우고 있는 입장이기 때문에 든 생각인 것 같기도 합니다. 테스트 코드 작성법(문법 + 메서드)을 전부 다 외워두는게 좋을까 ? 라고 생각해보면 뭔가 아닌거 같고, 그렇다고 AI에게 위임을 하자니 내가 검토는 하지만 테스트 코드를 작성할 때마다 매번 AI에게 시키는 것이 과연 바람직한 방식인지 고민이 많이 됩니다.

아마도 제가 생각하는 이상적인 개발자가 도움 안받고 내 머리만으로 코드를 뚝딱뚝딱 작성하는 개발자 라고 생각해서 위와 같은 고민이 드는 것 같습니다. 예전에는 구글링, 지금은 AI를 활용하여 많은 개발자들이 개발할 때 도움을 받곤 하는데 제가 너무 구시대적인 발상을 가지고 있는 것인지도 모르겠습니다. 욕심 때문일까요 ? 강박 때문일까요 ? 정답을 보고 코드를 작성하는 건 내 성장에 도움이 안돼. 내 머리로 직접 생각해서 직접 작성해야 진정한 내 것이야 라는 생각이 자꾸만 저 스스로를 압박하는 느낌입니다.

이에 대한 질문을 PR에 남겼고, 코치님과 팀원분들이 좋은 말씀을 해주셔서 고민을 조금은 덜 수 있었습니다.

🔥 Try

사고력 기르기

개발자에게 기록 + 사고력 기반의 프로젝트 파악 능력은 정말 중요하다는 것을 느낄 수 있었습니다. 과제 수행을 위한 방법을 찾고 있던 저와는 달리, 과제 시작 전 프로젝트 전체 구조를 파악하고 설계해나가는 팀원분들의 모습을 보면서 많이 배울 수 있었습니다. 과제 마무리에 급급하여 코치님께서 의도한 학습 목표에 부합하지 못하는 모습을 보이는 것 같은데, 마무리 보다는 배움에 초점을 맞춰 마음의 여유를 가지고 과제를 할 수 있도록 노력해야겠습니다...

(과제의 의도를 파악하기, 무작정 코드부터 치지말고 과제 내용 파악 + 진행 방향성 설계해보기, 머리로만 생각하지 말고 내용, 구조가 엉망이더라도 문서로 기록하기 등등..)

마무리하면서

이번 주차에 운 좋게 BP를 받았습니다. 제가 한 고민들이 유의미했다는 점에서 보람도 있었지만, 동시에 걱정도 됩니다. 과제 수행에서 학습이 우선되어야 하는데, 무의식적으로 '통과'를 목표로 코드를 작성하고 있어 고민이 되는 부분입니다.

블랙 배지를 향한 욕심이 학습의 본질을 흐리게 만들까 우려됩니다. 이 부분은 제가 스스로 조절해야 한다는 것을 알고 있지만, 저는 아직까지 저를 다루는 것이 익숙하지 않은 듯 합니다.

남은 주차도 학습의 본질을 잊지 않고 항해 여정을 이어가야겠습니다.

이번 주차에선 AI와 테스트를 활용한 안정적인 기능 개발 이라는 주제로 과제를 진행했습니다.

TDD의 개념을 이해하고 AI를 활용한 TDD 방식을 통해 기존 서비스에 새로운 기능을 점진적으로 추가하는 과정을 경험하며 TDD의 장점을 알 수 있었고, AI를 잘 활용하는 방법에 대해 생각해볼 수 있었습니다. 또한 어렵게만 느껴졌던 AI 에이전트라는 주제에 대한 두려움을 없애주었던 주차였습니다.

TDD란?

TDD(Test-Driven Development, 테스트 주도 개발)는 실제 코드를 작성하기 전에 테스트 코드를 먼저 작성하여 기능 개발을 하는 소프트웨어 개발 방법론 중 하나입니다.

실패하는 테스트 코드를 작성하는 단계를 RED, 테스트 코드를 통과하는 최소한의 기능 코드를 작성하는 단계를 GREEN, 기능 코드에 대한 리팩토링을 진행하는 단계를 REFACTOR 단계라고 합니다.

즉, TDD는 반복적인 RED -> GREEN -> REFACTOR 단계를 거쳐 기능을 구현하는 방법론으로 이해할 수 있습니다.

AI 에이전트란?

AI 에이전트란, LLM을 핵심 엔진으로 사용하여 행동을 수행하는 '실행자'입니다. AI 에이전트는 LLM, 계획, 도구, 피드백 등의 구성 요소를 가질 수 있습니다.

즉, 사용자의 지시를 받아 LLM을 통해 답변을 생성하고 답변을 생성하는 과정에서 정의된 계획 or 도구 등을 활용하는 것을 의미합니다. 마지막엔 피드백 or 평가 단계를 두어 AI 에이전트가 스스로 적절한 결과물인지 판단하도록 할 수도 있습니다.

과제에선 AI 에이전트를 어떻게 구성했는가

이번 과제에서 저는 총 6개의 AI 에이전트를 만들었습니다. (학습 메이트님들 좀 부려먹었어요 ㅎ.ㅎ)

• Doeun : 사용자로부터 입력받은 기능에 대한 기능 상세 문서를 만드는 에이전트
• Taeyoung : 기능 상세 문서를 바탕으로 세세한 작업 단위(story)를 나누는 에이전트
• Haneul : story 별 테스트 코드를 설계하고 작성하는, 즉 TDD RED 단계를 담당하는 에이전트
• Yeongseo : 작성된 테스트 코드를 통과하는 기능 코드를 작성하는, 즉 TDD GREEN 단계를 담당하는 에이전트
• Junhyeoung : 작성된 기능 코드를 리팩토링하는, 즉 TDD REFACTOR 단계를 담당하는 에이전트
• Jaehyun : 5개 에이전트를 총괄하는 오케스트레이션 에이전트

각각의 에이전트를 개별적으로 실행했을 때는 만족스러운 결과물을 얻을 수 있었지만, 오케스트레이션 에이전트를 활용했을 때는 문제가 발생했습니다.

오케스트레이션 에이전트가 각 에이전트에게 업무를 분배하고, 각자가 역할에 맞게 작업을 수행하는 자동화된 협업 프로세스를 구축하고 싶었지만, 오케스트레이션 에이전트가 다른 에이전트를 호출하지 않고 스스로 모든 작업을 처리하려는 문제가 발생했습니다.

아직 오케스트레이션 구조를 어떻게 설계해야 할지 명확히 감이 오진 않지만, 팀원분들과 학습 메이트의 노하우를 공유받아 제 에이전트를 고도화해볼 계획입니다.

👍 Keep

두려워하지 말고 적극적으로 나서기

이번 과제를 하면서 코치님과 페어 프로그래밍을 하는 경험을 했습니다.

예전의 저였다면 내 코드가 공개되는 게 너무 부끄럽다…, 내가 짠 코드가 형편없으면 어떡하지? 이런 생각들에 사로잡혀 아예 시도조차 하지 못했을 겁니다.

두려움을 극복한 결과로 너무나도 소중한 경험을 할 수 있었습니다. 기회를 만들어주신 분들께 감사함을 전합니다🙇

다음에도 좋은 기회가 주어진다면, 주저하지 않고 적극적으로 참여하여 또 다른 귀중한 경험을 쌓고 싶습니다.

‼️ Problem

모든 걸 AI에게 위임하고자 한 것

과제 초반에는 "나보다 AI가 더 똑똑하니깐 ~" 라는 생각으로, 에이전트 설계부터 기능 구현까지 모든 과정을 AI에게 위임했습니다. 하지만 그 결과, AI가 결과물을 만들어내긴 했으나 그 결과가 올바른지 스스로 판단하기 어려운 문제가 발생했습니다. 또한 결과물의 작성 포맷을 명확히 정해주지 않다 보니 매번 다른 형태의 결과물이 생성되었고, 이로 인해 결과의 정확성을 평가하기 어려웠습니다.

이 경험을 통해 중간중간 인간의 개입이 반드시 필요하다는 것을 깨달았습니다. 결과물에 대한 판단이 이루어지지 않으면 결과물이 산으로 갈 수 있기 때문입니다. 또한 입력(input)과 출력(output)에 대한 템플릿을 제공하고, 에이전트의 작업 워크플로우를 명시적으로 설계함으로써 매번 유사한 구조와 품질의 결과물을 도출하는 것이 중요하다는 점을 배웠습니다.

🔥 Try

과제 제출 보단 학습에 의미를 두기

욕심이 많아서일까요… 자꾸만 과제를 pass 받고 싶다는 생각에 자꾸만 무리를 하게 되는 것 같습니다. 사실 과제를 통과하지 못하더라도 조금이라도 배운 것이 있다면 혹은 어제보다 더 나은 오늘의 내가 됐다면 그 자체만으로 충분히 의미가 있는데, 막상 과제 pass를 받지 못하면 실패라고 느껴져, 스스로를 괜히 옥죄이게 되는 것 같습니다. 그런 마음 때문에 오히려 스스로에게 지나친 부담을 주고, 무리하게 되는 것 같습니다.

과제 pass에 대한 압박에서 벗어나, 양질의 지식을 흡수하고 그것을 내 것으로 만드는 데 집중해야겠습니다.

마무리하면서

지난주 과제에서 0.5 BP를 받았습니다 😊 예상치 못한 결과라 더욱 기뻤고, 수료하기 전에는 BP 1번을 받아보고 싶다는 의지도 생겼습니다 ㅎ.ㅎ

아직 항해 초반이지만, 이전과 달리 변화된 부분도 있고 얻는 것도 많아, 항해 플러스를 신청하기 잘 했다는 생각이 듭니다. 남은 8주 동안에도 지금처럼 열심히 참여하여 많은 것을 배우고 얻어가기 위해 노력해야겠습니다.🔥

1주차에는 프론트엔드 테스트 코드에 대해서 다룬다.

과제를 진행하기 전까진 "테스트 코드는 작업 분량만 2배 늘려.", "이점이 뭔지 모르겠어." 와 같은 생각이 지배적이었는데, 과제를 진행하면서 생각이 바뀌게 됐다. 특히 테스트 코드는 명세서의 역할을 할 수 있다.는 말이 가장 크게 와닿았고, 2주차 발제 내용 중 하나의TTD의 개념에 대해 이해하고 나니 테스트 코드의 중요성을 깨달을 수 있었다.

과제를 하면서 테스트 코드를 처음 작성해본 탓에 초반에는 방향조차 잡지 못했지만, [테스트 환경 설정 -> 테스트 상황 발생 -> 상황에 대해 검증] 라는 틀을 잡고 작성하니 조금은 수월해졌다. 아직까지 description을 명확하게 작성하기, 중복 코드 줄이기 와 같이 테스트 코드를 작성하는데 부족함이 많지만 테스트 코드의 중요성을 깨달을 수 있었다는 점에서 의미있는 1주차를 보낸 것 같다 :)

👍 Keep

: 현재 만족하고 계속 유지할 부분

포기하지 않기

항해에 지원하면서 다짐했던 것 중 하나는 아무리 힘들고 어려워도 포기하지 않기였다.

나는 항상 무언가를 하고 나면 후회하는 경우가 많았다. 멋사를 운영했을 때, 데브코스에 참여했을 때 등등 무언가가 마무리되고 그것을 되돌아 봤을 때 후회를 한 적이 많았다. "이렇게 했다면 더 좋은 결과를 낼 수 있지 않았을까?" 와 같은 후회를 가장 많이 하곤 했는데, 항해 활동을 되돌아봤을 땐 똑같은 후회를 하고 싶지 않았다.

1주차 과제부터 접해보지 못한 영역에 대해 다뤘다보니 “쉬운 단계로 내려갈까?” 하는 생각이 들기도 했지만, 배우고 성장하기 위해 항해에 참여한 만큼 이러한 어려움은 당연한 과정이라 생각하며 회피하지 않기로 다짐했다.

과제를 완벽하게 수행했다고는 할 수 없지만, 115개의 테스트 케이스를 모두 통과했고 남은 질문에도 나름의 답변을 작성했다. 학습 메이트 태영님이 말씀하신 “어제보다 더 나은 오늘의 내가 됐는가?”라는 질문에 그렇다고 자신 있게 답할 수 있기에, 만족스러운 1주차였다고 생각한다.

‼️ Problem

: 개선이 필요하다고 생각하는 문제점

나약한 나의 집중력

과제를 진행하며 나의 고질적인 문제인 집중력 부족을 다시 한 번 느꼈다. 테스트 코드를 연속적으로 작성해야 하는데, 하나를 마무리할 때마다 집중이 흐트러지고, 다시 마음을 잡아 또 하나를 작성하면 집중이 깨지는 상황이 반복되었다. 분명 개선이 필요한 부분이다. 과제 마감일이 되어서야 집중해 남은 작업들을 마무리했지만, 평소에 꾸준히 집중해서 진행했다면 마지막 날 그렇게 고생하지는 않았을 것이다. (집중하자 나 자신...)

https://www.youtube.com/watch?v=lyeLYUCalNw

신기하게 이 플레이리스트를 들으면 집중이 잘 된다... (다른 분들도 들어주셨으면 좋겠는데 맨날 까인다...)

🔥 Try

: 문제점을 해결하기 위해 시도해야 할 것

요일 별 할 일 정리

P 성향이 90% 이상인 나에게 가장 어려운 일은 요일별로 할 일을 정리하는 것이다. 그러나 계획 없이 진행하다 보니 마지막 날에 몰아서 처리하는 경우가 많아져, 이제는 할 일 정리가 필수라는 것을 느꼈다.

마무리하면서

테스트 코드는 서비스의 명세서 역할을 할 수 있기에, 나중에 새로운 개발자가 프로젝트에 합류하게 됐을 때 기능 파악에 많은 도움을 줄 수 있다. 또한 테스트 코드가 작성되어 있으면 마음 편히 기능 수정을 할 수 있겠는 것을 체감할 수 있었다.

회사 업무에도 테스트 코드를 도입해보고 싶었지만 귀찮음 때문에 포기했었다. 그러나 이번 경험을 통해 테스트 코드의 중요성을 깨달았고, 테스트 코드에 대한 생각이 바뀐 만큼 업무에 도입하는 것을 제안해봐야겠다.

Flux 패턴

: React의 상태 관리 아키텍처 패턴. 데이터 흐름을 단방향으로 유지해 어플리케이션 상태를 예측 가능하게 만든다. (중앙 집중식 상태 관리)

• Action -> Dispatcher -> Store(Model) -> View
  • Action : 데이터를 변경하는 행위. Dispatcher에게 전달되는 객체
  • Dispatcher : 데이터 흐름을 관리하는 중앙 허브
  • Store : 상태 저장소. 상태와 상태를 변경할 수 있는 메서드
  • View : 리액트 컴포넌트

Flux 패턴을 사용하는 대표적인 상태 관리 라이브러리 : Redux

반대되는 개념인 Atomic 패턴을 사용하는 대표적인 상태 관리 라이브러리에는 zustand 등이 있다.

Redux Toolkit

: Redux를 개량한 것. 코드는 더 적게, Redux를 더 편리하게 사용하기 위해 만든 라이브러리

axios

instance

: axios.create()로 생성하는 커스텀 axios 객체

공통 설정(baseURL, headers 등)을 사전 정의해두고, API 요청 시 재사용하기 위한 용도로 사용한다. (interceptor 설정 가능)

import axios from "axios";

export const api = axios.create({
  baseURL: "https://api.example.com",
  timeout: 5000,
  headers: {
    "Content-Type": "application/json",
  },
});

// 사용 예시
import { api } from "./axiosInstance";

const getUser = async () => {
  const res = await api.get("/users/1");
  return res.data;
};

interceptor

: 요청 혹은 응답을 가로채어 로직을 삽입할 수 있는 기능

• 요청 헤더 추가 및 공통 헤더 설정
• 인증 관리
• 로그 관련 로직 삽입
• 에러 핸들링

등의 작업을 인터셉터를 통해 처리할 수 있다.

// 요청 가로채기
api.interceptors.request.use(
  (config) => {
    const token = localStorage.getItem("accessToken");
    if (token) {
      config.headers.Authorization = `Bearer ${token}`;
    }
    return config;
  },
  (error) => Promise.reject(error)
);

// 응답 가로채기
api.interceptors.response.use(
  (response) => {
    // 응답 데이터 구조 단일화
    return response.data;
  },
  (error) => {
    const { status } = error.response;
    if (status === 401) {
      // 토큰 만료 처리 등
      console.warn("인증 만료 - 로그아웃 필요");
    }
    return Promise.reject(error);
  }
);

// api/client.ts
import axios from "axios";

const client = axios.create({
  baseURL: import.meta.env.VITE_API_URL,
  timeout: 7000,
});

client.interceptors.request.use((config) => {
  const token = sessionStorage.getItem("accessToken");
  if (token) config.headers.Authorization = `Bearer ${token}`;
  return config;
});

client.interceptors.response.use(
  (res) => res.data,
  (err) => {
    if (err.response?.status === 401) {
      // refreshToken 로직 수행 가능
    }
    return Promise.reject(err);
  }
);

export default client;

Thunk

: Redux에서 비동기를 다루기 위해 사용되는 리덕스 미들웨어

Thunk 함수를 반환하는 함수, 즉 객체가 아닌 함수를 반환할 수 있도록 허용해주는 미들웨어

• dispatch를 할 때 객체가 아닌 함수를 dispatch 할 수 있게 해준다.
  • 따라서 중간에 하고자 하는 작업을 함수를 통해 넣을 수 있게 된다.

dispatch(함수) → 함수실행 → 함수안에서 dispatch(객체)

Custom hook

: 기본 hook 만으로는 중복되는 로직을 효율적으로 관리하기 어렵기 때문에, 개발자가 직접 Hook을 만들어서 사용하게 되는데, 이를 Custom hook 이라고 한다.

• React 기본 hook (useState, useEffect 등)을 조립, 확장해서 만든 사용자 정의 함수
• 상태 로직을 컴포넌트 바깥으로 추출해 재사용하기 위한 구조
• 재사용 가능 로직을 구현하기 위해 사용됨.
• use 로 시작해야하며 hook 규칙을 준수해야 한다. (컴포넌트 최상위에서 호출 등등)

throttling & debouncing

: 짧은 시간 동안 연속해서 같은 이벤트가 발생했을 때 과도한 이벤트 핸들러 호출을 방지하기 위한 기법

구현 시 setTimeout, setInterval, 클로저를 사용하는데, 이때 정리(clean up 함수 작성)가 제대로 이루어지지 않으면 메모리 누수가 발생할 수 있다.

• 메모리 누수 : 필요하지 않은 메모리를 계속 점유하고 있는 현상

throttling

: 짧은 시간 동안 연속해서 같은 이벤트가 발생했을 때, 이벤트들을 일정 시간 단위로 그룹화하여 그룹의 처음 or 마지막 핸들러만 호출되도록 하는 것. 일정 시간 간격으로 이벤트 핸들러 호출

무한 스크롤에 많이 사용

debouncing

: 짧은 시간 동안 연속해서 같은 이벤트가 발생했을 때, 마지막 이벤트로부터 일정 시간이 경과한 후에 한 번만 호출하도록 하는 것

resize 이벤트, 입력값 실시간 검색에 많이 사용

인증/인가

• 인증(Authentication) : 서비스를 이용하려는 유저가 등록된 유저인지 확인하는 절차
• 인가(Authorization) : 특정 리소스에 접근할 수 있는 권한이 있는지 확인하는 절차

http 프로토콜 통신의 특징

• 무상태 (stateless) : 서버는 클라이언트의 상태를 기억하지 않으므로, 각 요청마다 서버에서 요구하는 모든 상태 정보를 담아서 요청해야 한다.
• 비연결성 (connectionless) : 서버와 클라이언트는 연결되어 있지 않다. 서버 입장에서는 매번 새로운 요청이다. 따라서 최소한의 서버 자원으로 서버를 유지할 수 있게 해준다.

쿠키, 세션, 토큰

• 쿠키(cookie) : 서버와 클라이언트 간의 지속적인 데이터 교환을 위해 만들어진 key-value 형식의 저장소.

  • 별도로 삭제하거나 유효기간이 만료되지 않는 이상 서버와 통신할 때 자동으로 주고 받게 된다
  • 서버에 특정 API 요청을 했을 때 서버가 응답 시 header 안에 set-cookie 속성으로 쿠키 정보를 담아주면 응답을 받은 브라우저는 쿠키를 브라우저에 자동으로 저장한다.
  • 서버에 http 요청을 할 때마다 브라우저에 저장되오 있는 쿠키는 자동으로 서버에 보내진다. (동일한 Origin 혹은 CORS를 허용하는 Origin에만 쿠키를 보냄)

• 세션(sesstion) : 사용자와 서버 간의 연결이 활성화된 상태를 의미한다. (인증이 유지되고 있는 상태

• 토큰(token) : 클라이언트에서 보관하는 암호화된 인증 정보를 의미한다.

  • 서버에서 사용자 인증 정보를 보관할 필요가 없기 때문에 서버 부담을 줄일 수 있다.
  • 웹에서 인증 수단으로 사용되는 토큰은 JWT (JSON Web Token) 이 있다.

JWT

: JSON Web Token. 웹에서 인증 수단으로 사용되는 토큰

• header, payload, signature 형식 3가지 데이터로 구성되어 있다.
• 암호회된 토큰을 누구나 복호화하여 payload를 볼 수 있다. (토큰의 용도는 인증정보(payload)에 대한 보호가 아니라 위조 방지)
• 정보(payload)를 토큰화할 때 signature에 secret key가 필요하고, secret key는 복호화가 아닌 토큰이 유효한지 검증하는 데 사용됨.

리소스 접근 인가를 받기 위해 사용되는 토큰을 Access Token, Refresh Token으로 만료된 Access Token을 재발급. Refresh Token도 만료된 상태라면 재인증 필요

S3

: Amazon S3는 확장성, 데이터 가용성, 보안 및 성능을 제공하는 스토리지 서비스. 쉽게 말해 구글 드라이브처럼 파일 저장 서비스

• FTP 서버처럼 단순 파일 저장 영역으로 사용하거나 AWS 서비스의 사용 로그 저장, 정적 웹 사이트 호스팅에 사용할 수 있음.

react-router-dom이란?

: React 어플리케이션에서 클라이언트 사이드 라우팅을 구현하기 위한 라이브러리. 여러 페이지 이동을 가능하게 하는 라이브러리

사용법

1. 페이지 컴포넌트 생성
2. Router.js 작성 - url 1개당 페이지 컴포넌트 연결
3. App.js에 Router 적용

// Router.js
<BrowserRouter>
  <Routes>
    <Route path="/" element={<Home />} />
    <Route path="about" element={<About />} />
    <Route path="contact" element={<Contact />} />
    <Route path="works" element={<Works />} />
  </Routes>
</BrowserRouter>

react-router-dom 주요 hooks

• useNavigate : 코드를 통한 path 이동
• useLocation : 현재 path 정보 확인
• Link : a 태그를 대체하는 태그
  • JSX에서 a 태그를 사용해야 한다면 Link 태그를 사용해서 구현해야 함. a 태그를 사용하면 페이지가 이동하면서 브라우저가 새로고침 되기 때문

children

: 컴포넌트 태그 사이에 들어가는 내용 (props.children)

• 하위 요소로 컴포넌트를 받고 싶을 때 사용
• layout에 적용하면 공통 UI (header, footer 등) + 페이지 요소 구조로 만들 수 있다.

Dynamic Route

Dynamic Route (동적 라우팅)이란

: path에 유동적인 값을 넣어 특정 페이지로 이동하도록 구현하는 방법

• path/:id 로 설정하여 동적 페이지 이동 가능
• :id는 url에 따라 바뀌는 값. useParams hook으로 조회 가능

<Route path="page/:id" element={<Page />} />

query parameter 조회

// Works.js

import { Link } from 'react-router-dom';

const data = [
  { id: 1, todo: '리액트 배우기' },
  { id: 2, todo: '노드 배우기' },
];

function Works() {
  return (
    <div>
      {data.map((work) => (
        <div key={work.id}>
          <Link to={`/works/${work.id}`}>{work.todo}</Link>
        </div>
      ))}
    </div>
  );
}

// Work.js

import { useParams } from 'react-router-dom';

const data = [
  { id: 1, todo: '리액트 배우기' },
  { id: 2, todo: '노드 배우기' },
];

function Work() {
  const { id } = useParams(); // useParams hook을 통해 쿼리 파라미터 추출
  const work = data.find((item) => item.id === parseInt(id));
  return <div>{work?.todo}</div>;
}

// 라우터 단

<Routes>
  <Route path="/" element={<Home />} />
  <Route path="works" element={<Works />} />
  <Route path="works/:id" element={<Work />} />
</Routes>

비동기 프로그래밍

동기 vs 비동기

• 동기 : 현재 실행중인 코드가 끝나야 다음 코드가 실행되는 방식.
• 비동기 : 실행 중인 코드의 완료 여부와 무관하게 즉시 다음 코드로 넘어가는 방식. 순서 보장 X. setTimeout, addEventListener, api 서버 통신 로직이 대표적인 비동기 코드

console.log("1");
setTimeout(() => console.log("2"), 3000); // 비동기 코드
console.log("3");
// 실행 순서 → 1 → 3 → 2

콜백 지옥

: 콜백 함수 중첩이 많아져 들여쓰기가 깊어지고 가독성이 안좋아지는 문제

• 이벤트 처리, 서버 통신과 같은 비동기적 작업을 수행할 때 자주 발생
• Promise, async/await 로 해결할 수 있다

setTimeout(() => {
    console.log('아메리카노')
      setTimeout(() => {
        console.log('밍밍한 아메리카노')
        ...
    }, 500)
}, 500)

Proimse

: 비동기 작업을 표현하는 객체, 3가지 상태를 가짐

• pending : 대기
• fulfilled : 성공
• rejected : 실패

then, catch, finally

axios.get("/api")
  .then(res => console.log("성공:", res))   // 성공 시 실행
  .catch(err => console.log("실패:", err)) // 실패 시 실행
  .finally(() => console.log("항상 실행")); // 무조건 실행

async/await

• await 는 Promise가 처리될 때까지 기다렸다가 결과를 리턴
• 에러는 try ~ catch로 처리

const getWeather = async () => {
    try {
        const response = axios.get('/api');
        console.log('성공' + response);
    } catch (error) {
        console.log('실패' + error);
    }
}

REST API

REST API란

: 어떤 자원에 대해 CRUD를 진행할 수 있게 HTTP method를 사용하여 요청을 보내는 것. REST 원칙을 적용하여 설계한 API

• REST
  • 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것 HTTP URL을 통해 자원을 명시, HTTP 메소드(GET, POST, PUT, PATCH, DELETE)를 통해 해당 자원에 대한 CRUD를 적용함.
  • 전반적인 웹 어플리케이션에서 상호작용 하는데 사용되는 웹 아키텍쳐 모델. 즉 자원을 주고받는 웹 상에서의 통신 체계에 있어서 범용적인 스타일을 규정한 아키텍쳐
• API 응용 프로그램을 통해 데이터를 제공받거나, 기능을 사용하고자 할 때 사용하는 인터페이스 및 규격

REST의 특징

• 균등한 인터페이스 (Uniform Interface)
  • HTTP의 표준만 따른다면 어떠한 기술이던지 접목하여 사용할 수 있다. 플랫폼이나 언어의 제약에 구애받지 않는다.
  • REST API 정의를 JSON 방식으로 많이 함. XML도 가능
• 무상태성 (Stateless)
  • 서버는 클라이언트의 상황을 고려하지 않고 API 요청에 대해서만 처리하기 때문에 이를 “상태가 없다”고 표현한다.
  • 클라이언트를 고려하지 않아도 되기 때문에 구현이 간결해진다.
• 캐싱 가능 (Cacheable)
  • REST는 HTTP 표준을 기반으로 만들어졌기 때문에 HTTP의 특징인 캐싱을 사용할 수 있다.
  • GET 메소드를 Last-Modified 값과 함께 보낼 경우, 컨텐츠의 변화가 없을 때 캐시된 값을 사용하게 된다. 이렇게 되면 네트워크의 응답시간 뿐만 아니라 API 서버에 요청을 발생시키지 않기 때문에 부담이 덜하다는 장점을 가지게 된다.
• 자체 표현성 (Self-Descriptiveness)
  • REST API 자원 명시 규칙 및 메소드는 그 자체로 의미를 지니기 때문에 어떠한 요청에 있어서 그 요청 자체로 어떤 것을 표현하는지 알아보기 쉽다.
  • API 문서를 제공하더라도 요청하는 방식만으로 어떠한 의미인지 알 수 있어야 좋은 REST API라고 할 수 있다.
  • 좋은 REST API는 요청만 보더라도 무슨 행동을 하는지 알 수 있어야 한다.
• 클라이언트 - 서버 구조 (Client-Server Architecture)
  • REST 서버가 API를 제공하는 방식이기 때문에 클라이언트에서 처리하는 부분과 독립적으로 동작한다.
  • 서로간의 의존성이 줄어들고 클라이언트와 서버를 최대한 독립적으로 개발할 수 있도록 도와준다.
• 계층형 구조 (Layered System)
  • 클라이언트는 계층형 구조가 불가능하지만 REST 서버의 경우, 보안/로드 밸런싱/암호화 등을 추가할 수 있고 Proxy 및 게이트웨이 등 중간 매체를 사용할 수 있다.

REST API의 핵심

• URL은 리소스(자원)를 표현해야 한다.
  • 리소스 명은 동사가 아닌 명사를 사용한다
  • 리소스는 Collection과 Document로 표현할 수 있다.
• 리소스에 대한 행위는 HTTP Method로 표현해야 한다.
  • GET : 리소스 조회
  • POST : 리소스 생성
  • PUT : 리소스 업데이트 (전체)
  • PATCH : 리소스 업데이트 (부분)
  • DELETE : 리소스 삭제

HTTP 상태코드

• 2xx : 성공 관련 (200 Ok, 201 Created)
• 3xx : 리다이렉션 관련 (304 Not Modified)
• 4xx : 클라이언트 에러 관련 (400 Bed Request, 401 Unauthorized)
• 5xx : 서버 에러 관련 (500 Internal Server Error)

Path Variable vs Query Parameter

• Path Variable : /users/10 와 같이 경로에 값을 포함하는 경우
• Query Parameter : /users?id=10 와 같이 ?key-value 형태로 정렬, 필터링 같은 조건 검색에 적합함

JSON

JSON이란

: JavaScript Object Notation. 자바스크립트 객체 문법을 토대로 문자 기반의 데이터 교환 형식

• 문자열, 숫자, boolean, 배열, 객체 모두 표현 가능
• JS 객체와 유사하지만 같진 않다
  • 작은 따옴표 X, 큰 따옴표만 허용

JSON method

• JSON.stringify() : JS 객체를 JSON 문자열로 변환할 때 사용

console.log(JSON.stringify({ x: 5, y: 6 }));
// "{"x":5,"y":6}"

• JSON,parse() : JSON 문자열을 JS 객체로 변환할 때 사용

const json = '{"result":true, "count":42}';
const obj = JSON.parse(json);

console.log(obj.count);
// 42

console.log(obj.result);
// true

: 컴파일러 플래그 --exactOptionalPropertyTypes을 사용하면 암시적으로 undefined를 허용하는 프로퍼티에 대한 undefined 할당이 더 이상 허용되지 않는다.

• name?: string 대신 name : string | undefined와 같이 명시적으로 undefined를 허용해야한다.

Awaited 타입 및 Promise 개선

: Awaited<> 유틸리티 타입은 무한하게 중첩된 Promise에서 값을 추출한다.

type P1 = Awaited<string>; // string
type P2 = Awaited<Promise<string>>; // string
type P3 = Awaited<Promise<Promise<string>>>; // string

Import 문에 대한 type 키워드

: Import type가 아닌 import 문에서 type 키워드를 사용하여 하나로 결합하여 불러올 수 있다.

// 이전
import { something } from './file';
import type { SomeType } from './file';

// 새로운 방식
import { something, type SomeType } from './file';

const 단언

: 상수를 정의할 때 as const를 사용하여 리터럴 타입으로 정확하게 타입 지정을 할 수 있다. 또한 객체와 배열을 readonly로 만들어서 상수 객체의 변경을 방지한다.

// 이전 방식
const obj = { name: 'foo', value: 9, toggle: false }; // { name: string; value: number; toggle: boolean; }
// 값은 일반적으로 입력되므로 어떤 값이라도 지정할 수 있습니다.
obj.name = 'bar';

const tuple = ['name', 4, true]; // (string | number | boolean)[]
// 길이와 정확한 타입은 타입에서 확인할 수 없습니다. 모든 값은 어디에나 지정할 수 있습니다.
tuple[0] = 0;
tuple[3] = 0;

// 새로운 방식
const objNew = { name: 'foo', value: 9, toggle: false } as const; // { readonly name: "foo"; readonly value: 9; readonly toggle: false; }
// "foo"로 정의되어 있고 읽기 전용이므로 값을 할당할 수 없습니다.
objNew.name = 'bar'; // type error: Cannot assign to 'name' because it is a read-only property.

const tupleNew = ['name', 4, true] as const; // readonly ["name", 4, true]
// 이제 길이와 정확한 타입이 정의되었으며 리터럴로 정의되어 읽기 전용이므로 아무 것도 할당할 수 없습니다.
tupleNew[0] = 0; // type error: Cannot assign to '0' because it is a read-only property.
tupleNew[3] = 0; // type error: Index signature in type 'readonly ["name", 4, true]' only permits reading.

클래스 내 메서드에 대한 코드 스니펫 완성

: 클래스가 메서드 유형을 상속할 때 에디터에서 해당 메서드가 코드 스니펫으로 제안된다.

인덱싱된 액세스 추론 개선 사항

: 키로 타입을 직접 인덱싱할 때 같은 객체에 있는 경우, 타입이 더 정확해진다.

interface AllowedTypes {
  'number': number;
  'string': string;
  'boolean': boolean;
}

// Record는 허용된 타입 중에서 종류와 값 타입을 지정합니다
type UnionRecord<AllowedKeys extends keyof AllowedTypes> = { [Key in AllowedKeys]:
{
  kind: Key;
  value: AllowedTypes[Key];
  logValue: (value: AllowedTypes[Key]) => void;
}
}[AllowedKeys];

// logValue 함수는 Record 값만 허용합니다.
function processRecord<Key extends keyof AllowedTypes>(record: UnionRecord<Key>) {
  record.logValue(record.value);
}

processRecord({
  kind: 'string',
  value: 'hello!',
  // 암시적으로 string | number | boolean 타입을 갖는 데 사용되는 값입니다.
  // 이제 string으로만 올바르게 추론됩니다.
  logValue: value => {
    console.log(value.toUpperCase());
  }
});

타입스크립트 추적 분석기

: -generateTrace <Output folder> 옵션은 타입스트립트 CLI에서 타입 검사 및 컴파일 프로세스에 관한 세부 정보가 포함된 파일을 생성하는 데 사용할 수 있다.

타입 파라미터를 사용하여 코드 작성 시점에서는 구체적인 자료형을 정하지 않고, 사용 시점에 타입을 지정

• <T> 형태로 많이 작성
• 타입을 매개변수처럼 다루는 문법
• 타입을 유동적으로 받기 때문에 코드 재사용성이 높아진다.
• 제네릭으로 허용되는 타입은 extends를 사용하여 제한할 수도 있다. (인터페이스 확장의 extends와 반대됨)

유틸리티 타입

Partial

: 타입의 모튼 프로퍼티를 옵셔널하게 만든다. (부분 집합 느낌)

interface Test {
  name: string;
  age: number;
}

type TestPartial = Partial<Test>;

Required

: 타입의 모든 프로퍼티를 필수로 만든다

interface Test {
  name?: string;
  age?: number;
}

type TestRequired = Required<Test>;

Readonly

: 타입의 모든 프로퍼티를 읽기 전용으로 만든다.

interface Test {
  name: string;
  age: number;
}

type TestReadonly = Readonly<Test>; // { readonly name: string; readonly age: string }

Record

: Record<K, T> => K 키 집합으로부터 T 값의 객체 생성

Pick

: 지정된 프로퍼티만 가져온다

interface Test {
  name: string;
  age: number;
}

type TestPick = Pick<Test, 'name'>; // {name: string}

Omit

: 지정된 타입을 무시한다

interface Test {
  name: string;
  age: number;
}

type TestOmit = Omit<Test, 'name'>; // {age: number}

Parameters

: 함수 타입의 매개변수를 가져온다.

function doSmth(value: string, anotherValue: number): string {
  return 'test';
}
type Params = Parameters<typeof doSmth>; // {value: string, anotherValue: number}

ReturnType

: 함수의 반환 타입을 가져온다.

type Return = ReturnType<typeof doSmth>; // string

조건부 타입

: 어떤 타입이 다른 타입과 일치하거나 확장하는지에 따라 타입을 조건부로 설정하는 것

type A = number extends number ? 'Yes' : 'No'; 
// 'Yes'
type B = string extends number ? 'Yes' : 'No'; 
// 'No'

조건부 + infer (타입 추론)

: 조건부 타입 안에서 infer 키워드를 써서 새로운 타입 변수 선언이 가능하다

type Return<T> = T extends (...args: any[]) => infer R ? R : never;

type R1 = Return<() => number>; // number
type R2 = Return<(x:string) => Promise<boolean>>; // Promise<boolean>

튜플 옵셔널 요소와 나머지

: ?를 사용하여 옵셔널한 요소를 튜플로 선언하고 나머지는 ...을 사용하여 다른 타입에 따라 선언할 수 있다.

// 만약 튜플의 길이를 정확히는 모르지만 적어도 1 이상인 경우, `?`를 사용하여 선택적인 타입을 지정할 수 있습니다.
const list: [number, number?, boolean?] = [];
list[0] // number
list[1] // number | undefined
list[2] // boolean | undefined
list[3] // Type error: Tuple type '[number, (number | undefined)?, (boolean | undefined)?]' of length '3' has no element at index '3'.

// 기존 타입을 기반으로 튜플을 만들 수도 있습니다.
// 만약 배열의 시작 부분을 패딩하고 싶다면, rest 연산자 `...`를 사용하여 패딩할 수 있습니다.
function padStart<T extends any[]>(arr: T, pad: string): [string, ...T] {
  return [pad, ...arr];
}

const padded = padStart([1, 2], 'test'); // [string, number, number]

튜플 : TS에서 길이와 각 원소의 타입이 고정된 배열

추상 클래스와 메소드

: 클래스와 그 안의 메서드는 추상적으로 선언하여 인스턴스화되지 않도록 할 수 있다.

abstract class Animal {
  abstract makeSound(): void;

  move(): void {
    console.log('roaming the earth...');
  }
}

// 확장 시 추상 메서드를 구현해야 합니다.
class Cat extends Animal {} // Compile error: Non-abstract class 'Cat' does not implement inherited abstract member 'makeSound' from class 'Animal'.

class Dog extends Animal {
  makeSound() {
    console.log('woof');
  }
}

// 추상 클래스는 인터페이스처럼 인스턴스화할 수 없으며 추상 메서드도 호출할 수 없습니다.
new Animal(); // Compile error: Cannot create an instance of an abstract class.

const dog = new Dog().makeSound(); // "woof"

생성자 시그니처

: 클래스 선언 외부에서 생성자 타입을 정의. 대부분의 경우 사용해서는 안된다.

ConstructorParameters 유틸리티 타입

: 클래스가 아닌 생성자 타입에서 생성자 매개변수를 가져오는 타입스크립트 헬퍼 함수이다.

TypeScript 4.0

가변 튜플 타입

: 튜플의 나머지 요소가 제네릭 일 수 있는 것. 여러 개의 rest 요소 사용이 허용된다.

declare function concatNew<T extends Arr, U extends Arr>(arr1: T, arr2: U): [...T, ...U];

레이블링된 튜플 요소

: 튜플 요소의 이름을 [start: number, end: number]와 같이 지정할 수 있다. 요소 중 하나에 이름이 지정된 경우, 모든 요소에 이름을 지정해야 한다.

type Foo = [first: number, second?: string, ...rest: any[]];

// 이렇게 하면 여기에서 인자의 이름을 올바르게 지정할 수 있으며 에디터에도 표시됩니다.
declare function someFunc(...args: Foo);

생성자로부터 클래스 프로퍼티 추론

: 생성자에서 프로퍼티를 설정하면 타입을 유추할 수 있으므로 수동으로 설정할 필요가 없다.

class Animal {
  // 생성자에서 타입을 할당할 때 타입을 설정할 필요가 없습니다.
  name;

  constructor(name: string) {
    this.name = name;
    console.log(this.name); // string
  }
}

JSDoc @deprecated 지원

: JSDoc, TSDoc @deprecated 태그는 타입스크립트에서 인식된다

/** @deprecated Use `NewType` instead */
type OldType = string;

type NewType = string;

const a: OldType = "hello"; // IDE에서 경고: OldType은 deprecated됨

TypeScript 4.1

템플릿 리터럴 타입

: 템플릿 리터럴을 사용하여 문자열 리터럴 타입을 조합/변형할 수 있는 기능

type ex = `Hello ${string}`;

// ex는 Hello로 시작하는 모든 문자열 타입

유니온 타입과 결합하여 조합이 가능하다.

type Lang = "ko" | "en";
type Path = `/api/${Lang}`;

// 결과: "/api/ko" | "/api/en"

제네릭, 다른 유틸리티와 결합이 가능하다.

type EventName<T extends string> = `on${Capitalize<T>}`;
type E = EventName<"click" | "hover">;
// "onClick" | "onHover"

// Capitalize : 문자열 리터럴 타입의 첫 글자를 대문자로 바꿔주는 유틸리티

매핑된 타입에서의 키 리매핑

: as 키워드를 사용해서 매핑된 타입의 키 이름을 다시 지정할 수 있다.

const obj = { value1: 0, value2: 1, value3: 3 };
const newObj: { [Property in keyof typeof obj as `_${Property}`]: number }; // { _value1: number; _value2: number; _value3: number; }

재귀적인 조건부 타입

: 자기 자신을 참조하여 타입을 점진적으로 변환하거나 분해하는 방식, 자기 자신을 다시 호출하여 복잡한 타입 연산을 수행하는 기법

type Last<T extends any[]> = 
  T extends [...infer Rest, infer L] 
    ? Last<Rest> extends never 
      ? L 
      : Last<Rest>
    : never;

// 결과
type A = Last<[1, 2, 3]>; // 3
type B = Last<['a', 'b', 'c', 'd']>; // 'd'

/// Last는 배열을 Rest와 마지막 L로 쪼갠 뒤, 재귀적으로 들어가면서 최종 L을 반환

jsDoc @see 태그를 지웒는 에디터

: 에디터에서 @see variable/type/link 태그가 지원된다.

@see : 참고 장보를 제공할 때 사용됨

/**
 * @see User
 */
type UserId = string;

interface User {
  id: UserId;
  name: string;
}

// UserId 볼 때 User 타입도 봐라

tsc -explainFiles

: ts 컴파일러에서 tsc -explainFiles 을 사용할 수 있다.

tsc -explainFiles : 컴파일에 포함된 파일과 그 이유를 설명

분해된 변수는 명시적으로 사용하지 않는 것으로 표시 가능

: 구조 분해할 때 밑줄(-)을 사용하여 변수를 사용하지 않을 것이라고 표시할 수 있음.

const [_first, second] = [3, 5];
console.log(second);

const [_, value] = [3, 5];
console.log(value);

TypeScript 4.3

프로퍼티에서 쓰기 타입 분리

: getter와 setter의 타입을 다르게 설정 가능

• getter 반환 타입은 setter 파라미터 타입의 supertype이어야 함 (읽을 때는 넓은 타입, 쓸 때는 좁은 타입 가능)

class Person {
  private _name: string = "";

  get name(): string {
    return this._name;
  }

  set name(value: string | undefined) {
    this._name = value ?? "";
  }
}

const p = new Person();
p.name = undefined; // OK (setter 허용)
console.log(p.name.toUpperCase()); // OK (getter는 string 반환)


// 읽을때는 무조건 string로 다루고, 쓸 때는 undefined도 받을 수 있도록

override

: 클래스 상속 관계에서 부모 클래스의 메서드를 자식 클래스에서 재정의할 때 사용

• 상속 시 부모 클래스의 메서드를 그대로 가져오되, 동작을 바꾸고 싶을 때 override 사용
• override 사용 시, 부모 클래스에 동일한 메서드가 없으면 에러 발생

class Animal {
  makeSound() {
    console.log("Some sound");
  }
}

class Dog extends Animal {
  override makeSound() {
    console.log("Bark!");
  }
}

const dog = new Dog();
dog.makeSound(); // Bark!

정적 인덱스 시그니처

: static [propsName: string] : string 를 사용하여 정적 인덱스 시그니처를 설정할 수 있다.

• 일반 인덱스 시그니처와 달리, 타입 수준에서 특정 집합의 키만 허용하고, 그 값의 타입을 지정하는 형태
• 정해진 키 집합에 대한 값 타입을 제한

type Roles = "admin" | "editor" | "viewer";

type RolePermissions = {
  [R in Roles]: boolean; // 각 역할은 boolean 값
};

const perms: RolePermissions = {
  admin: true,
  editor: false,
  viewer: true,
  // superAdmin: false, // ❌ Roles에 없는 키는 에러
};

// [R in Roles] => 정적 인덱스 시그니처
// 키 집합이 미리 정의

인덱스 시그니처 : 객체가 어떤 키를 가질 수 있는지, 값의 타입이 무엇인지 동적으로 정의하는 방법 [key : string] : number => 모든 문자열 키에 대해 number 타입 값 허용

jsDoc @link 태그 지원

: jsDoc, tsDoc에서 @link 태그 지원

@link : 코드나 문서, URL 등 외부 참조를 연결할 때 사용 (하이퍼링크 연결)

React에서 state는 컴포넌트 내에서 데이터와 UI 상태를 관리하는 변수. 컴포넌트 내부에서 바뀔 수 있는 값

state의 특징

• 값이 바뀌면 해당 컴포넌트가 리렌더링됨
• 불변성 유지 : state를 수정하기 위해선 직접 수정하는 것이 아닌 set 함수를 통해 변경해야 함

React에서 state를 정의할 땐 useState() hook을 사용

const [value, setValue] = useState(초기값);

불변성

불변성(immutability): 한 번 생성된 데이터는 직접 변경할 수 없다는 의미

• 원시 데이터(숫자, 문자열, 불리언 등)는 불변
  • 값이 바뀌면 새로운 메모리에 저장되고, 변수는 새 값을 참조
• 참조형 데이터(객체, 배열, 함수)는 기본적으로 가변
  • 값이 바뀌면 기존 메모리를 직접 수정함

React와 불변성

React는 이전 state와 새로운 state의 메모리 주소를 비교하여 변경 여부를 감지

• 기존 state를 직접 수정하면 메모리 주소가 변하지 않아 변화 감지 실패 → UI 갱신 X
• 따라서 state 업데이트 시 불변성을 유지해야 함
  • 배열 → [...prev, newItem]
  • 객체 → { ...prev, key: value }

순수 함수

같은 입력값에 대해 항상 같은 출력값을 반환하고, 외부 상태나 변수에 영향을 미치치 않는 함수

// 순수 함수
function add(a, b) {
  return a + b; // 입력(a, b)에 따라 항상 같은 결과
}


// 순수 함수 X
let count = 0;

function increment() {
  count += 1; // 외부 상태(count)를 변경 → 부작용
  return count;
}

• React 컴포넌트와 state 업데이트 함수는 순수 함수로 작성해야 예측 가능, 디버깅 쉬워짐
• 외부 상태를 직접 수정하거나 다른 side effects(HTTP 요청, 쿠키 조작 등)를 발생 시킨다면 UI 예측이 어려워지고 버그 발생 가능성 높아짐

컴포넌트, 렌더링

컴포넌트: UI를 구성하는 단위체 렌더링 : 현재 props와 state 상태에 따라 UI를 그리는 작업

렌더링이 발생하는 조건은

• 초기 렌더링
• state가 변경 되었을 때
• props가 변경 되었을 때
• 상위 컴포넌트가 렌더링 되면 하위 컴포넌트도 렌더링 됨
• context 값 변경 (context API 사용 시)

명령형 프로그래밍 vs 선언형 프로그래밍

• 명령형 프로그래밍 : 무엇을 할지 뿐만 아니라, 어떻게 할지를 구체적으로 기술하는 방식
• 선언형 프로그래밍 : 무엇을 할지를 기술하고, 어떻게 할지는 시스템이나 언어가 알아서 처리하는 방식

// 명령형

const numbers = [1, 2, 3, 4];
const squared = [];
for (let i = 0; i < numbers.length; i++) {
  squared.push(numbers[i] * numbers[i]);
}
console.log(squared); // [1, 4, 9, 16]


// 선언형

const numbers = [1, 2, 3, 4];
const squared = numbers.map(n => n * n);
console.log(squared); // [1, 4, 9, 16]

React Hooks

useState

컴포넌트의 상태 관리를 가능하게 하는 hook.

• 컴포넌트가 리렌더링 되더라도 이전 값을 유지.
• state를 업데이트 하기 위해선 직접 수정하는 것이 아닌 setState 함수를 통해 수정해야 함
• useState hook으로 원시 타입이 아닌 데이터를 수정 시 불변성을 유지해야함
• state 초기값으로 모든 타입이 올 수 있음. 초기값 계산이 필요한 경우 함수형 초기값 사용 가능

const [count, setCount] = useState(0)

// state를 변경하는 방법
setCount(1)
setCount((prev) => prev + 1)

일반 업데이트 방식과 함수형 업데이트 방식의 차이는?

• 일반 업데이트 방법은 setState 함수가 여러개 있더라도 일괄적으로 처리 (불필요한 렌더링을 줄이기 위해 한번에 처리)
• 함수형 업데이트 방식은 setState 함수를 호출한 만큼 로직이 실행됨

함수형 업데이트 방식이 안정적인 것 같음

useEffect

부수 효과(side effect)를 관리하기 위해 제공되는 hook

• 컴포넌트가 마운트, 언마운트 됐을 때 실행하고자 하는 함수를 제어할 수 있음
• 의존성 배열을 통해 hook callback 함수의 실행 조건을 제어할 수 있음
• useEffect hook을 한 번만 실행하고자 할 때는 의존성 배열을 빈 배열로

부수 효과(side effect : UI를 그리는 순수 연산이 아닌, 외부 환경에 영향을 주거나 외부 상태를 참조/변경하는 작업

useRef

DOM 요소에 접근할 수 있도록 하는 hook, 데이터를 담아둘 때도 사용함

• ref에 설정된 값 (current)은 컴포넌트가 계속 렌더링디어도 unmount 전까지 값을 유지함
  • 제어 컴포넌트(state), 비제어 컴포넌트(ref)

useContext

context API를 사용할 때 사용되는 hook

Provider에서 제공한 value가 달라진다면 해당 context를 구독하고 있는 모든 컴포넌트가 리렌더링 됨.

useMemo, useCallback, React.memo

최적화를 위한 hook. 불필요한 렌더링이 발생하지 않도록 하여 최적화를 도움

• useMemo : 값을 메모이제이션
• useCallback : 함수를 메모이제이션
• memo : 컴포넌트를 메모이제이션

라이프 사이클

리액트 컴포넌트가 생성되고 제거될 때 까지의 과정을 의미 Mount - Update - Unmount

• Mount : 컴포넌트가 생성될 때를 의미 (constructor(), getDerivedStateFromProps(nextProps, prevState), render(), componentDidMount())
• Update : 컴포넌트가 갱신될 때를 의미 (getDerivedStateFromProps(nextProps, prevState), shouldComponentUpdate(), render(), getSnapshotBeforeUpdate(), componentDidUpdate())
• Unmount : 컴포넌트가 DOM에서 제거될 때를 의미 (componentWillUnmount)

DOM, Virtual DOM

DOM : 페이지를 구성하는 엘리먼트(컴포넌트)를 tree 형태로 표현한 것

• tree 요소 하나하나를 '노드' 라고 표현

Virtual DOM : 가상의 DOM, 실제 DOM 구조와 동일한 복사본

• Virtual DOM 작동 원리
  • 실제 DOM과 동일한 가상의 DOM을 만들어 변경 사항을 반영. 그 후 실제 DOM과 가상 DOM을 비교하여 바뀐 부분만 실제 DOM에 적용.
  • 브라우저의 렌더링 부담을 줄여줄 수 있음. (메모리에서 가상 DOM으로 변경 사항 선 반영 후 바뀐 부분만 실제 DOM에 업데이트 하기 때문)

• Virtual DOM을 사용하는 이유
  • 사용자 인터렉션이 일어날 때마다 DOM을 조작하게 된다면, 매번 브라우저 렌더링이 실행되고 이는 성능에 많은 영향을 끼치게 됨 따라서 가상 DOM을 이용해 DOM 처리 횟수를 최소화하고 효율적으로 진행하게 해줌.

String.replaceAll(searchValue, replaceValue)

문자열 내에서 특정 문자열 또는 정규식 패턴과 일치하는 모든 항목을 새 문자열로 교체하는 메서드. 교체된 새 문자열을 반환

• searchValue에는 찾는 문자열, 전역 플래그 g가 있는 정규식 객체가 들어올 수 있음
• replaceValue에는 교체할 문자열, 매치된 값에 따라 동적으로 결과를 생성하는 함수가 들어올 수 있음

하나만 바꾸고 싶을 땐 replace, 모두 바꾸고 싶을 땐 replaceAll 사용

const text = "apple apple";

// replace (첫 번째만 치환)
console.log(text.replace("apple", "orange"));
// "orange apple"

// replaceAll (전체 치환)
console.log(text.replaceAll("apple", "orange"));
// "orange orange"

Promise.any

여러 개의 프로미스 중에서 가장 먼저 성공한(fullfilled) 프로미스를 반환하는 메서드. 모든 프로미스가 실패(rejected) 했을 때만 AggregateError와 함께 rejected됨

// 가장 먼저 성공한 결과 반환
const p1 = new Promise((_, reject) => setTimeout(() => reject("fail1"), 100));
const p2 = new Promise((resolve) => setTimeout(() => resolve("success"), 200));
const p3 = new Promise((resolve) => setTimeout(() => resolve("another success"), 300));

Promise.any([p1, p2, p3])
  .then(result => console.log(result))  // "success"
  .catch(error => console.log(error));


// 모든 Promise가 rejected일 때 => AggregateError 발생
const p1 = Promise.reject("fail1");
const p2 = Promise.reject("fail2");

Promise.any([p1, p2])
  .then(result => console.log(result))
  .catch(error => {
    console.log(error instanceof AggregateError); // true
    console.log(error.errors); // ["fail1", "fail2"]
  });

Nullish coalescing 할당 (??=)

왼쪽 피연산자가 nullish(null or undefined)일 때, 오른쪽 피연산자 값을 할당

let a = null;
a ??= 10;
console.log(a); // 10

let b = 0;
b ??= 20;
console.log(b); // 0

let c;
c ??= "default";
console.log(c); // "default"

논리적 AND 할당 (&&=)

왼쪽 피연산자가 truthy일때 오른쪽 피연산자 값을 할당

let a = 5;
a &&= 20;
console.log(a); // 20

let b = 0;
b &&= 30;
console.log(b); // 0

논리적 OR 할당 (||=)

왼쪽 피연산자가 falsy일때 오른쪽 피연산자 값을 할당

let a = 0;
a ||= 10;
console.log(a); // 10

let b = "hi";
b ||= "hello";
console.log(b); // "hi"

WeakRef

• 객체를 변수에 저장할 때 강한 참조로 관리됨. 누군가 참조하고 있는 한 GC가 해당 객체를 제거하지 않음
• WeakRef로 감싼 객체를 변수에 저장하면 약한 참조로 관리되며, 객체에 대한 다른 강한 참조가 모두 사라지면 GC에 의해 메모리에서 제거됨

주의점

• GC 타이밍은 예측 불가, 메모리에서 바로 제거 되는 것이 아님
• 캐싱, 메모리 관리 등의 상황에서만 사용 권장 (일반적인 데이터 저장 용도로는 적합하지 않음)

숫자 리터럴 구분자

숫자의 가독성을 높이기 위해 _를 사용하여 숫자를 구분

const number = 1_000_000;

ES2022

Top level await

ES 모듈의 최상위 수준에서 await 키워드를 사용할 수 있게 됨. async 래퍼 함수가 필요하지 않아 오류 처리가 개선됨

#private

# 로 시작하는 이름을 지정하여 클래스 멤버(프로퍼티, 메서드)를 비공개로 설정. 클래스 자체에서만 접근할 수 있으며 삭제 및 동적 할당 불가능 TS 프로젝트에선 이 방법을 권장하지 않음. 기존 private 키워드 사용하자

정적 클래스 멤버

클래스 멤버를 정적으로 표시 (static 키워드)

클래스에서의 정적 초기화 블록

클래스가 초기화될 때 실행되는 블록, 정적 멤버의 생성자

Import Assertions

import ... from ... assert { type: 'json' }와 같이 가져온 모듈의 타입을 단언하는 방법

정규식 매치 인덱스

정규식 일치 및 캡처 그룹에 대한 시작 및 끝 인덱스를 가져옴. RegExp.exec(), String.match() 및 String.matchAll()에서 동작

음수 인덱싱 (.at(-1))

배열, 문자열 인덱싱 시 at()을 이용하여 끝부터 인덱싱 가능 arr[arr.length - 1]과 동일 (할당은 불가능)

Object.hasOwn(obj, property)

obj.hasOwnProperty(property) 와 같이 객체가 특정 프로퍼티를 가지고 있는지 판별할 때 사용하는 메서드

객체 자체가 hasOwnProperty를 덮어쓴 경우, hasOwn 메서드를 통해 안전하게 판별할 수 있음

Error cause

error에 선택적인 원인을 지정할 수 있음.

Auto-Accessor

자동으로 프로퍼티를 비공개로 설정하고 해당 프로퍼티에 대한 get/set 접근자를 생성

• A JavaScript library for building user interfaces, 웹 or 앱 어플리케이션의 UI를 담당하는 JavaScript 라이브러리
• SPA(Single Page Application) 기반 프론트엔드 개발 라이브러리

SPA (Single Page Application)

한 개의 페이지로 이루어진 어플리케이션. MPA (Multi Page Application)과 상반된 개념

SPA vs MPA

SPA

• 한 개의 페이지로 이루어진 어플리케이션
• 전체 화면에서 일부분이 바뀌는 식으로 동작
• 최초 로딩은 느리지만 이후 로딩은 빠름
• CSR 방식 사용 시, SEO에 불리 (초기엔 빈 HTML이기 때문)

MPA

• 여러 개의 페이지로 이루어진 어플리케이션
• 페이지 중 일부만 변하더라도 페이지 전체가 리렌더링
• 매번 새로운 페이지를 렌더링 하기 때문에 로딩이 느림
• SEO에 유리 (서버로부터 만들어진 HTML을 받기 때문)

왜 React를 많이 사용할까?

• facebook(현 meta)에서 개발한 기술 스택, 꾸준한 유지보수
• 방대한 커뮤니티, 문제 발생 시 관련 자료 찾기가 쉬움
• React에 익숙해지면 RN에도 도전해볼 수 있음

컴포넌트 맛보기

컴포넌트란? 쉽게 말하면 페이지를 이루는 단위 (Header, Footer, Contents 등) React에서는 컴포넌트를 조립해서 페이지를 만든다 !

• SPA는 컴포넌트 단위로 변경사항을 반영하기 때문에 화면 깜빡임 X
• MPA는 바뀐 내용이 반영된 HTML을 다시 불러오기 때문에 화면 깜빡임 O

React에서 자주 사용되는 필수 ES6 문법

상수와 변수

이전에는 var 키워드로 변수를 선언했다면 ES6부턴 let, const 키워드를 사용해 변수, 상수를 선언한다.

• var : 재할당 가능, 재선언 가능, 함수 레벨 스코프

• let : 재할당 가능, 재선언 불가, 블록 레벨 스코프
• const : 재할당 불가, 재선언 불가, 블록 레벨 스코프

함수 레벨 스코프, 블록 레벨 스코프

• 함수 레벨 스코프 : 함수 내부에서 선언된 변수는 함수 내에서만 유효하며 함수외부에서는 참조할 수 없다.
• 블록 레벨 스코프 : 함수를 포함한 모든 코드 블록(함수, if문, for문, while문, try/catch문 등) 내에서 선언된 변수는 코드 블록 내에서만 유효하며 코드 블록 외부에서는 참조할 수 없다.

Object 선언, 단축 속성, 객체 복사

객체는 key-value 쌍으로 가짐

// 객체 선언 방법
const a = {
    name: 'abc',
      age: 1
}

const name = 'Jaehyun'
const b = {
    name, // 객체 키와 동일한 이름을 가진 변수를 적용할 때, 단축 속성을 사용할 수 있음
      age: 1
}

얕은 복사, 깊은 복사

객체나 배열을 복사할 때 참조까지 복사하느냐의 차이

얕은 복사

• 객체/배열의 1차원 값은 복사
• 객체/배열 참조는 주소만 복사 -> 원본과 복사본이 같은 참조를 공유

변수에 객체, 배열, 함수와 같은 참조 타입 데이터를 담을 때, 변수에는 데이터가 담기는 것이 아닌, 데이터의 메모리 주소(참조값)가 저장됨

const user = {
  name: "재현",
  address: { city: "Seoul" }
};

// 얕은 복사 (스프레드 연산자)
const copy = { ...user };

copy.name = "길동";
copy.address.city = "Busan";

console.log(user.name);        // "재현" (독립적)
console.log(user.address.city); // "Busan" (같이 바뀜!)

// name은 기본값이라 독립적이지만, address는 객체가 참조값을 공유 => 원본도 같이 변경됨

깊은 복사

• 중첩된 객체/배열까지 모두 새로운 메모리에 복사
• 원본과 복사본이 독립적

const user = {
  name: "재현",
  address: { city: "Seoul" }
};

// 깊은 복사 (JSON 방법)
const deepCopy = JSON.parse(JSON.stringify(user));

deepCopy.name = "길동";
deepCopy.address.city = "Busan";

console.log(user.name);        // "재현"
console.log(user.address.city); // "Seoul" (안 바뀜!)


// 두 객체는 독립적이므로 서로 영향을 주지 않음

템플릿 리터럴

백틱 (``)을 사용하여 문자열을 선언하는 방식.

• 일반 문자열 사이에 데이터를 삽입할 수 있음
• 멀티 라인 작성 가능

배열/객체 구조 분해 할당

// 객체 구조 분해 할당

const person = {
    name: 'Jaehyun',
    age: 1
}


const {name: userName, age} = person
console.log(`${userName}님, ${age}살이시네요!`); // Jaehyun님, 1살이시네요!


function hello({name, age}) {
    console.log(`${name}님, ${age}살이시네요!`);
}
hello(person); // Jaehyun님, 1살이시네요!


// 배열 구조 분해 할당

const testArr = [1, 2, 3, 4, 5];
const [val1, val2, val3, val4, val5] = testArr;

console.log(val1); // 1

let [name] = ["Tom", 10, "Seoul"];
let [, age] = ["Tom", 10, "Seoul"]; // Tom은 무시됨
let [name, age, region] = ["Tom", 10, "Seoul"];
let [name, age, region, height] = ["Tom", 10, "Seoul"]; // height는 undefined
let [name, age, region, height = 150] = ["Tom", 10, "Seoul"];

전개 연산자 (Spread Operator)

스프레드 연산자(...)는 배열, 객체, 이터러블의 요소를 펼치는 연산자. 배열, 객체, 함수 호출 등의 상황에서 자주 쓰임

const arr1 = [1, 2, 3];
const arr2 = [4, 5];

const merged = [...arr1, ...arr2]; 
console.log(merged); // [1, 2, 3, 4, 5]

// 복사
const obj1 = { name: "Jaehyun", age: 1 };
const obj2 = { region: "Seoul", age: 3 };

const merged = { ...obj1, ...obj2 };
console.log(merged); // { name: "Jaehyun", age: 3, region: "Seoul" }
// 나중에 오는 속성이 앞에 있는 속성을 덮어씀

function sum(...args) {
  return args.reduce((acc, cur) => acc + cur);
}

console.log(sum(10, 20, 30)); // 60
console.log(sum(1, 2, 3, 4, 5)); // 15

// 스프레드 연산자 사용으로 가변 인자를 전달할 수 있음

화살표 함수

• 함수 선언 시 function 키워드 대신 => 사용
• 파라미터가 1개면 () 생략 가능
• return 생략 가능
• 생성자 함수로 사용 불가 (new 키워드 사용 불가)
• this 바인딩 차이
  • 일반 함수 : 호출 방식에 따라 this가 동적으로 결정됨
  • 화살표 함수 : this가 정의된 시점의 상위 스코프로 고정됨

// 일반 함수 표현식
const add = function(a, b) {
  return a + b;
};

// 화살표 함수
const add = (a, b) => {
  return a + b;
};

// 생성자 함수로 사용 불가 예시
const Person = (name) => {
  this.name = name;
};

const p = new Person("abc"); // ❌ TypeError

React Component

컴포넌트란

• React 어플리케이션에서 UI를 구성하는 독립적인 단위 (재사용 가능한 HTML + 로직 조각)
• 재사용 가능하고, 독립성을 가지며, UI 표현 중심(props, state를 활용해 UI 출력)

컴포넌트 종류

함수형 컴포넌트

• React 16.8 이후 등장한 hooks 사용 가능, 라이프 사이클(생명주기) 메서드를 hooks를 통해 사용
• 클래스형 컴포넌트에 비해 간결한 구조를 가지고 있어 많이 사용

클래스형 컴포넌트

• hooks가 등장하기 이전에 주로 사용하던 방식, 라이프 사이클 메서드 (mount, update, unmount) 사용 가능

컴포넌트 합성 (부모 - 자식 컴포넌트)

• 컴포넌트는 다른 컴포넌트를 포함할 수 있음

JSX

JSX(JS + XML) :JS를 확장한 문법으로 JS 파일 내부에서 HTML 문법을 사용있는 문법

• 조건문은 삼항 연산자로 사용 (return 문 안에서 if 못쓰니깐)
• 반복문은 map() 메서드 사용
• 1개의 엘리먼트만 반환 (return 문 안에 최상위 태그는 1개만 존재)

Props

부모 컴포넌트가 자식 컴포넌트로 넘겨준 데이터를 props라고 함 (컴포넌트 간 state 공유 방법)

• props는 읽기 전용 데이터
• props를 받은 컴포넌트는 props를 직접 수정할 수 없다. (핸들러 함수를 같이 props로 넘겨주어 상위 컴포넌트에서 관리되고 있는 props 데이터를 변경하도록)

props drilling

최상위 컴포넌트에서 최하위 컴포넌트로 props를 넘겨주어야 할 때 중간에 의미 없이 props를 받아 그대로 넘기는 현상이 많아지는 것을 말함

• props drilling가 심해질 수록 데이터 흐름 파악이 힘들고 컴포넌트 간 결합도가 높아짐 => 유지보수 헬
• props drilling를 방지하기 위해 react의 context API, 전역 상태 라이브러리를 사용할 수 있음

children

컴포넌트 태그 사이에 들어가는 내용을 의미,

• 부모가 자식을 감쌀 때 전달 됨
• ReactNode 타입
• Layout 컴포넌트를 만들 때 자주 사용

const Card = ({children}) => {
  return <div className="card">{children}</div>;
}

// 사용 예시
<Card>
  <h1>제목</h1>
  <p>내용</p>
</Card>

구조 분해 할당으로 props 추출하기

const Card = (props) => {
  return <div>{props.name}</div>;
}

// 사용 예시
<Card name='Ahn' />

구조 분해 할당을 적용해보면

const Card = ({name}) => {
  return <div>{name}</div>;
}

// 사용 예시
<Card name='Ahn' />

로 사용 가능

defaultProps

컴포넌트에 props가 전달되지 않았을 때 사용할 기본값을 지정하는 개념

const Card = ({name}) => {
  return <div>{name}</div>;
}

Card.defaultProps = {
    name: 'Ahn'
}

• 클래스/함수형 모두 사용 가능
• TS와 호환성 문제가 있을 수 있고 최근에는 점점 안 쓰이는 추세

const Card = ({ name = 'Ahn' }) => {
  return <div>{name}</div>;
}

• 함수형 컴포넌트에서만 사용 가능
• TS와 자연스럽게 호환
• 가장 일반적이고 간단한 방법

템플릿 리터럴

백틱(``)을 사용하여 문자열을 선언하는 방식. ES6부터 백틱을 사용하여 문자열을 정의할 수 있게 됨

const name = 'Jaehyun';

console.log('My name is' + name + '. nice to meey you'); // My name is Jaehyun. nice to meet you

// 백틱 사용
console.log(`My name is ${name}. nice to meey you`); // My name is Jaehyun. nice to meet you

템플릿 리터럴 태그

템플릿 리터럴 앞에 함수 이름을 붙이면 템플릿 리터럴과 템플릿 값의 일부가 전달됨.

• 템플릿 리터럴로 선언한 문자열 앞에 함수를 붙여 기능을 붙이는 느낌

// values 길이는 2라고 가정 (템플릿 리터럴 안에 number 타입의 변수(${...})가 2개)
// reduce를 통해 식을 작성하는 것이 보통. (values의 길이를 단정지을 수 없기 때문에) 편의를 위해 아래와 같이 예시를 작성함
const formatNumbers = (strings: TemplateStringsArray, ...values: number[]) : string => {
    return strings[0] + values[0].toFixed(2) + values[1].toFixed(2) + strings[1];
}

console.log(formatNumbers`This is value: ${0}, ${4}, it's important.`) // This is value: 0.00, 4.00, it's important.

심볼(Symbols)

객체의 고유한 키값

Symbol('foo') === Symbol('foo') // false
Symbol.for('a') === Symbol.for('a') // true

Symbol() 과 Symbol.for()의 차이는?

• Symbol() : 매번 고유한 심볼을 생성. 해당 심볼의 description은 식별에 도움을 주지 않음.
• Symbol.for() : 전역 심볼 레지스트리에 등록된 심볼을 찾거나 생성. 동일한 key가 있으면 동일한 심볼을 재사용

ES2020

옵셔널 체이닝 (?.)

?. 앞의 평가 대상이 undefined나 null이면 평가를 멈추고 undefined를 반환

const user = {
  name: null
}

console.log(user.name.first) // 타입 에러
console.log(user.name?.first) // undefined

인덱싱 및 함수에도 사용할 수 있음. (ex. array?.[3], func?.())

널 병합 연산자 (??)

||과 함께 조건부 할당에 사용할 수 있는 연산자

|| vs ??

• || : 모든 falsy 값에 적용
• ?? : undefined, null에만 적용

import()

동적 import, 정적 임포트인 import ... from "..."와 비슷하지만 런타임에 동작하고 Promise를 반환하며 변수를 사용한다는 차이가 있음

String.matchAll

루프를 사용하지 않고 캡처 그룹을 포함하여 정규식의 여러 개의 일치 항목을 가져오는 메서드, str.matchAll(regexp) 와 같은 형태로 사용. (regexp는 g 플래그 필수)

• 캡쳐 그룹 : 정규식에 ()로 묶은 부분, 매치된 값이 따로 저장됨

const text = "cat, bat, rat";
const regex = /(\w)at/g;

console.log(text.match(regex));
// ["cat", "bat", "rat"]

console.log([...text.matchAll(regex)]);

/*
[
  ["cat", "c", index: 0, input: "cat, bat, rat", groups: undefined],
  ["bat", "b", index: 5, input: "cat, bat, rat", groups: undefined],
  ["rat", "r", index: 10, input: "cat, bat, rat", groups: undefined]
]
*/

const text = "2025-09-15, 2024-12-31";
const regex = /(\d{4})-(\d{2})-(\d{2})/g;

for (const match of text.matchAll(regex)) {
  const [full, year, month, day] = match;
  console.log({ full, year, month, day });
}

// { full: "2025-09-15", year: "2025", month: "09", day: "15" }
// { full: "2024-12-31", year: "2024", month: "12", day: "31" }

Promise.allSettled()

Promise 배열 중 1개라도 실패하면 즉시 reject 처리하는 Promise.all과 달리 모든 Promise가 끝날 때 까지 기다리며 실패하더라도 결과 배열에 rejected로 저장함

• 또한, Promise.all은 실패한 Promise 1개만은 반환하여 이후 Promise의 성공/실패 유무를 판단하기 까다로움 + 성공한 promise에 접근할 수 없음
• 모든 Promise의 결과가 필요할 때 유용하게 사용 가능

const promises = [
  Promise.resolve(42),
  Promise.reject("에러 발생"),
  new Promise((resolve) => setTimeout(() => resolve("done"), 1000))
];

Promise.allSettled(promises).then((result) => {
    console.log(result);
})

/*
[
  { status: "fulfilled", value: 42 },
  { status: "rejected", reason: "에러 발생" },
  { status: "fulfilled", value: "done" }
]
*/

BigInt

매우 큰 정수를 표현하기 위해 도입된 원시 타입, Number.MIN_SAFE_INTEGER ~ Number.MAX_SAFE_INTEGER 범위를 넘어가면 정확도가 낮아질 수 있음

• BigInt() 생성자 사용 시, 오류 방지를 위해 문자열과 함께 사용하는 것이 좋음.
• BigInt와 Number 타입은 연산 시 같이 사용 불가. BigInt 타입 끼리 연산, Number 타입 끼리 연산 가능

globalThis

전역 객체를 가리키는 표준화된 식별자, 환경에 따라 동일하게 전역 객체에 접근할 수 있도록 하는 메서드

console.log(globalThis); // 브라우저면 window, Node면 global

import.meta

ES 모듈 환경에서 모듈 자체에 대한 메타데이터를 담고 있는 객체

• import.meta.url : 현재 모듈 파일의 url을 반환

export * as ~~ from ...

ES 모듈에서 다른 모듈을 통째로 재추출 할 때 사용하는 방식

• 여러 유틸 함수들을~~. 로 사용할 수 있게끔 묶어서 재추출 할 때 사용

첫 FEconf는 아쉬움이 많이 남았다.

주제에 대한 이해도가 부족한 경우가 있어 내용을 제대로 흡수하지 못한 경우도 있었고, 이전 후기들을 통해 다양한 기업 부스 체험을 기대했지만 작년보다 기업 부스 갯수가 확연하게 줄어 입장 시작 1시간 만에 부스 사은품이 다 떨어진 탓에 스티커만 받아왔다. 부스 사은품이 다 떨어져 사람들이 모이지 않자 관리자분들이 자리를 비우는 경우도 있었고, 부스에 가도 아무런 액션을 취하지 않는 경우도 있었다. 여러 기업 부스에 참여해 굿즈도 받고 채용 관련 상담도 받고 싶었지만 그러지 못한 것이 아쉬웠다.

또 하나 느낀 점은, 혼자보단 지인들과 함께 왔다면 더 좋았을 것 같다는 생각이 들었다. 이번 FEconf는 네트워킹에 중점을 두었다는 느낌을 많이 받았는데 낯가림이 있는 나는 네트워킹 행사를 많이 즐기지 못했다. 지인과 함께 있었다면 조금은 수월하게 네트워킹에 참여할 수 있지 않았을까? 하는 아쉬움이 남았다.

나는 Lightning Talk 세션에 많이 참여했다. 다른 세션은 유튜브에 업로드 된다는 이야기를 듣기도 했고, 아래 사진처럼 자리를 잡지 못하면 발표 자료가 잘 안보였기 때문이다.

Lightning Talk 세션은 다른 세션보단 가벼운 주제지만, 유익한 내용을 많이 들을 수 있었다.

기억에 남는 세션은

• 비IT기업에서 개발자로 살아남기
• 킵올빌런 은퇴식
• UI 코드 생성 자동화를 프로덕션까지: 우리 팀은 Figma MCP + Cursor(AI)와 함께 일합니다

이다.

AI와 관련된 세션이 생각보다 많았고, 특히 Figma MCP + Cursor 환경을 구축해 UI 요소를 빠르게 개발할 수 있는 환경을 구축한 사례를 주제로 한 세션을 들었을 땐 나도 적용해보고 싶다는 생각이 들 정도로 흥미롭게 발표를 들었던 것 같다.

킵올빌런의 은퇴식도 직관할 수 있었다. (기억할게요 킵올빌런)

비IT기업에서 개발자로 일하고 있는 내가 취해야 할 자세도 배울 수 있었다. (티를 팍팍 내자)

메인 세션의 발표 내용을 제대로 흡수하지 못한 것은 아쉽지만, Lightning Talk 세션에서 유익한 정보와 내용을 많이 얻을 수 있었다.

다음 FEconf가 열리기 전까지 많이 성장해서 내년에는 메인 세션의 내용도 잘 흡수할 수 있었으면 좋겠다.

이 글에서는 GitHub 회사 계정과 개인 계정을 각각 SSH 키로 구분해서 사용하는 방법을 정리한다.

📁 .ssh 폴더가 없다면? 직접 만들어주기

일부 환경에서는 ~/.ssh 폴더가 기본적으로 없을 수도 있다. 이 경우 SSH 키를 저장할 수 있도록 먼저 폴더를 만들어야 한다.

mkdir -p ~/.ssh

-p 옵션은 이미 폴더가 존재해도 에러 없이 넘어가게 해줌

SSH 키는 항상 이 폴더 안에 저장됨

1️⃣ SSH 키 각각 생성 (회사 / 개인)

터미널에서 각각 아래 명령어를 입력하여 SSH 키를 생성한다.

🔹 개인 계정 키 생성

ssh-keygen -t ed25519 -C "your_personal_email@example.com"

프롬프트가 뜨면 아래처럼 입력:

~/.ssh/id_ed25519_personal

→ 엔터 2번 (패스프레이즈(비밀번호)는 생략 가능)

|#*+ .o==+        |
|== .  .=o        |
| o.E .           |
|. o   .. .       |
|oo   .. S        |
|o .  o.  o o     |
|    o o.  *      |
|   + +o.oo o     |
|ooo.+o=+oo.      |

이런 이모지 나오면 성공

🔹 회사 계정 키 생성

ssh-keygen -t ed25519 -C "your_work_email@company.com"

프롬프트가 뜨면 아래처럼 입력:

~/.ssh/id_ed25519_work

→ 엔터 2번 (패스프레이즈(비밀번호)는 생략 가능)

|#*+ .o==+        |
|== .  .=o        |
| o.E .           |
|. o   .. .       |
|oo   .. S        |
|o .  o.  o o     |
|    o o.  *      |
|   + +o.oo o     |
|ooo.+o=+oo.      |

이런 이모지 나오면 성공

📝 키 이름은 자유롭게 정해도 됨

예시:

~/.ssh/id_github_personal
~/.ssh/id_github_work

2️⃣ SSH 키 확인

ls ~/.ssh

아래 4개가 보이면 OK:

id_ed25519_personal
id_ed25519_personal.pub
id_ed25519_work
id_ed25519_work.pub

3️⃣ GitHub에 공개 키 등록

개인 github

cat ~/.ssh/id_ed25519_personal.pub

회사 github

cat ~/.ssh/id_ed25519_work.pub

명령어 입력 후 나오는 값을 복사하여 [GitHub → Settings → SSH and GPG Keys]에서 각각의 계정에 등록.

4️⃣ SSH 설정 파일 수정 (~/.ssh/config)

nano ~/.ssh/config

아래 내용 추가:

# 개인 계정
Host personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_personal
  IdentitiesOnly yes

# 회사 계정
Host work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_work
  IdentitiesOnly yes

📝 Host 이름도 자유롭게 지정 가능

예: `gh-personal`, `gh-work`, `github-jaehyun`, `office`, `home` 등
중요한 건 나중에 clone 또는 remote 설정 시 `git@:...` 형태로 쓸 거라는 점!

5️⃣ SSH 연결 테스트

ssh -T git@personal

ssh -T git@work

결과:

Hi your-username! You've successfully authenticated, but GitHub does not provide shell access.

개인 or 회사 github 계정의 이름이 나오면 성공

6️⃣ 💻 로컬에 이미 있는 프로젝트 설정

레포 클론 시, SSH 탭을 눌렀을 때 나오는 url 복사 후

  git@github.com:~~/~~.git

을

  git@personal:~~/~~.git

로 바꿔 준다고 생각하면 됨. (회사 프로젝트라면 personal 대신 work가 들어가야함.)

📁 개인 프로젝트

git remote set-url origin git@personal:username/repo.git
git config user.name "your user name"
git config user.email "your_personal_email@example.com"

🏢 회사 프로젝트

git remote set-url origin git@work:orgname/repo.git
git config user.name "Jaehyun Ahn"
git config user.email "your_work_email@company.com"

7️⃣ 📦 새로 clone 해올 때

📁 개인 계정에서 clone

git clone git@personal:username/repo.git
cd repo
git config user.name "your name"
git config user.email "your_personal_email@example.com"

🏢 회사 계정에서 clone

git clone git@work:orgname/repo.git
cd repo
git config user.name "your name"
git config user.email "your_work_email@company.com"

✅ 마무리 체크리스트

🧠 참고

• git remote -v 로 현재 remote 주소 확인 가능
• 커밋 계정 확인: git config user.name, git config user.email
• 전역 설정은 ~/.gitconfig, 레포별 설정은 .git/config에 저장됨

최근 회사에서 내가 맡은 업무 중 하나는 Next.js 프로젝트에 Presentation & Container 디자인 패턴을 적용해 UI와 로직을 나누고, Storybook + Chromatic 조합으로 시각적 회귀 테스트를 진행하는 것이었다.

최근 프로젝트에 단위 테스트를 도입하면서 코드 리팩토링까지 겸하여 진행 중인데, 이 과정에서 예기치 못한 UI 변동을 방지 하기 위해 시각적 회귀 테스트를 도입하게 되었다.

시각적 회귀 테스트란? 코드 변경 전/후의 스크린샷을 비교해 차이를 감지하고 예기치 못한 오류를 확인하여 UI의 시각적 일관성을 제공할 수 있도록 하는 테스트이다. 참고

진행 도중, 사수분께서 나에게 한 가지 요청을 하였다.

Next.js의 Script 컴포넌트가 서버 사이드에서 작동이 안되는지 확인 해줄래요?

나도 모르는 내용이었기에, 검증을 위한 테스트 코드를 작성하며 클라이언트 환경과 서버 환경을 확인하는 작업이 필요했다.

테스트 해보자🔥

Script 컴포넌트가 뭔데?

검증하기 전, Script 컴포넌트가 어떤 역할을 하는 컴포넌트인지 알 필요가 있었다.

Script 컴포넌트란 HTML의 script 태그를 최적화 해주는 컴포넌트다. 보통 script 태그는 GA를 연동하거나, 다른 웹사이트 or 기능과 상호작용이 필요할 때 사용하게 된다. 스크립트를 언제 어떻게 불러올 지 정하려면 일반 script 태그를 사용하는 것이 아닌 Next.js에서 제공하는 Script 컴포넌트를 사용하는 것이 좋다.

Script 컴포넌트는 strategy 속성을 사용할 수 있는데 속성 값은 아래 4가지를 사용할 수 있다.

• beforeInteractive : 페이지를 다 불러와서 상호작용 하기 전에 스크립트를 불러오는 것
• afterInteractive (기본값) : 페이지를 다 불러온 다음 스크립트를 불러오는 것.
• lazyOnload : 스크립트를 다른 모든 데이터나 소스들을 불러오고 나서 불러오는 전략
• worker : 실험적 속성 값으로, 아직 정식으로 사용되진 않는다.

서버 환경에서 렌더링 준비를 마친 HTML과 JS 파일을 클라이언트에 보낸 뒤, 클라이언트 환경에서 HTML과 JS 코드를 매칭시키는 과정인 Hydrate(하이트레이트) 순서와 연관지어 사용할 수 있는 속성이라고 볼 수 있다.

테스트 진행 결과는..

테스트 코드는 아래와 같이 작성했다.

// app/page.tsx
import Script from 'next/script';

export default function Page() {
  console.log('app/page.tsx 렌더링 중...');

  return (
    <div>
      <h1>Script 컴포넌트 테스트</h1>
      <Script src="/test-script.js" />
    </div>
  );
}

// public/test-script.js
console.log('🔥 script 실행됨');

서버 사이드 환경에서 Script 컴포넌트가 동작되는지 확인하기 위해 page.tsx를 서버 컴포넌트로 만든 뒤 Script 컴포넌트를 통해 test-script.js 파일을 가져오도록 코드를 작성했다.

이후 터미널에서 프로젝트르 실행해보면 서버 로그를 확인할 수 있다.

터미널과 브라우저 콘솔 창을 확인해보면 아래 사진과 같은 결과를 확인할 수 있다.

위는 서버 환경에서의 로그, 아래는 클라이언트 환경에서의 로그를 나타낸다. 이를 통해 알 수 있는 내용은,

1. page.tsx는 서버 컴포넌트로서 서버 환경에서 렌더링됐다.
2. script는 클라이언트 환경에서 실행됐다.

Script 컴포넌트를 서버 컴포넌트 내에 작성하면, 서버에서 렌더링은 되지만 실행은 클라이언트에서 되는 것을 알 수 있다.

왜 이런 결과가 나왔는지는 SSR(서버 사이드 렌더링) 과정을 살펴보면 유추해볼 수 있다.

SSR (서버 사이드 렌더링)

SSR (서버 사이드 렌더링)이란, 서버에서 페이지를 그려 클라이언트(브라우저)로 보낸 후, 화면에 표시하는 기법을 의미한다.

위 사진처럼, 사용자가 SSR 페이지에 접속한다면, 서버에서는 렌더링 준비를 마친 HTML과 JS 코드를 클라이언트에 전달하게 된다.

따라서 사용자는 페이지에 접속하면 빠르게 서비스 화면을 볼 수 있게 된다. 하지만, JS 코드는 클라이언트에서 실행되기 때문에 JS 코드 다운로드가 마무리되기 전까진 버튼을 클릭하는 등의 동작은 실행되지 않는다.

결론은 ?

따라서 Script 컴포넌트를 서버 컴포넌트 내에 작성하면, 서버에서 렌더링은 되지만 실행은 클라이언트에서 되는 이유를 SSR과 연관지어 유추해본다면

서버 사이드 렌더링 과정이 서버에서 완성된 HTML과 JS 파일이 클라이언트로 전송되어 JS 적용은 클라이언트에서 되기 때문에, strategy 속성과 관계 없이 script는 클라이언트 환경에서만 실행된다.

로 결론 지을 수 있다.

참고자료

• https://techblog.woowahan.com/17081/
• https://nextjs.org/docs/app/api-reference/components/script
• https://hahahoho5915.tistory.com/52
• https://dev-ellachoi.tistory.com/28
• https://hyunseo-fullstackdiary.tistory.com/305
• https://helloinyong.tistory.com/315