드디어 나의 인생 첫 해커톤이 끝났다!

멋쟁이사자처럼 해커톤은 내가 멋사에 지원할 때 가장 기대한 부분이기도 하다.
인스타 릴스에서만 보던 큰 공간에 천 명이 넘는 사람들이 모여 다같이 밤샘 코딩을 하다니!! 정말 낭만적이당ㅎ 모두 같은 단체 티셔츠를 입는 것도 너무 기대되었다..

우리 팀이 만든 서비스 '바로지금(BarrowNow)' 이다!
https://baronow.netlify.app/

(서버를 내리면 원활히 작동되지 않을 수 있음 주의..)

---

2024 멋쟁이사자처럼 해커톤 일정

https://likelion.notion.site/12th-HACKATHON-4cbaf4e34dd1441d9341aa46d197637f

해커톤 공식 일정은 다음과 같았다.

날짜	일정
7/5(금) 14시	주제 공개
~7/14(일) 23:59	해커톤 참가 신청
8/6(화)~8/7(수)	오프라인 해커톤 본선

---

느낀점

기획

가장 먼저, 일정대로 7월 5일에 주제가 공개되었다.
주제는 바로..

“IT 기술을 활용하여 현대인의 건강 (wellness) 문제를 해결할 수 있는 서비스를 개발하시오.”

였다.

사실 7월 5일에 해당 주제가 나오고 나서 상당히 당황했었다! 몇 개월 전에 있었던 2024 멋쟁이사자처럼 아이디어톤과 주제가 완전히 동일했기 때문이다.

웰니스.. 아이디어톤을 진행하는 약 한 달간 고통받은 주제이다.
주제 특성상 적용될 수 있는 범위가 너무 넓고, 개념도 추상적이어서 딱 적당한 서비스를 떠올리기가 어려웠던 것같다. 그럼에도 불구하고 우리 '아사우사'팀은 본선까지 진출했지만!!! (아사우사랑해)

또 이미 수많은 아이디어가 아이디어톤 때 나왔기 때문에, 새로운 신선한 아이디어를 찾기는 힘들 것이라고 생각하여 더더욱 멘붕이 왔던 것같다.

그래도 별 수 있겠나! 화이팅 해보기로 했다. 개인적으로 이번에 꾸려진 우리 팀이 너무 맘에 들어서 더 열정이 생겼다!!!

약 1~2주간 열심히 기획 관련 회의를 거친 결과, 우리는 '중고 운동 용품 대여 서비스'를 만들기로 하였다.

개발

그렇게 PM의 주도 하에 서비스가 확정되고 디자이너는 열심히 디자인을 하기 시작했다.
이때 조금 아쉬웠던 점은, 프론트가 할 수 있는 일이 많이 없어 시간을 최대로 사용하지 못했던 것이다.

그도 그럴 것이, 기획 단계가 끝나고 디자이너는 디자인을 시작하면 되고 백엔드는 ERD를 작성하고 대략적인 구조를 구축하는 등의 작업을 할 수 있지만 프론트는 항상 디자인과 백엔드의 API를 필요로 하기 때문이다...
이러한 문제는 프로젝트 전 단계에서 느껴진 문제였다.

그치만 지금 생각하면 프론트에서도 디자인이나 API가 나오지 않은 상황에서, 어떤 것을 클릭하면 어떻게 되고, 어떻게 데이터들을 불러오고 출력되게 할지 플로우를 짤 수 있었을 것 같다!!! 다음 프로젝트부터는 꼭 이렇게 해야겠다고 다짐했다.

그렇게 디자인이 한 페이지 한 페이지 나오는대로 재빠르게 CSS를 구현하기 시작했다.
API도 나오는대로 연결했다.

처음에 프로젝트를 시작할 때는 우리가 짠 계획대로 작업이 척척 이루어질 것만 같았는데, 그게 생각보다 쉬운 것이 아니었다.
디자인, 백, 프론트를 거치면서 서로서로가 서비스의 기능에 대해 본격적으로 생각하다보니, 그제서야 군데군데 존재하던 허점들이 보이기 시작한 것이다.

그래서 결국 전체 프로젝트는 애자일(agile)하게 진행되었다. 개발 파트에서 문제점을 발견하면 PM이나 디자이너에게 보고하고, 둘은 이를 반영하여 수정하고, 개발 파트는 수정 사항을 또 코드에 반영하는 과정이 반복되었다.

개인적으로 하나를 완성해도 계속해서 수정사항이 생기다보니 애로사항이 있었던 것 같다.
이런 문제점을 해결하려면 어떻게 해야할까? 아직도 정확히는 모르겠다.
기획 단계를 더 오래 가져 기능을 더욱 정확하고 구체적으로 정하고, 여러 번 검토를 해야하는 등의 과정을 거쳐야 할 것 같다.

프로젝트 경험이 많아질수록 해결될 문제라고 생각한다! 처음은 누구나 서툴다..헷

개발을 하면서 겪은 어려움? 고민거리를 정리해보자면

• 컴포넌트 분리
• 함수 분리
• 파일 구조
• 깃허브 사용(협업)
• 팀원 간 소통
• styled-component 정의
• 반응형 구현
• 디자인 초안과의 일치

정도가 될 것 같다.

Q. 컴포넌트 분리?

어마어마한 컴포넌트들..ㅎㅎ
말 그대로이다.
하나의 jsx 파일에 어디까지의 컴포넌트를 작성해야 좋을지 판단하기가 모호했다.
또 무조건 분리하는 게 좋은 것인가? 하는 의문이 들기도 했다.

그래도 Header, Main, Footer와 같이 정말 기본적으로 분리하면 좋은 것들은 당연히 분리하고, ItemCard처럼 재사용되는 것들은 재사용되게끔 해주었다.

하나의 파일 안에 컴포넌트가 많아지는 것과, jsx 파일이 많아지는 것 중 어떤 게 더 나을까?
생각해 볼 문제인 것 같다.
나는 우선 시간 부족 문제로 하나의 jsx 파일에 많은 컴포넌트들을 때려넣는 방식으로 하기는 했다..ㅎㅎ
시간이 된다면 추후에 분리를 시도해보아야겠다.

Q. 함수 분리?

함수를 작성하는 방법에는 컴포넌트, 즉 jsx 파일에서 바로 위에 정의해주거나 / 따로 js 전용 파일을 만들어 함수만 작성하고 jsx 파일에서 import 하여 사용하는 방법이 있다.

전자의 방법은 해당 jsx 파일에서만 사용되는 함수(ex. handleClick, navigate)나 간단한 함수를 정의하는데 유용하고, 후자의 방법은 자주 재사용되거나 복잡한 함수를 정의하는데 유용하다.
또한 관례적으로 API를 사용하는 함수는 분리하여 사용하고는 한다.

후자의 방법에는 jsx 파일의 코드가 간결해진다는 장점이 있으나, 함수를 일일히 import 해주어야 하고 불러오는 과정에서 추가적인 문제가 생길 수 있다는 단점이 있다.
그러나 나는 코드가 길어지면 머릿속이 복잡해지기에 함수는 되도록이면 분리하는 타입인 것 같다!

크게 apis/utils 폴더를 만들어서 api를 사용하는 함수들은 무조건 apis 폴더에, 계산이나 출력 등의 기타 로직을 담당하는 함수는 utils 폴더에 넣어주었다.

Q. 파일 구조?

파일 구조도 굉장히 고민되었던 부분이다.
어디까지 파일을 분리하여 사용해야할지 고민이 되었다.

예를 들어 상품 상세 정보를 알려주는 goodsDetail.jsx 파일이 있고, 그 파일에 사용되는 달력이나 계산기 등의 컴포넌트가 있다면, 그것들을 모두 동일한 디렉토리에 두어야 할지 아니면 분리해야 할지 모호했다.

나는 개인적으로 물론 파일들이 구분되어 정리돼있으면 편리하지만, 그 폴더들을 모두 여닫으며 필요한 파일을 찾는 과정이 더 번거롭다고 느껴졌기에 일단 'components' 파일 한 곳에 모두 때려박기는 했다...ㅎ
다른 사람들의 코드를 톺아보여 다른 사람들은 어떤 스타일인지 알아봐야겠다.

Q. github 사용?

이번에 처음으로 github을 통해 제대로 된 협업을 해 보았다!
물론 나와 다른 프론트엔드 개발자 한 명, 총 두 명끼리의 협업이었지만 충분히 github 사용법을 익힐 수 있었던 것 같다.

브랜치의 용도, 머지 시 충돌 해결의 필요성 등에 대해 머리로 이해는 하고 있었지만 막상 실제로 github으로 협업을 해보니 브랜치가 꼬이기도 하고, 실수로 상대방이 열심히 작성한 코드를 삭제하기도 하는 등의 불상사가 발생했다.

하지만 이렇게 시행착오를 겪으면서 해커톤이 끝나갈 즈음에는 github를 수월하게 사용할 수 있게 되었다! 특히 git stash라는 명령어를 처음 알게 되어 매우 유용하게 사용했다.ㅎㅎ 스태시 최고

이번 프로젝트는 워낙 기간이 짧았기도 하고 주로 agile하게 진행되었기 때문에 브랜치는 그냥 개인의 이름으로 만들어 사용했는데, 다음에는 기능 별로 분리하여 사용해보아야겠다고 생각했다.

잘 사용한다면 정말 좋고 대단한 프로그램인 것 같다.

그리고 github를 시각화해주는 'GitKraken'이라는 프로그램도 원래 알고는 있었지만 이번에 제대로 사용해 볼 수 있었다.
GUI로 시각화해주는 것이 참 편리한 것 같다. 그치만 아직은 여기서 pull/push 등의 작업을 하기에는 좀 무서워서 아직 vscode terminal로 진행하고 있는데, 앞으로는 이 gitkraken을 자유자재로 다룰 수 있도록 많이 공부해야겠다.

Q. 팀원 간 소통?

이번 프로젝트를 하면서 팀원 간의 소통도 매우 중요하다고 느꼈다...
여러 명이 협업을 하면 머리통과 손발 수가 많은 만큼 배로 많은 일을 할 수 있지만, 그만큼
특히 서로 원격으로 작업할 때는 각자 어떤 부분을 맡아 작업하고 있는지 모르니 본인의 현 상태를 알리는 것이 매우 중요한 것 같다. 상대방이 딱히 물어보지 않아도 tmi를 남발해야 한다.

그리고 기록<<매우 중요하다!
실시간으로 소통할 수 있다면 좋지만 그렇지 못하는 경우가 대부분이기 때문에, 다른 팀원이 언제 어디서라도 볼 수 있도록 나의 진행상황과 요구사항, 발생한 문제 등을 기록하는 게 좋다고 느꼈다.
궁금한 게 생겼을 때 상대에게 질문을 하고 답변을 올 때까지 기다리다 보면 작업의 흐름이 끊기기도 하고, 시간이 계속해서 지연되기 때문이다. 필요한 게 있을 때 바로바로 찾아볼 수 있으면 좋은 것 같다.

그리고 이렇게 해야할 일들을 가시적으로 리스트로 정리해두니 진행 상황을 시각화해서 볼 수 있어서 좋고, 한 작업을 완료한 후 어떤 것을 할지 바로바로 알 수 있어 좋았다.

Q. styled-component 정의?

이게 무슨 말이냐하믄.. 예를 들어 밑의 코드를 보자.

여기서 지금은 '대여료 계산기' 텍스트를 가진 부분이 그냥 <div> 태그로 되어있는데, 하려면 이것까지 styled-component로 바꿀 수도 있겠다. 예를 들어서 <Title>과 <TitleText> 처럼 말이다.

두 방법 중에 어떤 것이 좋을지는 아직도 확실하지 않지만, 내가 생각한 장단점을 정리해보았다.

Styled-component	id/class
- 이름이 직관적이다	- 불필요하게 과도한 styled-component의 작성 방지
- CSS를 별도의 공간에 편리하게 작성할 수 있다	- id와 class 관련 기능을 사용하기 용이하다
- map 함수 등에서 재사용이 쉽다	- 개발자 도구에서 외계어로 표현되지 않고 이름 그대로 뜬다

styled-component는 코드의 하단부에 CSS를 간결하게 작성할 수 있다는 점이 가장 큰 특징인 것 같다. 그치만 전체 코드에서 한 번만 쓰이고, 간단한 것들은 오히려 그냥 <div> 태그에 id나 class를 부여하여 사용하는 것이 더 나은 것 같다.

Q. 반응형 구현?

이것도 참 난제였다...
시간이 많았다면 반응형까지 무조건 구현하고 싶었는데 절대적인 시간의 부족으로 결국 구현하지 못했다.

그치만 미디어쿼리로 따로 구현하지 않아도 rem, % 등의 상대적인 사이즈 기준들을 사용했다면 그래도 대충은 반응형이 되었을 것 같은데, 시간이 너무 촉박하고 정신이 없다보니 pixel을 너무 많이 사용하여(특히 font-size로) 창 사이즈를 줄이면 글자들이 자기주장을 강하게 하게 되었다!!!! 흑흑

다음에는 CSS를 구현하면서 꼭 조정되어야 할 폰트 크기는 rem으로 하여야겠다고 다짐했다...

Q. 디자인 초안과의 일치?

이번 프로젝트에서 디자인 툴로는 Figma를 사용했다.(아마 대부분 이것을 사용할 것 같긴 하지만)

Figma에는 '개발자 모드'가 따로 있어, font-size, background-color, padding, margin 등의 속성들이 디자이너가 지정한 대로 모두 알려준다.

그치만 이렇게 나와있는 사이즈 그대로 지정했을 때의 문제가 있었다... 전체 페이지의 사이즈가 달라 디자이너가 의도한 대로의 레이아웃이 나오지 않는 것이었다.
그래서 어쩔 수 없이 그냥 눈대중으로 사이즈 수치를 지정할 수 밖에 없었다.

Figma의 개발자 모드로 사이즈를 더욱 정확하게 보고 적용할 수 있는 방법을 공부해야겠다고 생각했다. 디자이너가 열심히 디자인 해주었는데 100% 반영해주지 못한 것 같아서 미안했다...ㅠㅡㅠ

총평

그나마 이전에 학교 수업에서 팀 프로젝트로 비슷한? 스케일의 서비스를 만들어 본 적이 있어서 그때보다는 시행착오를 덜 겪은 것 같다. 그러나 아직 완벽한 협업을 진행하려면 한참 멀었음을 느꼈다...

그리고 역시 프로그래밍은 개념적으로 공부하는 것보다 이렇게 실전으로 들어가 몸으로 부딪히는 것이 가장 베스트라는 것을 다시금 느꼈다!!
실력 향상이 아닌 '생존'을 위해 열심히 공부를 하게 된다.. 팀원들의 기대치가 있으니 더 열심히 하게 되는 것 같다.

앞으로도 더 많은 프로젝트를 해보고싶다고 느꼈다!!!!

우리 팀원들 모두모두 수고했어 ~.~