이런 유령 블로그에 방문자가?
도토리 같은 글 하나 남겨두고 잠수를 탄지 어언 4일이 지나고, 이 정도면 오래 방치했다 싶어 들어와 보니 방문자가 있더군요? 닉네임은 싱그러운 자몽이라 지어놓고는, TIL을 쓰는 지금은 곧 하루가 지날 쯤이라 축 쳐져서 생기를 잃어가며 쓰고 있습니다. 매일 양질의 TIL을 쓰는 모든 블로거 분들 존경스럽고, 저도 곧 따라가겠습니다!
※ 위에는 첫 포스팅 기념으로 잡설이 고봉밥만큼 쌓일 예정입니다. 위의 '목차'를 통해 필요한 정보만 얻어가세요.
"그렇게 시들시들한데 뭔 블로그냐?"
TIL을 쓰긴 써야하는데, 어디에 써야 할지 고민이 많았습니다. 노션이나 깃허브에 몰래 숨겨두고 쓸까? SEO가 자동으로 설정된 Velog나 지금의 Tistory는 게시하면 꼭 누가 볼 텐데, 괜히 정보의 바다에 쓸모없는 정보만 한, 두 스푼 더 흘려 넣는 건 아닐까?라는 걱정이 되었거든요. 그렇지만 저도 누군가가 낙서라고 버려둔 페이지에서, 꼬깃꼬깃 찢어진 곳 이어 붙여 원하던 정보를 얻은 적이 한두 번이 아니기 때문에, 저의 조그마한 기록과 정보가 누군가에게 도움이 되었으면 하는 마음에 시작하게 되었습니다.(사실 방문자가 있는 게 큰 대수가 아니라고 생각했는데, 생각보다 더 의지가 되네요.)
※ 내일배움캠프를 시작하기 전 프로젝트 경험
새로운 해가 밝은 2024년 초, 독학으로 다져진 실력이 어디쯤인지 알아보기 위해 호기롭게 팀 프로젝트 모집 글을 기웃기웃거리는 게 하루의 시작이었습니다. (사실 연말에도 연말이니깐 뭐 하나 해야지! 이러면서 팀 프로젝트를 도전했는데 크리스마스쯤 되니 어영부영 사라지시는 분들도 계셔서 대차게 망했습니다.)
항상 열정과 실력이 넘치시는 분들은 많으셨지만, 바로 이전에 팀이 공중분해 된 경험이 있어 기획자 1명+디자이너 1명+프론트 2명+백엔드 2명으로 안정적으로 구성되어 협업하는 프로젝트에 참여하게 되었습니다. 실제 현업에 계신 분도 계시고, 취준생인 분들도 계셔서 매주가 새롭고 정말 많이 배워갈 수 있는 3개월이었습니다. 팀만의 그라운드 룰을 만들고(이게 엄청 중요할 줄은 나중에야 알았죠), 협업 규칙도 정하고, 코드 컨벤션, 초기 개발 환경 세팅, 현업에서 사용하는 디자인 시스템 도입 등 처음 찾아보고 익히는 게 많아 밤을 지새운 적이 정말 많았지만 그만큼 감탄하며 얻어가는 것도 많았습니다. 혹여 '아직.. 프로젝트하기엔 좀 민폐인 것 같은데...'라고 생각하신다면 바로 그때가 시작할 시기라고 생각해요. 전 프로젝트 진행 중에 typescript를 주말 동안 뼈 빠지게 공부한 다음 바로 도입하고 react-query를 통한 success/error 핸들링도 처음 해봤습니다. 두려워 말고 일단 해보세요!
서류 전형에 위기 극복/갈등 해결이 있는 이유
프로젝트 시작하기 전, 순진했던 저는 서류전형에 위기 극복이나 팀원간 갈등 해결 경험이 도대체 왜 존재하는지 알지 못했습니다. 이전부터 대학 졸업까지 많은 집단을 경험했지만 타인과의 의견 충돌은 있을 수 있어도 그것이 위기라고 부르거나 갈등 해결이라고 부를 그런 거창한 건 아니었거든요.
서로 다른 4가지의 직군이 모인 이 팀에서 팀장을 맡게된 저는 그나마 프론트엔드 직군으로서 기획도 백엔드도 조금은 경험해 보았고, 디자인은 항상 관심 있던 분야기 때문에 서로의 용어나 이해가 어려운 전문 용어를 재해석해서 발언하는 등의 노력과 팀원분들의 열정까지 더해져 항상 회의는 즐겁고 평화로운 분위기로 잘 이끌어나가고 있었습니다. 그러던 어느 날 팀원 한 분이 다른 한 분의 성격을 공개적으로 문제 삼아 팀에 냉랭한 분위기가 돌았고, 엎친데 덮친 격으로 다른 한 팀원분은 개인적인 사정으로 이탈하시게 되어 새로운 팀원분이 오시는 일도 있었습니다. 때문에 개발 일정이 급한 와중에도 온전히 하루를 소모해 각 팀원분들과 이야기를 나누며 분위기를 푸는데 주력했고, 살짝의 추위와 함께였지만 프로젝트는 무난하게 마치게 되었습니다.
그렇게 우여곡절 끝에 예쁘고 화목하게 끝낸 프로젝트라는 복주머니 안에는 팀장 직을 맡았음에도 실력이 더 뛰어난 팀원과의 협업에서 오는 부담감과 함께 더 좋은 코드를 보고 배웠다는 향상감, 두 팀원간의 냉랭한 영하의 온도에서 어떻게든 불을 피웠던 경험과 이를 추억으로 곱씹으며 한층 성장했다는 양면적인 교훈들이 가득했습니다. 그럼 프로젝트도 끝났는데 이제 뭐 할까요?
프로젝트가 끝나고...
프로젝트가 끝나면 나만의 프로젝트가 시작된다는 말이 있듯이, 막상 다시 되짚어봐야 할 것들이 태산처럼 쌓여있었습니다. 하지만 그중에서도 꼭 해보고 싶은 게 있었는데, 그건 바로 '기본기를 더 쌓자'라는 것이었습니다. 촉박한 개발 일정 속 새로운 기술 스택을 익힐 때, 다른 팀원의 코드가 존재하는 상태에서 그것을 해석하고 코드 기능을 수정할 때 등 기본기는 위로 쌓아나기 이전에 더 단단하게 다지고 익혀야 한다는 것을 깨달았습니다.(우물까진 이미 팠는데, 내핵까지 뚫어야 한다는 걸 느낀 기분?)
그렇게 프로젝트를 한 번 더 할까? 아니면 독학이나 부트캠프를 할까?라는 고민은 어느 순간 기초부터 시작하는 부트캠프에 시선이 끌리기 시작했습니다. 사실 각종 커뮤니티나 현직 개발자분들이 계시는 오픈 카톡방에 문의를 하면 열이면 아홉 분이 독학을 추천했지만, 뭔가 아는 내용이라면 관성에 의해 깊게 파볼 생각 자체를 못할 것 같아 취업 전 기본부터 꼭대기까지 제대로 해보자라고 결심하게 되었습니다.
※ 스파르타 내일배움캠프?
전 음식점에 가서 메뉴를 고를 때도, 편의점 가서 김밥 하나를 고를 때도 정말 많은 고민을 하는 성격이지만 의외로 어쩔 때는 결론을 빨리 내려 주위를 당황하게 하기도 합니다. 이미 수많은 부트캠프들이 있어 각종 블로그 후기와 정보글을 보고 고민을 오래 했는데, 막상 제 시기와 맞고 풀스택이 아닌 과정은 3개 정도로 추려졌습니다. 되도록 사전 인터뷰나 코딩 테스트가 있는 곳을 가라고 많이 추천하는 걸 보았지만, 어딜 가든 스스로가 나태해지지 않고 열심히 하면 충분히 많은 것을 얻을 수 있다는 자신감도 있었고, 하루에 12시간 이상을 공부해야 하는데 그걸 각오하고 도전하시는 분들은 어떤 분일까 궁금해서 스파르타 내일배움캠프에 참여하게 되었습니다. 특히 바로 직전에 사람에 덴 경험도 있어 협업 기회가 많아 다양한 팀원분들을 만날 수 있는 곳에서 많은 분들을 보고 경험하고 싶은 마음도 있었습니다.(저 ISFJ에요! 같은 ISFJ 분들은 공감하시죠..?)
스파르타 내일배움캠프!(사전캠프)
주위에서 12시간은 힘들지 않겠냐고 걱정하기도 했지만, 이미 개발 마감 일정에 밥과 화장실을 제외하곤 하루에 일어난 적이 없는 생활을 해온지라 오히려 12시간이 짧게 느껴졌습니다.(잠은 없었습니다.. 거의 기절만 있었을 뿐😂)
본격적인 개강에 앞서 신청한 인원들은 사전캠프라는 걸 미리 진행했었는데, 본 개강일에 고작 일주일 앞서 합류해서 거의 사전캠프는 막바지 분위기였습니다. 때문에 제공해 주신 웹개발 강의와 각종 JS 자료들을 학습하고 익히는 기간만 남아있었습니다. 그래서인지 아니나 다를까, 이미 알던걸 빠르게 해치워버리는 성격을 못 버렸는지 사전캠프 과제를 뚝딱 해버리고 먼저 읽던 모던 REACT DEEP DIVE 책을 읽으러 가버렸습니다.. 아직 초심으로 돌아갈 자세가 되어있지 않다는 걸 스스로 느꼈지만, 그걸 깨달았다는 것이 사전 캠프 내 가장 큰 수확이었습니다. 그 외에도 ZEP라는 메타버스 공간에서 다 같이 학습하기 위해 모여있는 걸 보니 뭔가 신기하면서도 기대되었고, 궁금한 게 있어 문의를 넣었을 때 답변해 주시는 매니저님들 속도가 정말 빨라서 놀랐습니다.
내배캠 본 캠프 시작!(1일차. 협업시 코드 구조 고민)
아침 9시에 본 캠프 OT를 할 때, 일주일간 미니 프로젝트를 함께할 팀원들 명단을 처음으로 보았습니다. 뭔가 익숙한 이름들이 보였는데, 알고 보니 사전캠프 때 팀이랑 똑같았습니다. 팀 소개 이후 모두가 I 성향인걸 알고선 재밌는 상황이 나오기도 했지만, 제가 만나본 개발자들 중 E는 멸종 위기종 그 이상이기에 늘 그렇듯 비교적 조용하게 소개시간과 회의시간이 이어졌습니다.(팀장분이 잘 이끌어주시고 계시고, 팀원분들도 의견을... 잘 말씀해 주신다! TMI 시간 때 본 고양이와 강아지들이 너무 귀여웠어요! 아이들 파이팅~~)
사실 첫날은 고민의 연속이었습니다. OT때도 매니저님이 말씀해 주셨고, 이전의 경험상으로도 그렇고 먼저 개발을 시작해 실력차이가 있는 경우 배우는 입장에서 그저 "오... 그렇구나"라는 느낌이 강하기에 개강 첫 주차의 의미대로 웹개발 강의에서 배운 것만 활용해서 참여할 계획이었습니다. 하지만 다른 조를 보니 먼저 익히고 오신 분들을 눈치껏(?) 보니 최대한 역량을 발휘하시는 것 같아 보이고, 사수 없이 혼자 독학으로 공부해 왔기 때문에 개발 시작할 때 사수가 있었으면.. 하는 아쉬움이 얼마나 큰지 느꼈기에 최대한 도움을 드리기 위해 방향을 순회하게 되었습니다.
이런 태도에 대한 걸 차치하고 다시 프로젝트라는 걸 하게 되니 감회가 새로우면서도 스스로 뭔가 더 해보고 싶어 졌습니다. 내배캠의 1주차 팀플은 '팀 소개 페이지'라는 주제를 듣고 구글링, 유튜브, 해외 레퍼런스까지 50개가 넘는 자료들을 보고 ui/ux 직군의 결과물에서는 디자인을, React와 node.js 과정에서는 어떤 코드를 썼나 읽어보며 감각을 쌓았습니다. 기획자와 디자이너가 없어 초반 기획과정이 험난하고, 백엔드가 없어 완벽한 CRUD를 구현하기엔 어려움이 있어도, 팀원 모두가 어떻게 해야겠다는 느낌은 얻은 하루였습니다.
코드 구조에 대해 고민하다
특히 HTML, CSS, JS만을 사용하는 현재 프로젝트의 협업 시 좋은 코드 구조에 대해서 많은 고민을 했는데
1. 혼자서 개발하듯 하나의 페이지에 기능을 담고 추가적인 건 모달로 띄우는 싱글 페이지 형식이 첫 번째 방안이었고,
2. HTML, CSS, JS만을 사용하지만 리액트처럼 컴포넌트 개념을 이용해 각 기능을 쪼개는 방식이 두 번째 방식이었습니다.
첫 번째 방식은 늘 하던 방식이라 편하고 익숙하지만, 서로 협업 시 작업공간이 겹칠 수도 있었으며, CSS명의 경우 당연히 충돌 나는 걸 기정사실화 해놓고 논의해야 하는 방식이었습니다. 두 번째 방식은 학습하진 않아 러닝커브는 가파르지만, 컴포넌트에 대해서 배워가며 더 효율적인 코드 구조를 지향하는 방식이었습니다.
팀 내에서 많은 논의 끝에 각 방법마다 장단점이 있어 끝내 하나로 결정되지 못하고, 튜터님께 이 문제에 대해 문의를 드렸는데 어쩌다 보니 세 분의 튜터님께 질문할 기회가 있어 다양한 의견을 들어볼 수 있었습니다.
※ 튜터님 1. 처음엔 1번 방식만을 두고 어떻게 협업할까 팀 내에서 고민하고 있었는데, 2번의 컴포넌트를 팀에 처음 알려주시고 추천해 주셨다. 리액트만 컴포넌트가 가능한 줄 알았는데, Html과 JS를 이용해서 컴포넌트 구조를 짤 수 있다는 걸 처음 알게 되고 개인적으로 많이 찾아보게 되었다.
※ 튜터님 2. 1번 방식을 추천해 주셨습니다. 당연히 에러가 수반될 테지만, 그걸 해결해 나가며 성장하는 것도 의미가 있을 거라고 조언해 주셨습니다.
※ 튜터님 3. 각각의 방법 모두 장단점이 있다는 걸 자세히 설명해 주셨습니다. 1번에 방식에 대해 장점을 쭉 말씀하시길래 1번을 추천하시는가 싶었는데 마지막에 꺾어서 앞으로 React 과정에 앞서 컴포넌트 구조를 익히면 도움이 될 것이라고 2번 방식을 추천해 주셨습니다. 다만, 실제 컴포넌트화를 시키는 것이 아닌 개념만을 도입해 하나의 페이지 내에서 기능별로 컴포넌트를 만드는 식으로 하는 방법을 알려주셨습니다.
세 번째 튜터님의 마지막 의견을 듣고 나니 뭔가 길을 찾은 느낌에, 하나의 페이지 내에서 각자의 기능을 컴포넌트 식으로 구현하는 방식을 채택하게 되었습니다. 그러면서 1일 차가 마무리되었는데, 첫 번째 튜터님이 말씀해 주신 개념이 인상 깊어서 문서들을 찾아보았고, LIT이라는 Web Components를 구성할 수 있게 해주는 Library를 알게 되었습니다. 반드시 React를 사용해야만 Components 구조를 만들 수 있는게 아니라는 것을 깨달은 의미 있는 발견이었습니다.
내배캠 2일차가 밝았습니다.(행간 값 설정 방법, wheel 스크롤 이벤트, CSS 중복 변수명 피하기)
"한 번도 안 먹어본 사람은 있어도, 한 번 먹어본 사람은 없다"라는 말이 있듯이, 한 번 협업을 해보니 기획자와 디자이너의 부재가 더욱 뼈저리게 다가왔습니다. 때문에 오전에 플로우차트를 그리고, 오후에 디자인 시스템을 만들어보려고 했습니다. 디자인 시스템은 wanted 기업이 오픈한 디자인 시스템을 많이 참고했는데, 그걸 보니 행간을 폰트 크기의 배수로 적어놓은 것을 보고 개발 직군과 디자이너가 서로에 대한 이해와 커뮤니케이션이 확실하구나라는 걸 깨닫게 되었습니다.
+ 알게 된 점) 행간은 폰트 크기에 맞춰 바로 동적으로 변화할 수 있도록 "폰트 크기 * [일정 배수값]"의 형태로 많이 사용하여 코드 유지보수성을 높인다고 합니다. 예를 들어 40px이고 디자인 시스템에서 1.3배라고 적혀있으면 40px x 1.3을 하여 행간은 52px이 되는 셈입니다.
폰트에 대한 디자인 시스템을 마무리하니 어느덧 회의시간이 다가와 업무 분배를 하게 되었습니다. 여러 업무 중 초기 개발 환경 세팅과 wheel 스크롤 시 페이지 섹션별로 넘어가는 이벤트 구현을 맡았습니다.
먼저 wheel 스크롤 이벤트는 addEventListner를 이용해 wheel을 아래로 내리면 양수값이, 올리면 음수값이 나오는 점을 이용해 로직을 구성하였고, 해당 이벤트 발생 시 height를 100vh씩 상/하로 이동하여 새로운 페이지가 나올 수 있게 구현하였습니다. 이와 동시에 이벤트에 대한 정리된 글을 보니 생각보다 종류와 쓰임이 다양하였고, 이를 다시 한번 이 이벤트를 공부하면서 DOM의 event 동작원리에 대해서 더 알아봐야겠다는 생각을 했습니다.
초기 개발 환경 세팅은 회의 시간 때 정했던 코드 컨벤션과 규칙들을 필두로 작업하게 되었습니다. prettier와 eslint 플러그인을 사용하였고, 프로그래밍 명명 규칙(camelCase 등)을 정하였고, 가장 문제가 되었던 CSS 문제도 다음과 같은 방법으로 해결했습니다. 부득이하게 한 페이지 내에서 협업을 하게 될 시
1. 먼저 각자의 섹션을 div로 구분하고 고유의 class명을 갖도록 개인 작업 공간을 확보하였습니다.
2. 각자의 공간에서 일반적으로 CSS를 사용하면 변수명이 중복되기 때문에, 각자 부여된 class를 접두사로 가지고 그 뒤에는 _[class 이름]으로 이름을 짓도록 구상했습니다.
e.x) <div class="login"></div> // 해당 작업 공간에서 작업 시 css명은 login_submit_button처럼 명명할 수 있다.
+) 추후 튜터님 피드백: 현재 구조에서는 css를 login-submit-button과 같은 케밥(kebab-case)가 더 대중적이라고 설명해 주셨다.
이런 방식으로 CSS의 충돌을 피할 수 있을 거라 생각해 아이디어를 냈지만, 아직 CSS가 활발하게 작업될 단계가 아니기에 효용성에 대해서는 의문으로 남습니다. 그렇지만 협업을 위해 여러 코드 구조를 고민하고 생각해 봤다는 것에 큰 의의를 두며, 이와 같은 케이스가 있는지도 더 찾아보려 합니다.
사전캠프 때의 걱정과 다르게 하루가 달리 깊고 깊은 곳을 향해 파내려 가는 느낌이 드는 하루하루가 되고 있습니다. 이제 전체 과정 중 1%지만, 시작이 반이라 믿고 좋은 출발을 할 수 있도록 많이 찾아보고 익혀보려 합니다.
P.s. 혹시 지금 팀원이거나 앞으로 팀원이 되실 분이 보신다면..
"저도 열심히 질문하고 모르는 게 있으면 질문 드릴테니,
반대로 모르는게 있으시면 진짜 언제든 말씀만 주시면 열심히 돕겠습니다!!
잘하고 부족하고는 정말로 상관 없고,
배우러 온 만큼 더 많이 배울 수 있는 기회를 놓치지 않고 싶어요
(아무때나 질문/스터디/프로젝트 연락 환영입니다!)"
'TIL' 카테고리의 다른 글
| [2024.04.21] 건강관리 잘하기 + 할 일 정리 (0) | 2024.04.21 |
|---|---|
| [2024.04.20] 외부영역 클릭시 모달창 닫기(검은색 배경 수난기) (0) | 2024.04.20 |
| [2024.04.19] 가면 증후군_더 나은 개발자로 발돋움하기 (0) | 2024.04.19 |
| [2024.04.18] 토스처럼 transition 효과 주기(transition, :hover) (1) | 2024.04.18 |
| [2024.04.17] github 협업 시 Clone부터 Push까지(clone, branch, commit, push 등) (0) | 2024.04.17 |
