앞서 비즈니스 로직을 훅, 유틸로 좀더 쪼개서 분리해보는 등 타 작업도 같이 진행했었기에 당연히 그쪽 문제인 줄 알았다. 물론 당연한 건 없었다 useEffect 의존성 배열 설정이 잘못돼서 리렌더링이 트리거되지 않은 건가, 아 혹시 CSS 문제인가, 강제로 7열 그리드 멕여놓은 게 문제가 된건가? 등등 이런 고민을 약 3일간 하면서 (물론 다른 거 하느라 바쁜 것도 있었지만 아무튼 3일) 계속 고민했었는데, 문제는 그게 아니었다.

각설, 문제의 원인은 바로

display: none; 이 문제였다.

사람 눈에는 그저 요소가 눈에 보이고 vs 안 보이고 지만, 웹에서 컨텐츠를 보여줄 때는

1. DOM에 렌더링 되고 눈에도 보이는 것
vs
2. DOM에 렌더링 되지 않고 눈에도 안 보이는 것
vs
3. (대망의) DOM에 렌더링은 되는 데 눈에는 안 보이는 것

이렇게 나눌 수 있다.

문제의 원인은, 앞서

.react-calendar__month-view__days__day--neighboringMonth {
  display: none;

}

(react Calendar라이브러리의 css 끌어와서 쓰느라 기본 CSS쓴거임) 특정 달의 이웃 달의 날짜가 안 보이게 하기 위해 위와 같이 CSS를 짰었는데, 이렇게 하면 2번 케이스에 당첨이다.

그런데 실제 현실의 달력은, 설령 이웃달의 날짜를 같이 병기하지 않더라도 그 자리 자체는 차지한다. 그런데 2번을 채택하게 되면 DOM에도 렌더링이 안되어 버리니까, 결과적으로 이웃달 날짜가 차지해서 해당 달의 날짜가 시작해야하는 날짜가 그만큼 뒤에 밀려야하는데 그렇지 못했던 것이다. 그래서 모든 달의 날짜가 죄다 일요일부터 시작해버렸다.

따라서, 결과적으론 시시하게 visibility: hidden;로 해결했다.

추신.

• 사실 불필요하게 DOM에 많은 요소가 렌더링되면 그만큼 성능을 떨어트린다. 하지만 은총알은 없는 법. 상황에 맞게 적절한 솔루션을 찾고 적용하는 게 중요하겠다.
• CSS가 문제였다! 고 시작했지만 결과적으로는 DOM 개념까지 연결된 문제 상황이었다. 역시 모든 개념은 연결되어있나보다.
• 기술 블로그 잘 안쓰는 고질병이 있으나 굳이 왜 이렇게 빠르게 기록을 남겼나 하면 이거 v2 디자인 적용시킬 때도 겪었던 문제였다. 당시에 기술블로그에 기록을 해놨으면, 어 이거 설마! 하고 바로 알아서 고쳤을 텐데. 하아... 트러블슈팅은 간단하게라도 기록하는 습관을 들이겠다. 같은 실수 2번은 안 해야지.

서비스 설명

약속 잡기 힘든 시람들이 만든, 더 많은 만남을 위한 서비스

우선, 설명에 들어가기 앞서 본 '언제볼까?'프로젝트는 위 모토의 웹앱 서비스이다. 모임장이 캘린더에서 날짜와 시작, 종료 시간대를 정하여 약속을 생성하고, 해당 약속의 공유 링크를 받아 모임장과 모임원은 만날 수 있는 시간대를 작성한 뒤, 공동 캘린더에서 이를 확인한다. 서비스의 selling point는 다음과 같다.

1. 원터치로 손쉽게 약속 잡기!

2. 여러 약속들은 서비스 하나에서 한번에 관리!

3. 기존 when2meet같은 약속 서비스보다 접근성 강화되고, 내수 시장에 익숙한 UI, UX!

UI 개발

우선 9월에 막 본 프로젝트에 착수했을 때, React와 CSS라이브러리 자체에 대한 이해도가 낮았고 '왜 써야하나?'에 대한 필요를 못 느꼈다. 사실 당시까지만 해도 그냥 className 다 다르게 하는 식으로 해도 무방한 수준의 짧은 코드였다. 작년 9월부터 12월까지 개발한 Monthview, weekView(개발은 했으나 당장 말고 이후 추가 기능에 넣기로 했음), invite, indivual Calendar, eventCalendar 페이지에는 모두 기본 CSS를 적용했다!

'왜' tailwindCSS? 한계?

작년 9월부터 시작한 교내 IT동아리인 KUIT 4기 WEB 부원으로써, FE 스터디에서 CSS-IN-JS, tailwindCSS 등 CSS관련 여러 기법과 라이브러리에 대해 배웠다. 향후 유지 관리의 용이함 및 협업에 있어 CSS 라이브러리의 사용은 꽤 중요한 점을 깨닫고, 그래서 방학 기념으로 1월에 Landing페이지를 포함한 이전에 개발한 모든 페이지를 tailwindCSS와, 그를 도울 clsx, class-variance-authority 라이브러리를 사용하여 모두 리팩토링 하였다.

tailwindCSS를 선택한 이유는 알아본 결과 문법이 굉장히 쉽고, 꾸준히 업데이트가 잘 되어 여러 복잡한 CSS 기능을 지원한다고 해 선택했다. 그러나 막상 써보니 코드가 깔끔은 한데 더 복잡해지는 느낌이 없잖아 있었고, 그렇다고 현재 하드코딩된 CSS 코드를 그대로 냅둘 수도 없었다.

clsx와 class-variance-authority 도입

딱 className="eventCalendar-header"하는거보다 매번 className="w-2 h-2 어쩌고 저쩌고..."가 가독성 면에서 항상 좋은지는 확신하기 어렵다. 이에 이러한 문제를 해결하고자 조건부 상황에서 동적 클래스를 적용해야할 때 가독성을 높이는 clsx, 코드 재사용성을 높이는 class-variance-authority 라이브러리도 함께 도입했다. 특히 class-variance-authority는, color.ts모듈과 typograhpy.ts에 적용하여 재사용성을 크게 높였다. 이전에 작성된 CSS는 정말 하나하나 #FFFFFF 이런식으로 하드코딩되어 작성되었기에 (...) 리팩토링의 효용을 크게 맛보았다.

모듈화

색상하는 김에 버튼도 모듈화했는데, 처음에는 만들면서도 모든 페이지에서 쓸 총 버튼 개수가 몇 안되는데 이정도 수고를 들여아하나? 생각했다. 그런데 버튼이 단지 selected, unselected 상태 뿐만 아니라 예를 들어disable, hover, focus 이런 상태까지 여러 개 있으므로, 상태를 조합해서 나올 수 있는 가짓수를 생각하니, 생각보다 꽤 되었다. 모듈화 하기 잘했다.

React 기능 개발

사실 가독성에 있어서 UI 개발 -> 기능 개발이 보기 편할 거 같아, 포스트 상에서는 임의로 위와 같이 구성했다. tailwindCSS 도입 이전에 앞서 이러한 PR들이 올라갔고, 새해부터 대략 일주일 넘게 나를 애 먹였던 individualCalendar 스케줄 데이터 처리 관련 버그 이슈 버그에 대해 포스트 해보고자 한다. (Issue는 팀장님이 올리셨긴하나 내용 자체는 Slack에서 내가 제보한 내용이었다)

FE? BE? 어디서 오류가 난걸까...

여러번의 Slack에서 총 107개의 댓글을 빙자한 토론이 오갔고...

이슈의 요지는 다음과 같다.

• FE → BE (http://localhost:8080/api/v1/schedule/updateSchedule) 데이터 전송, BE에서 해당 시간대로 저장

• BE(http://localhost:8080/api/v1/schedule/getUserSchedule?appointmentId=${appointmentId}&userName=${name}) → FE 저장된 데이터 response
• FE에서 UI 렌더링

이 3가지가 모두 정상 작동하는데, 정작 사용자가individualCalendar에서 저장한 시간대 값이랑 이후 재로그인하여 화면에 나타난 individualCalendar의 시간대 저장값이 전혀 달랐다...!! 이에 BE에서 데이터가 가공될 때 뭔가 이슈가 발견한 것으로 확인, 제보했다. Github Issue 페이지에서 수차례의 논의와 FE,BE 각각의 코드 수정 끝에 사용자가 입력한 시간대보다 9시간의 시차를 가진 시간대가 저장된다로 버그를 규칙성 있게 만드는 데 성공했다! 야호~ 그러나 여전히 문제가 해결되지 않아 계속해서 코드를 디버깅해가며 검토하던 중, 팀장님께서 solution을 내놓으셨다.

결론적으로는 Spring 실행 환경에 따른 시간 문제로 결론났다. 왜 똑같은 ec2 서버 주소로 요청을 보내도, public 환경의 https 서버 주소에 요청을 보내도 팀장님 노트북에서는 되고 내 노트북에서는 안될까? 라는 지점이 못내 답답했는데 깔끔하게 해결되는 순간이었다.

앞으로 마주할 버그가 단순히 FE, BE에 있는 거라기보단 이런 식으로 FE와 BE 그 사이 어딘가를 헤매는 버그가 대다수일것이다. 이런 버그가 발생했을 때, 버그의 원인과 버그가 일어나는 상황을 하나하나 테스트해가며 찾다보니 야크 털 깎기에 빠지기 무척 쉬웠다. 이에 여러분이 이런 FE와 BE 사이의 버그를 탐색해야할 때, Slack과 Github Issue, Jira를 활용하여 매순간 내가 무엇을 찾고자 어떤 과정에 있고, 무엇을 발견하며 다시 돌아가서 다시 탐색해볼 건지, 즉 일련의 Issue Tracking과정을 매 순간 다소 강박적으로라도 되새김하며 했으면 한다. 실제로도 이런 태도가 도움이 되었다.

공유하기에 관하여

본 '언제볼까?' 서비스의 핵심은 약속에 참여할 모든 사용자의 겹치는 시간대를 보는 데 있다. 그러기 위해선 약속 링크를 공유해야했고, 당초 나온 계획은 클립보드 링크 복사, 카카오톡 공유, 그리고 마지막으로 다른 앱으로 공유가 있었다.

클립보드 링크 복사는 딱히 언급할 필요도 없이 무척 쉽게 구현했다. 카카오톡으로 공유하기의 경우, 처음 해보기는 했으나 (사실 이 프로젝트에서 하는 모든 게 처음이긴하다...) 공식문서가 꽤 깔끔하게 적혀있기도 하고 카카오 DevTalk에서 역대 토론이 잘 적혀있어서 쉽게 구현할 수 있었다. 다만, 카카오 앱 키를 발급하여 로컬 .env에만 등록하고 정작 Github Actions에서 주입될 앱 키를 Github Secret 기능에 등록을 깜박하여 조금 난항을 겪긴 했다. 제 노트북에서는 돌아가는데요?

그 다음은 그 문제의 다른 앱으로 공유 기능... 프론트엔드 단에서 구현할 때 쓰는 Web Share API로 구현하는데, 해당 라이브러리를 써번 사람은 알겠지만 온갖 이슈가 많다. 당시 발생했던 이슈 상황에서 참고했고 실제로 해결이 됐던 solution이 담긴 기술블로그 글은 다음과 같다. 디버깅(로컬) 환경에서 아예 동작하지 않을때, 공유하기 실패 시,alert 처리를 해주었음에도 불구하고 아무런 반응이 없을때 또, 전체적인 코드의 구조와 쓰임새를 참고할때는 이 글을 참고하였다. 그 외에도 애주가 유저를 위해 술 정보,,,?를 저장하는 기능이 담긴 사이드 프로젝트 기술블로그에서 코드 컴포넌트화의 이해와 Web Share API에 대한 이해도를 얻어갈 수 있었다.
개인적으로 해당 사이드프로젝트 Github을 직접 들어가보고 코드를 모듈화 한다의 필요성을 크게 깨달았고, 아, 남의 코드를 보고 배운다는 게 이런 거구나!!를 느끼게 한 좋은 코드이였는데, 문제는 해당 글과 Github 주소를 저장 안해놔서... 이 글에 꼭 넣고싶었는데 찾지 못했다... 여러분은 꼭 좋은 인사이트를 준 글을 저장해두면 좋겠다. 제발

이러고 이슈를 모두 해결하고 Web Share API를 성공적으로 이식했으면 좋았겠지만 아쉽게도 실패했다. 웹과 네이티브(Android) 간의 상호작용이 무슨 짓을 해도 성공하지 않았다... 안드로이드 웹뷰에서는 본 라이브러리가 동작하지 않음을 인지했으나, 어째서인지 모바일 브라우저(ex Chrome, 삼성인터넷, 파이어폭스 등등)에서도 돌아가지 않았다. 이 블로그에 다 쓰지 못할만큼 이슈 해결을 위해 삽질을 좀 하다가, 다시 본질로 돌아와서 생각해봤다.

이게 정말 필요한가?

결론적으로 당시 내가 낸 결론은 아니었다! 우리의 목표는 코드 짜는 게 아니라 하나의 product를 완성하는 것이다. 이 삽질의 끝이 이 product를 완성하는 데 중요한가?라 생각하니 그렇지는 않았다. 접근성의 측면에서도, 카카오톡 공유하기와 클립보드 링크 복사정도면 그럭저럭 쓸만하다고 판단했다. 이에 팀 내 기획 겸 디자이너님께 의견을 여쭈었고, 공유하기 기능을 모아둔 모달에서 해당 Web Share API기능을 제외하기로 했다.

디자이너와 소통하는 법

사실 제일 걱정했던 부분이다. 2024년도 여름방학에 준비했던 멋쟁이사자처럼 동아리의 해커톤 product의 경우, 기획을 맡은 선배가 컴퓨터공학도였다. 즉, 기획 겸 디자이너 역할을 하면서도 개발에 대한 충분한 이해가 있는 상태였고, 심지어 최종 CSS 수정에 있어 어느정도 검토까지 해주신 전적이 있다.

그런데 본 '언제볼까?' 프로젝트의 경우는 보다 장기적인 프로젝트이고, 기획 겸 디자이너 님이 디자인 전공이시며, 이전에 개발자와 협업한 경험이 있는 분이었다. 정작 나는 진짜(?) 디자인 전공자와 일해본 게 처음이었기에, 혹여나 소통하는 데 있어 폐가 되지않을까 갖은 걱정을 했다.

이에 내 나름대로 다음의 원칙을 갖고 소통에 임했다.

1. 무조건 안된다고 하지않는다. (안되면 왜 안되는지 상황 설명을 한다)

2. 기술 용어를 쓰더라도 쉬운 자연어로 풀어 설명한다.

3. 레퍼런스도 같이 첨부해서 이해를 돕는다.

4. 조금이라도 헷갈릴 때는 기획 의도를 묻는다.

5. 기획자는 기획자의 일을 해야한다.

1번과 2번, 3번은 사실 나 자신을 위한 원칙이기도 했다. 프론트엔드 구현에 대해 잘 모르는 사람을 위해 설명하는 것은, 다시 말해 이걸 말하는 나는 이것을 자연어로 설명할 수 있나? 설명할 수 있어야 잘 아는 거 아닌가?의 지점을 고민하게 했다. 남이 이해할 수 있는 글은 본인을 더욱 이해시킬 수 있다. 나는 프론트엔드 개발을 함으로써 백엔드의 아주 세부적 로직까지는 몰라도 개괄적인 로직(특히 백엔드 API호출 부분, 즉 뭐를 요청했을때 뭐를 응답받아야한다)과 UI, UX를 이해하고있다. 특히 본 프로젝트의 초기 기획은 팀장님(ver1 백엔드 개발)이 내놓으셨고, 세부 UI, UX는 디자이너 님이 들어오고 확정되었다. 디자이너 님께서 모임장, 모임원 각각에 대한 서비스 로직 자체에 대해 살짝 헷갈려 하셔서 직접 동영상 시연을 통해 확실한 이해를 도운 기억이 난다!

4번 역시 중요했다. 기획자의 시선과 개발자의 시선을 같은 듯 하면서도 다르다는 걸 많이 느꼈기에, 기획자의 의도 파악이 중요했다. 명확히 밝히지않고 가면 꼭 마지막에 엎어야하는 상황이 생겼기에... 조금이라도 헷갈리면 물어보는 게 best.

사실 5번에 관해서는 프론트엔드 개발에 임하는 사람들에게 있어 의견이 갈릴 거 같다. 다만 나는 기획자는 기획자대로의, 개발자는 개발자 대로의 일이 있다고 믿는다. 팀 내 기획자가 기획 단계에서부터 이렇게 개발하는 게 편하니까를 염두에 둘 필요는 없다고 생각한다. 물론 개발적으로 전혀 말이 안되거나, 개발 마감이 빠듯하거나 제한된 리소스, 인적 자원을 가진 상태라면 협의를 통해 업무를 조정하는 게 맞다. 앞에서 설명한 Web Share API 사례처럼 말이다. 또, 개인적으로 UI, UX자체는 간편하고 훌륭한데 코드 구현으로는 복잡한 경험도 나름의 훈련이 되었다. 이 또한 만약 기획 단계에서 이렇게 개발하면 편하니까를 고려했다면 하기 어려웠을 것이다.

당시 디자이너님과 주고 받았던 Slack 메시지의 좋은 예시 몇개를 첨부해본다. 박수도 두 짝이 맞아야 소리가 난다는 데, 여러모로 소통에 있어서 항상 깔끔하셔서 좋았던 거 같다. Figma에 작업하신 디테일한 UI, UX를 보면서 항상 감탄하며 정말 많이 배웠다...!

UI와 실제 전송되는 데이터의 차이

개인 일정을 작성하는 individualCalendar 페이지에서, 눈에 보이는 UI와 실제 전송되는 데이터의 차이가 있어야한다. 현재 BE에서 이미 선택된 부분을 한번더 클릭했을 때는 선택되지 않은 부분으로 togglee 되도록 세팅되어 있다. (on 상태면 off, off상태면 on으로 전환) 이에 모든 시간 가능 버튼 클릭시, 이미 선택된 timeslot에도 동일하게 요청을 보내서 오히려 해제 되버리는 식으로 동작되어 이슈가 발생한 적이 있다. 사용자 화면에 보여줄 selected된 timeslot이 담긴 배열과, 정말로 서버에 보낼 상태가 변화한 timeslot을 담은 배열 해서 총 2가지 배열을 만드는 식으로 해결했다.

코드를 쪼개자 (ft. Props 전달)

약속을 만들때의 화면에 대해 팀원들과 논할때, 다음과 같은 MonthView페이지로 통칭했다. 그런데 이는 사실 MonthView.js와 TimePicker.js, 그리고 두 컴포넌트의 데이터가 준비되면 서버에 보내는 로직이 포함된 ParentMonth.js로 구성되어 있다.

ParentMonth.js의 네이밍을 보면 알 수 있듯 React의 Props 전달의 개념에서 따왔다. 데이터의 이동 과정은 다음과 같다.

1.ParentMonth에서 두 컴포넌트에 useState로써 jsonData,startTime, endTime, isFormReady를 내려준다.

2. TimePicker에서 startTime, endTime이 설정 되고 MonthView에서 날짜가 1개 이상 선택되면 MonthView에 내린 isFormReady가 true가 된다.

3. MonthView의 jsonData가 시간대를 UTC시간대에 맞게 변환 및 약속자 이름, 약속 이름 등의 구체적인 약속 정보를 포함하여 입력 된다.

4. 최종적으로 ParentMonth.js에서 isFormReady를 useEffect로 상태변화를 추적하여 서버로 jsonData를 전송한다.

뭔가 이상하지 않은가? 그렇다. 이 코드는 더럽다... 설계의 중요성

정말 Props 전달의 모토에 맞게 할려면 자식 컴포넌트는 부모 컴포넌트인 ParentMonth로부터 꼭 필요한 데이터만 내려 받아야한다. 또, isFormReady는 MonthView에서 startTime, endTime, selectedDates를 확인하여 자체적으로 결정 가능하고, useEffect로 상태 변화를 추적할 수 있다. 즉, 정리하자면 MonthView와 TimePicker단에서는 데이터를 가공하고, 최종적으로 서버에 전송할 때만 ParentMonth에서 하는 식으로 책임을 분리하면 훨씬 가독성이 개선된다.

위 solution은, 추후 기능 확장 등을 이유로 MonthView와 TimePicker 각각 에서 또한번 자식 컴포넌트로 분화한다면 깊은 단계의 자식한테 Props를 전달하는 Props Drilling을 유발할 수 있다. 이런 경우에는 Context API나 Zustand 등의 상태 관리 라이브러리를 활용하여 데이터를 전역 상태로 관리하는 것도 또 하나의 좋은 방법이 될 것이다.

프로모션 페이지 (with framer-motion)

정말 즐겁게 했던 프로모션 페이지 작업 ...! 해커톤 프로젝트 당시에는 별다른 프로모션 페이지 없었고,Framer란 툴을 처음봐서 신기했던 거 같다.

해커톤 당시에는 간단한 인터랙티브 디자인은 직접 구현했는데, 이번에는 본격적으로 인터랙티브 디자인이 복잡하게 많이 들어가기도 하고 Framer는 유명한 회사니까 분명 라이브러리가 있을 거라는 생각이 들었다. 찾아본 결과 정말 Framer motion 라이브러리가 있어서 이것을 사용하여 개발했다. 사용법이 워낙 직관적이고 간편하기도 하여 구현에 큰 어려움은 없었다. (그냥 <motion div> </div> 안에 속성 좀 부여하고 컨텐츠 내용 작성하면 끝이다)

다만 라이브러리 특성상 인터랙티브 디자인과 많이 연관되어 있는 만큼, 기술블로그 들을 많이 참고하여 다양한 모션 디자인 예시들을 참고해 보는 게 중요했다. 특히 구체적인 모션읭 속도를 지정할 때, 컴퓨터에서는 베지어 곡선(Bezier Curve)개념을 사용한다. 두 개 이상의 제어점을 사용하여 곡선의 형태를 조절하기에 단순한 수 조정으로는 직관적인 이해가 어려울 수 있다. 이럴 때는 요런 사이트를 참고하면 도움이 될 것이다.

SEO 최적화

서비스가 홍보가 될려면 아무래도 일단 검색이 되어야한다. 특히 본 프로젝트는 CRA(Create React App)으로 만들어졌기에, Client-Side Rendering으로 동작한다. Next.js처럼 Server-Side Rendering 되어서 요청 시 서버에서 HTML을 생성하여 즉시 전송되는 게 아니기에, SEO가 잘 되도록 하기 위해서 여러 세팅이 필요했다. 검색엔진 최적화를 위해 적용했던 사항은 다음과 같다.

1. <div> 태그 대신 시멘틱 태그 넣기
2. react-helmet-async 라이브러리로 각 페이지별 메타태그 넣기
3. react-hydratable로 Prerendering을 구현하여 크롤러가 미리 렌더링된 HTML을 가져갈 수 있게 하기
4. 구글 서치콘솔, 네이버 웹 마스터에 우리 사이트 주요 path 등록 (색인 요청)
5. 크롤러가 읽기 쉬우라고 /Robots.txt , /sitemap.xml 세팅

SEO 최적화를 했는데 전에는 잘되던 초대페이지 접속이 안된다??

이렇게 SEO를 적용시키고 나니, 이런 이슈가 발생하였다. 결론적으로 Prerendering을 구현하는데 있어서, 정적 라우팅을 시키다보니 매 약속마다 구체적인 UUID가 달라지는 invite페이지에서 오류가 났던 것이었다. 이 부분에는 다시 따로 동적 라우팅을 적용시킴으로써 해결했다,

SEO를 넘어 GEO로

요즈음 들어 이전처럼 구글링을 직접 하는 게 아닌, searchGPT 등 AI를 활용해 검색하는 사람들이 늘고있다. 따라서 AI 모델이 정보를 더 잘 이해하고 선택하도록 최적화하는 것 역시 필요하다! FE ver2 개발하며 같이 진행할 계획이다.

이게 잘하고 있는 걸까?

본 글을 쓰면서, 이전에 기록해둔 KUIT 4기 웹 프로젝트 스터디 정리 자료, 언제볼까? Github FrontEnd 페이지을 참고했다. 본 프로젝트를 막 시작할 때 쯤에는 React에 대한 이해도가 부족하여 위의 Props 전달 예시처럼 초기 세팅 단계에서 제대로된 설계가 부족했음을 뼈저리 느낀다. 당시 전공 5개에 본 사이드 프로젝트와 동아리 스터디를 병행했었기에, 스터디를 하며 React 개념을 열심히 배우고 실습하는데 급급했었다.

'더 좋은 코드에 대한 고민이 없이 짜고 있다... 이게 맞나?'와 '근데 좋은 코드보다는 일단 돌아가기만 하면 되지않을까?'같은 고민의 연속이었다. 학기 내내 주7일간 휴일 없이 학교 과제와 학교 팀프로젝트 개발과 언제볼까? FE 개발과 동아리 강의와 동아리 과제... 뭐 하나 제대로 잘 못해내는 기분이 들었다. 선택과 집중이 필요한가는 고민을 했고 급기야는 동아리 스터디 탈퇴까지 고려하여, 평소 친분이 있던 KUIT 4기 웹 파트장님인 지환님께 말씀을 드렸고 다음과 같은 답을 얻었다. (분량상 일부 생략)

아하.. 현주님이 엄청 잘 따라가고 있는 쪽이었는데 의외네요ㅠㅠ 질문도 매번 열심히 해주셔서 감동이었는데요 ㅠ 벌써 6주차 과제도 잘 제출해 주셨고 이제 4주차 밖에 (사실 상 과제는 3주차 밖에) 안 남았는데 일정 상 많이많이 힘드신가요??? 시간이야 항상 없고 저조차도 PR 리뷰도 시간에 쫒기면서 계속 미뤄지고 있는 걸 보면... 많이 공감되네요 저도 지금 우테코나 이것저것 동시에 진행하면서 느끼는 건데, "Done is better than perfect"라는 말이 많이 와닿아요. 좋은 코드에 대한 고민은 일단 나중으로 미루고 먼저 요구사항에 맞는 구현을 빠르게 하는 방향으로 잡아 보는 것은 어떨까요? 충분한 고민 없더라도 조금만이라도 고민하면서 짠다면 코드가 늘어 있을 거고, 짧은 시간에 일단 돌아가는 코드를 짜내는 것도 중요한 실력이라 생각하거든요. 솔직히 강의 듣고 과제 하는 것도 완벽한 수준이 아니라 out 되지 않을 정도 선에서 멈춰도 괜찮다 생각해요. 그래서 이미 충분히 잘 따라와주셨기도 하고, 개념들을 한 번이라도 가볍게 훝어 보는 거랑 아예 모르고 끝내는 거랑도 차이가 있으니 스터디만이라도 완주하는 것을 추천드립니다...ㅠㅠㅠ

이에 마음을 다잡고 스터디를 완주했다. FE ver1이 끝난 와서 생각해보니 정말 잘한 선택인 거 같다. 위에 조언해주신 대로 개념을 한번이라도 훑은 것과 아예 모르고 끝낸 거는 큰 차이가 있었다. 당장 chatGPT에게 질문을 하더라도, 키워드를 알고 구체적인 질문을 하는 것과, 개념을 모른 채 피상적이고 넓은 질문을 할 때 답변 퀄리티 자체가 달라지는 걸 알 수 있다. 사람도 똑같다고 생각한다.

마치며

흔히 사이드 프로젝트의 장점으로 '협업 경험을 쌓을 수 있다'가 꼽히곤 한다. 겉보기에 간단한 UI, UX지만 직접 구현할 때 복잡한 내용들을 구현해보기도 하고, 공식문서와 기술블로그들을 보며 남의 코드를 까보며(?) 배운다를 몸소 배우기도 하고, 왜 설계가 중요한지도 느끼기도하고, 개발자가 아닌 사람과 개발을 논할 때 어떤 태도로 임해야하는 지도 배웠다. 확실히 혼자 공부할 때는 느낄 수 없는 부분들이다.

특히 웹 기술은 하루가 다르게 발전하고, 꽤 많은 부분이 추상화 되었지만 결국 근본적인 이해를 위해서는 low레벨 개념 까지도 확인해야 하는 부분이 있었다. 여러모로 학교 전공 공부에 안주하지 말고, 꾸준히 스스로 찾아가며 공부해나가야한다. 특히 공식문서 꼭 확인하기를 많이 느꼈다.

진짜마치며

FE ver1을 개발하며 줄곧 정리하고 싶다는 생각을 많이 했는데, 마침내 정리를 하게되어 기쁘다. 이 글을 쓰는 시점에서 디자인 및 백엔드, 인프라 팀원이 열심히 해주신 덕에 ver2이 모두 완료되었다. 으악 FE ver2도 마저 힘내서 열심히 개발해보아야겠다. 파이팅!!

0. 다른 달로 넘어가라!는 신호 발생 및 정보 전송까지는 정상적으로 되는데, 문제는 React 특유의 사이클이 채 다 돌기전에 다음 달 버튼을 클릭했을때 이미 저장된 현재 달로 reset되서 사용자가 원하는 다음달로 정상적으로 넘어가지않고, 계속 맨 처음 선택한 달만 선택되는 거였음.

• 결국 '캘린더 month의 reset이 어떤 타이밍에 이뤄지는게 흐름상 적합한가?'의 문제였기에, 라이브러리에서 제공하는 activeStartDate로 해결함.
• React 기초가 튼튼한 편이 아니라 사실 이 표현이 정확한건지 잘 모르겠음
• 즉, '다음달로 넘어가라는 신호 발생 -> ㅇㅋ 넘어갈려는 달이 n월이구나 -> n월로 리셋->끗'가 되어야하는데 '다음달로 넘어가라는 신호 발생 -> 음, 현재 달은 k월이구나. k월로 리셋-> ㅇㅋ 넘어갈려는 달이 n월이구나.-> 끗' 흐름이 되니까 다음달로 reset하는 것도, reset한 값 받는부분에도 정상작동하는데도 단지 타이밍이 안 맞는거 하나땜에 문제가 터진거였다.
• 전에도 React 사이클 관련해서 문제 났던 기억이 있는데...; 아직 React는 갈 길이 먼거같다.

아래는 구차한,,,변명,,^^

1. 공식문서 이슈페이지 읽었음에도 안 써봐서 어색한typeScript문법 있다고 제대로 안 읽음

• 안써봤다고 냅다 쫄지말자
• typeScript란게 별세상의 존재가 아니라 좀더 깐깐하게 조건 제어할 정도의 몇가지 추가한정도였음. 즉, 몇글자 제거하면 평소 쓰던 React친구라는 ...였던 것..

  2. 애초에 아주 기본적인거 제외하고 기능 만들려고 라이브러리 제대로 불러다 쓴건 이게 처음이라 남의 코드(???) 잘 안읽을려한듯?

• 내 코드도 2주 손 놓고 주석도 안 써놓으면 노답이긴하지만... 그래도 정독할 노력정도는 해봐야할듯(당연함)

  3. 기술블로그 10개 대충 읽는거보단 공식문서 및 이슈토론 페이지 답글 열심히 보는게 낫구나...

• ㅋㅋ...ㅎㅎ!

해커톤 당일 후기도 아직 안 썻지만...그치만 지금 이 깨달음을 남기고싶어 후루룩 써봤고...해커톤 후기 완결편은 각잡고 열심히 써볼..생각...

'에이스팀' 근데 나만 빼고...

우리 해커톤 팀은 백엔드 총 3명 (Django 2명, Spring 1명), 기획 1명, 마지막으로 프론트엔드(React) 나 한명이었다. 팀원 과반수가 프로젝트 유경험자이고, 프론트엔드 관련해서 물어볼 사람 없이 팀을 이뤘기에 걱정이 이만저만이 아니었다. 기획자 분이 '어느 수준까지 구현해봤냐, 혹시 전에 했던 작업물 있으면 봐도 되냐'고 충분히 물어보실 수 있는 부분마저 제대로 답을 하지 못했다.

불안할 시간에 뭐라도 구글링을 하자

그나마 다행이었던 건, 내가 평소에도 AI 파인튜닝 및 UI 용어에 관심이 있고, 웹프로그래밍 수업과 멋사 스터디 세션을 통해 js를 전혀 못 쓰는 상태는 아니었던 점이었다. 기획 초안이 나오기 전까지 AI파인튜닝 팁, IT 프로젝트 소통 팁, chatGPT로 웹페이지 만들기, chatGPT 코딩봇, UI 디자인 설명 , UI용어 정리 사이트, 기타 js&css꿀팁 등을 열심히 구글링했던 기억이 난다. 특히 UI용어는 현직자 사이에서도 통일되지 않고 다르게 부르는 게 꽤 있다고 하여 기획이 여러명이면 꽤 도움될듯하다. 기획과 소통할 프론트엔드가 읽기에도 무척 좋고! 다만 우리팀은 기획이 1명이어서 용어를 혼용할 사람(...)이 없었기에, 내가 UI공부하는 정도에서 그쳤다.

프론트엔드는 한명이지만 commit과 push는 열심히

앞으로의 과정 서술은 간단하게, 적을만한 내용을 에피소드 형식으로 간추려 적도록 하겠다. 사실 깃허브에 프론트엔드 Repo가 파진 시점에서 고민을 했다. '진리의 Ctrl+Z만 해도 충분히 쓸만한데, 게다가 프론트엔드가 나 혼자인데 굳이?'라는 생각이 들었다. 다만 백엔드 spring 담당 선배의 조언으로 꾸준히 간단한 commit메시지와 함께 push를 했다. 이후 새 Detailed.js(상세페이지)를 만들었더니 이유를 찾을 수 없는 버그가 있어, 마지막 commit버전으로 돌려서 겨우 해결한 적이 있었다. 지금와서는 아마 css 특유의 전역변수 현상으로 새로만든 js와 연결된 css의 변수가 겹쳐서 충돌이 일어난 걸로 추측하나, 당시에는 정말 개발 경험이 없던 터라 초멘붕에 빠졌고, 꾸준히 commit의 중요성을 다시금 느끼며 안도의 한숨을 쉬었던 기억이다.당시 작업기록... 멘붕와서 저날은 계속 똑같은 코드 붙들고 있었다. 결국 과감히 이전 commit으로 돌리고서야 해결.

CORS? 프록시 서버?

이후 기획팀에서 받아온 웹페이지를 열심히 만들고... 대망의 백엔드 api 연결을 위해 우선 서버 연결을 시도해보는데...!!! CORS에러가 뜨고 말았다. 진짜 수없는 구글링을 통해 프론트엔드측에서 해결하는 방법, 백엔드 측에서 해결하는 방법을 각각 알아냈고 우선 프론트엔드 측 해결방법을 시도했다. 얼핏 기억나는건 프록시 서버를 통해 우회하고, 관련 모듈을 열심히 깔아주고, package.json, package-lock.json 측 설정 건드려주고... chatGPT로 해보고 안되면 이 블로그 그래도 안되면 저 블로그 방법으로 그래도 안되면 chatGPT로... 윤회의 굴레도 이정도는 아닐 거 같다. 대략 4시간의 대장정은 모듈만 실컷 깔고 실패로 돌아갔고, 앞서 찾아낸 백엔드 측 해결방법을 Slack으로 백엔드 spring 선배한테 공유했다. 그러나 발빠른 선배는 이미 관련 설정을 추가했고, DB까지 채운 뒤 서버 재배포 생각이었다고, CORS 관련해서는 더 안찾아봐도 될거라고 말을 덧붙였다. 프론트엔드도 백엔드 지식이 필요해지는 시대에 조기경험한 셈쳤다.

chatGPT 길들이기

사실 이 부분을 제일 쓰고 싶었다. 누누히 언급했듯 React관련해서는 프로젝트 경험이 제대로 쌓여있지 않아 AI가 큰 도움이 되었다. 나의 프롬프트 팁을 간략히 적어보자면 다음과 같다.

0. 내가 누구고 앞으로 어떤 요구를 할건지 간단히 파인튜닝

1. []태그 안에 요구사항을 명확하고 자세하게 요구

2. chatGPT로 해결 안된 문제는, chatGPT가 제시한 키워드로 다시 구글링 한 뒤, 새로 알아낸 걸 다시 chatGPT한테 질문 (chatGPT한테 구체적인 레퍼런스 멕이는 과정)

3. chatGPT한테 큰 틀을 먼저 만들어달라 한 뒤, 세부사항 차근차근 요구(step-by-step)

4. 한 chatGPT페이지에는 그거 관련 내용만 묻기

정도가 있겠다. 해커톤 끝나고 찾은 '2024년부터는 코딩 작성을 중단했습니다' 글도 참고하면 좋을 거 같다. 읽으면 알 수 있듯 큰 맥락은 일치한다.

또한 당연! 하지만! 그냥 chatGPT한테 시키기만하면 실력이 늘지 않는다.

chatGPT가 만든 코드를 일단 읽고, 이해가 안되면 코드리뷰를 요구하거나, 구글링을 좀더 해보는 등 적어도 이 코드가 왜 돌아가는지 이유도 모르는 채 묻는 사태를 방지했다. 결국은 공부를 해야 나중에 또 같은 문제로 물어보지않고, 다음에 할 질문을 보다 똑똑하게 할 수 있다. 또 이런식으로 공부하다보면 어느 순간 chatGPT한테 묻기전에 그냥 혼자 후루룩 빠르게 코드 적고 넘어가는 일이 생긴다.

AI시대가 열린다고 해서 인간이 구태여 바보로 남을 이유는 없다.

프롬프트 예시1. chatGPT에게 앞으로의 질문은 모두 React와 css 위주 일것이란 힌트를 미리 줄 수 있다. 프롬프트 예시2. '성공시 금전적 보상을 주겠다'는 프롬프트가 도움이 된다는 글을 꽤 봤는데, 유의미한 차이는 못 느꼈다. 하여튼 요구사항을 구체적으로 썼더니 잘 알아듣는 모습이다.프롬프트 예시3. 기존에 작성된 코드를 요구사항에 맞게 고치는 것 역시 잘한다.

CSS 전역변수 현상

사실상 css관련 제일 큰 빌런이었던 거 같다. 각 js에 연결된 css의 부모-자식 상속관계 속성 지정, 구조 안 무너지게 잘 쌓기, 랜딩페이지 인터랙티브 디자인 적용까지는 그래도 배워가며 작업 재미가 있었는데 얘는 대체... 심지어 프로젝트 중반에 알아채서 더 고생했던 거 같다. 앞서 마지막 commit버전으로 돌리고 겨우 해결해야 했던 문제도 돌이켜보면 여기서 파생된 거였다. 결국 중반부터는 최대한 안 겹치게 클래스명을 짜고, 이미 짠 코드는 '해당 js파일이름+원래 변수명' 형태로 재작성했다. 덕분에 이런 JAVA 뺨치고 갈 길이의(...) 변수명이 탄생했다. 또, 여기서 더 생각해본 것은 '아예 이걸 진짜 전역변수처럼 써버릴 수는 없나?!' 였고, 마땅한 답을 찾았다. CSS 변수(--variable) 사용법 링크를 참고하면 좋을 듯 하다. CSS 강제 우선순위(!import) 쓰는법 링크도 겸사겸사 보길... 나는 프로젝트 후반부에 가서 이 정보들을 알았기에 제대로 쓰지 못했다.

background: #000000; 

일일이 이러고 썼다. 역시 사람은 뭐든지 알아야 쓸 수 있는 법이다.

끝!

이번글은 이쯤에서 마쳐본다. 다음 글은 해커톤 현장편으로 올릴 예정이다.

왜 하필 '멋쟁이사자처럼' 였을까?

2024년도 기준으로 컴퓨터공학부 2학년에 재학중인 나는 작년까지만해도 개발 동아라에 들어갔다거나, 프로젝트에 참가해봤다던가... 이런 것들이 전무한 상태였다. 1학년때는 학과 공부에 집중했고 여전히 개발에 있어서는 갈피를 못 잡는 상태였다. 1학년 교육과정에 들어가있는 c와 java는 솔직히 말해 재미가 없었다! 백엔드에는 큰 관심을 붙이진 못했으나 UI, UX에는 꾸준한 관심이 있었고,

관심 가는 걸 일단 해보자!

라는 마음으로 개발동아리를 들어가고자 여러가지 정보를 탐색하던 중, 다음과 같은 이유를 꼭 맞는 동아리를 발견했다.

1. 연합동아리 특성상, 같은 학교 뿐만 아니라 다른 학교랑 네크워킹 가능

2. 아이디어톤, 해커톤 등 구미가 당기는 행사가 다양하게 있음

3. 내가 원하는 프론트엔드 파트가 있음

그렇게 '건국대학교 멋쟁이사자처럼 12기'에 지원하게 되었다.

면접... not easy...

말했듯이 제대로된 프론트엔드 개발 경험이라던가, 어디 개발동아리 들어가서 협업경험이 있다던가 하는 상황이 아니었다. 다만 보여줄 수 있었던 건 다음과 같았다.

개발동아리는 '아니지만' 글쓰기 소모임을 운영하며 겪었던 소통 경험, 평소 가지고 있던 프론트엔드적 관점 및 철학, 마지막으로 본 동아리 활동을 잘 이해하고 있고 나는 그 속에서 성장할 것이다

라는 메시지를 잘 녹여내고자 노력했다. 실제로도 의도한 바를 나쁘지않게 잘 녹아있는 것을 볼 수 있다. 음, 이부분은 해커톤을 끝내고 나서 보니 조금 수정 및 추가되어야할 거 같다. 참신한 아이디어 부분은 아마도 화려한 인터랙티브 디자인, 모션그래픽 정도를 염두에 두고 쓴 거 같다. 하지만 막상 해커톤을 준비하면서 느꼈던 건 후에 수정해도 무너지지않게 초반 구조 잘 짜기가 중요하다는 것이었다. 인터랙티브 디자인의 화려함은 담백하고 정교한 구조위에 쌓여 올라간다. 역시 뭐든지 기본이 튼튼해야한다.

각설, 열심히 준비한 면접은 나쁘지 않았다. 덕분에 합격했고, 그 이후의 여정은 다음 편에서 이어서 써볼 생각이다.