2023 SW중심대학 공동해커톤 후기 및 개발과정 (feat. 병원맛집 - 프론트엔드)

 

1.  행사참여 👍

---

2023 SW중심대학 공동해커톤 참가 후기를 작성하고자 한다.

 

6전공과 취업 준비를 병행하며 학기의 끝을 향해 달리고 있을 무렵 학교 홈페이지에 해커톤 공지사항이 올라왔다.

인턴과 동아리 활동은 여러번 해보았지만 해커톤 경험은 없었기에 이번 기회에 참가하고자 하였다.

 

학교에서 5인에 선발이 되고, 해커톤에 6월 28일부터 6월 30일까지 천안의 한 연수원에서 해커톤에 참여했다.

 

청주에 살고있는데 마침 청주공항에서 픽업이 가능하다고 하여서,

아침에 청주공항에서 다같이 출발했다.

 

다들 다 같이 왔는데 나만 혼자여서 뻘쭘하긴 했지만 행사장에서 팀원들과 친해질 생각에 설렘 가득이었다!

 

전날 PT 과제를 새벽 4시까지 작성 하느냐고 정신도 없었고 피곤했지만

행사장에 들어선 순간 분위기에 압도되어 몰입하게 되었다는 사실

 

 

신문사에서 취재도 오고 생각보다 행사가 크게 진행되었다. 

간략한 설명을 듣고 각자 생각해온 프로젝트 아이디어에 대한 발표가 진행되었다.

그 중 마음에 드는 주제가 몇 가지 있었는데, 기술 스택이 안맞거나 주제가 모호해서 생각과는 다른 주제에 합류하게 되었다.

 

해커톤의 일정에는 개발 관련 강연도 있었는데, 생각보다 알차서 집중해서 들었다.

나머지 시간은 전부 팀원끼리 개발을 하는 시간이었고 숙소도 제공되어서 첫 째날에는 새벽 5시에 들어가 한숨 자고 나왔다.

 

2. 프로젝트 기획 📜

---

각기 다른 5개의 대학에서 모인 조원들 :)

우리 팀은 프론트엔드 개발자 2명, 백엔드 개발자 2명, 디자이너 1명으로 구성되었다.

 

 

2-0. 하루가 지나고 변경된 프로젝트 주제 🫣 

---

 

프로젝트 발표가 24시간도 채 남지않은 2일차 점심 무렵, 프로젝트 주제가 변경되었다.

 

기존에는 동물병원 관련된 커뮤니티 서비스였지만 

해커톤에서는 아이디어 구현보다는 아이디어에 조금 더 초점을 맞춰서 평가한다고 하여서 주제 변경을 제안했다.

 

 

 

이번 해커톤에서 수상에 목적을 두지는 않았다.

 

해커톤이 처음이기도 했지만 끝난 다음날에 곧바로 한 기업의 면접을 봐야했고 해커톤 중간에 PT 과제 제출까지 해야했기 때문이다. 

그래도 나는 이번 해커톤에서 상업에 목적을 두지 않고 실생활의 불편함을 해결할 수 있는 서비스를 기획/개발 해보고 싶었다.

 

팀장님이 기존에 선정한 주제도 너무 좋았지만, 해커톤의 취지와는 살짝 빗나간다고 생각을 했고

디자인과 개발 과정에 참여하면서 팀원들과도 계속해서 조금 아쉽다는 의견을 주고 받았다.

 

나는 그래서 중간에 패기넘치게

"우리 아쉬워하지 말고, 과감하게 주제 변경하자. 안되는 부분은 내가 다 맡아서 할게!" 하며 팀원들을 불러모았고

 

조금만 생각을 바꾸면 유의미한 주제가 될 것 같다고 생각하여서 프로젝트 진행 중간에 주제를 변경했다.

 

 

서비스의 기획 방향이 도저히 잡히지 않아서, 기획 분야의 멘토님께 늦은 밤이었지만 멘토링을 요청드렸다.

 

해커톤에서 가장 좋았던 점 중 하나는 현직에 계시는 다양한 분야의 멘토님께 멘토링을 받을 수 있는 것이었다.

덕분에 정말 많이 배웠고, 프로젝트 관련 내용이 아니어도 평소 프론트엔드 개발을 진행하며 궁금했던 부분들을 많이 여쭤보았다.

 

특히 기획 과정에서 멘토님들의 도움을 많이 받았는데 멘토님들의 생각과 팀원들간의 생각이 정확하게 일치하여서 프로젝트의 주제를 변경하게 되었다.

 

다만 하루동안 진행했던 디자인과 개발 결과물들을 전부 뒤엎고 다시 시작해야 했기에,

최대한 핵심기능만 담는 UX/UI로 설계하여 개발을 진행했다.

 

 

그래서 마침내 최종적으로 팀에서 선정한 주제는

특정 병명을 입력하면 내 주변에서 사용자가 입력한 병의 치료 후기가 가장 좋은 병원을 추천해주는

병원맛집 : 내 주변 질병 맞춤형 병원 추천 서비스 이다.

 

 

2-1. 니즈분석

---

평소 병원을 찾을 때 '특정 병'을 치료받기 위해서 가는 것이지 '특정 병원'을 가는 건 아니라고 생각했다.

그렇다면 병원을 고를 때 어떤 기준으로 선정을 하는가에 대한 궁금증이 있었고,

각종 설문조사를 찾아보고 인터뷰를 실시한 결과 집에서 거리가 가장 중요하다는 니즈를 파악할 수 있었다.

 

그래서 우리는 다음과 같이 많은 정보를 찾아서 병원을 선정했지만,

과잉 치료를 받은 만 24세의 김민준이라는 페르소나를 설정하여 아이디어를 구체화 시키고자 하였다.

 

 

2-2. 프로젝트 목적

---

최종적으로 도출한 프로젝트의 목적은 다음과 같았다.

 

1. 사용자들이 자신의 증상에 맞는 맞춤형 치료를 받을 수 있도록 도와준다.

2. 집 근처에 있는 병원을 쉽게 찾을 수 있도록 한다.

 

서비스의 타켓층은 다음과 같았다.

 

1. 집 근처에 있는 병원을 찾는 사람

2. 이사를 와서 자신이 사는 동네에 병원이 어디 있는지 모르는 사람

3. 과잉 or 불친절 진료로 손해를 본 적이 있는 사람

4. 특정 질병치료의 후기가 가장 좋은 병원을 가고 싶은 사람

 

관련 아이디어가 많이 나왔지만 그 중에서 1번과 4번에 초점을 맞추어서 서비스를 개발하고자 하였다.

 

 

3. 프로젝트 개발 👨🏻‍💻

---

다들 밤을 새면서 개발하고 있는 모습. 열정가득!

프론트엔드 개발은 React와 Typescript를 이용해 개발했고, 백엔드 개발 주요 기술 스택은 Node.js였다.

 

거의 대부분의 참가자들이 밤을 샜고, 우리도 3일 합쳐서 3시간을 제외하고는 개발에 열중했다.

체육관은 지하에 있었는데, 해가 떴는지도 모르고 개발에 열중한 경험은 처음이었다

중간에 간식들도 먹으면서 휴식을 취하곤 했다

 

내가 속한 '식스센스' 팀원들의 대부분은 프로젝트 경험이 없었기에, 상대적으로 많은 내가 개발 과정을 총괄하면서 프로젝트를 이끌려고 노력했다. 이 과정에서 많이 배웠다. 처음에 프로젝트를 진행했을 때 느꼈던 감정들을 다시금 느끼고 내가 부족한 부분을 계속해서 채워나가려고 했다.

 

나도 잘 모르지만 어떻게 구현 하면 좋을지 디자이너, 백엔드, 프론트엔드 관점 전부를 생각하면서 진행하니 힘들기도 했지만

짧은 기한 내에 개발 과정을 전반적으로 바라볼 수 있는 시선이 생겼다고 느꼈다. 

 

 

3-1 최종 결과물 🖥

---

 

 

 

 

3-2 개발 플로우 및 아키텍처 📈

---

전반적인 어플의 플로우를 설명하면

 

1. 사용자가 추천받고자 하는 질병을 입력한다
2. 현재위치 기반의 주변 병원의 데이터를 분석한다
3. 병원목록 데이터를 전달받고 각 병원의 블로그 리뷰를 각 5개씩 추출한다
4. 프롬프트 엔지니어링을 통해 ChatGPT로 부터 리뷰를 분석받는다
5. 리뷰의 긍/부정을 판단하여 새롭게 별점을 부여한다.
6. 최종적으로 사용자에게 현재 위치 주변의 병원 5개를 추천한다
7. 사용자는 추천받은 병원을 클릭하면 구글맵 API를 활용하여 병원의 위치를 보여준다.

7번에 적혀있는 구글맵을 활용하는 부분은 QA 과정에서 추가된 기능이다.

 

우리 팀에서 고려해야할 중요한 부분 중 하나는 어떻게 병원의 리뷰를 분석할 것인지에 대한 문제였다.

 

1) 병원의 네이버 지도 리뷰를 크롤링하여서 데이터를 분석한다.

2) 병원의 네이버 블로그 리뷰 링크를 ChatGPT에 전달하여서 데이터를 분석한다.

 

가장 보편적인 첫 번째 방식은 시간이 오래걸리고 GPU가 있어야 실시간으로 처리를 할 수 있는 문제가 있었고, 자연어 처리 및 감정분석을 추가로 진행해야 되었기에 기한내에 끝낼 방법이 없었다.

 

그래서 두 번째 방식인 ChatGPT를 활용하여 리뷰를 분석하는 방향으로 구현했다.

ChatGPT를 활용한 프로젝트를 진행한 적이 없어서 멘토님들께 많은 도움을 구했고

'프롬프트 엔지니어링' 기술을 알게되었다.

 

"프롬프트 엔지니어링이란 인공지능 분야의 한 개념으로 AI로부터 높은 수준의 결과물을 얻기 위해 적절한 프롬프트를 구성하는 작업"을 얘기하는데 이를 도입하기 이전과 이후의 응답 결과물이 확연히 달랐다.

다음은 참고했던 레퍼런스 중 일부이다.

https://www.codestates.com/blog/content/프롬프트-프롬프트엔지니어링

AI 프롬프트와 프롬프트 엔지니어링 | 정의와 예시 - 코드스테이츠 공식 블로그

 

기술스택 아키텍처는 다음과 같았다.

Front-end 

- React

- Typescript

- Styled-domponenets

- Recoil

- Vercel

- Yarn

 

Back-end

- Node.js

- AWS RDS

- AWS EC2

- ChatGPT API

 

 

같이 작업한 프론트엔드 팀원과 React 기술 스택이 동일하였고, SPA로 구현하고자 React로 개발을 진행하였다.

팀원은 Javascript 위주로 프로젝트를 진행했었다고 하여서 고민을 했지만, 실무에서 많이 쓰이고 타입 미설정으로 인한 오류를 방지하고자 Typescript를 도입하여 개발을 진행했다. 

전역상태 관리 라이브러리로는 Recoil을 활용했고, 배포는 Vercel을 이용하여 배포했다. 

 

* 서버비용이 지원이 안되어서 아쉽지만 현재는 서버를 내린 상태이다. 

 

3-3  프론트엔드 개발과정 및 배운점 🙏

---

 

아무리 시간과 정신이 없더라도, 페이지와 컴포넌트 별로 파일과 폴더를 분리하여 개발을 진행했다.

Props drilling 문제가 발생하여서 전역 State 값을 Recoil 라이브러리를 활용하여서 관리했고 덕분에 리렌더링 횟수도 줄이고 

Props를 무분별하게 하위 컴포넌트로 전달하는 상황도 피할 수 있었다.

 

 

 정규식을 활용한 문자열 검사 

프로젝트를 진행하면서 처음 알았던 메서드 중 하나는 test() 메서드였다.

정규표현식은 암호처럼 보이지만 문자열을 검사하고 처리할 수 있는 강력한 도구로 사용되기도 한다.

 

해당 페이지에서 사용자가 병명을 잘못입력하면 서버의 요청 횟수를 최소화 하기 위해서 요청이 되지 않도록 막아야 했다. 

const pattern = /([^가-힣\x20])/i;

const postInfo = async () => {
  if (pattern.test(value)) {
    return alert('입력이 올바르지 않습니다.');
 }

정규식을 활용하여서 자음과 모음으로만 입력된 오타와 영문자를 인식하여서 다음 페이지로 넘어가지 않도록 분기처리 했다.

 

CSS Flex + gap 

 

또 한 가지는 평소 UI를 개발할 때 

컴포넌트의 배치를 어떻게 구현하는지에 대한 궁금증이 늘 있었다.

방법은 여러개가 있을 것이고 내가 생각한 2가지는 다음과 같았다.

 

1. 부모 요소의 Position을 relative, 자식 요소 absolute로 두어서 절대적인 위치로 배치를 하는 방법

2. display를 flex로 두고 gap, margin, paddin 등을 설정하여 배치 하는 방법 

 

구름 기업에 재직하고 계시는 프론트엔드 멘토님께 도움을 청하여 궁금증을 해결했고

실무에서는 주로 2번 방법을 사용한다고 하였고 이번 프로젝트에서도 2번 방법으로 구현하려고 노력했다.

 

1번 방법은 하드코딩의 느낌이 강했고, 브라우저마다 다르게 보일 수도 있는 문제점이 있었다.

물론 2번도 반응형을 고려해야 하지만 1번보다는 더욱 직관적이고 개발자들이 알아보기 쉬운 방법이었다.

 

 

export const InputWrapper = styled.div`
  display: flex;
  justify-content: center;
  align-items: center;
  gap: 20px;
`;

코드 중 일부를 가져왔는데, gap의 적절한 사용 방법을 처음 알게되었다

 

gap을 활용하려면 특정 컴포넌트 부분의 각 요소들의 간격이 일정해야 하는데, 디자인적인 요소가 수정될 필요가 있었다.

디자이너분도 UI 설계가 처음이었기에 함께 배워가면서 어떻게 하면 더 효율적으로 협업을 하고 개발 코드를 작성할 수 있을지 충분히 고민할 수 있는 기회였다.

 

여러 개 버튼 중 하나만 클릭되게 만들기  

 

진료과목을 선택하는 페이지에서 사용자가 1개만 클릭할 수 있도록 구현해야 했다.

state 값을 이용해서 구현하는 것까지는 알고 있었는데, 어떻게 하면 더 직관적이고 간소하게 코드를 작성할 수 있을까 고민했다.

const [isSelected, setIsSelected] = useState([
    false,
    false,
    false,
    false,
    false,
    false,
    false,
    false,
    false,
    false,
    false,
    false,
    false,
    false,
  ]);
  
  const keyword = [
    '내과',
    '비뇨기과',
    '산부인과',
    '신경과',
    '신경외과',
    '심장내과',
    '안과',
    '외과',
    '이비인후과',
    '정신과',
    '정형외과',
    '치과',
    '피부과',
    '항문외과',
  ];

  const handleKeywordClick = (idx: number) => {
      const data = isSelected.map((item, index) => {
        if (index === idx) {
          return true;
        } else {
          return false;
        }
      });
      setIsSelected(data);
  };

<KeywordBox>
  {keyword.map((keyword, idx) => {
    return (
      <KeywordBtn
      	key={idx}
        value={idx}
        onClick={() => handleKeywordClick(idx)}
        selected={isSelected[idx]}
      >
        {keyword}
      </KeywordBtn>
    );
  })}
</KeywordBox>

 

기존에는 단순히 state 값을 버튼 수만큼 두어서 클릭할 때마다, 클릭된 버튼의 index를 판단하여 나머지 부분은 False로 변경하고 클릭된 부분만 True로 변경하여 state 값을 변경하였다.

 

이렇게 해도 기능적으로는 문제가 없지만, 버튼이 수십개 수백개가 된다면 코드가 불필요하게 길어지게 될 것이다. 

또한 버튼의 수를 예측하지 못하게 될 때 어떻게 하면 좋을지에 대한 고민이 있었다.

 

자바스크립트를 사용하면 다음과 handleKeywordClick 함수의 로직만 변경하면 구현할 수 있다.

코드의 수가 현저히 줄어든 것을 확인할 수 있다.

const [isSelected, SetIsSelected] = useState(false);

  const handleKeywordClick = (idx: number) => {
      const newArr = Array(keyword.length).fill(false);
      newArr[idx] = true;
      SetIsSelected(newArr);
   };

 

하지만 나는 타입스크립트를 사용하고 있어서 Type 에러가 발생했다.

 

 

state 값에 Type을 지정해주지 않아서 발생한 오류였는데 

다음과 같이 형식을 지정해주어 문제를 해결할 수 있었다.

 export interface Props {
    [key: number]: boolean[];
  }

const [isSelected, SetIsSelected] = useState<Props>({});

 

앞서 도움을 받았던 멘토님께 다시 찾아가 여쭤보겠다는 약속을 했는데,

개발 해야될 부분이 너무 많이 남았어서 코드가 길더라도 우선 1번 방법으로 코딩을 한 후 추후 개선하였다.

( 해커톤 끝날 때 멘토님께서 어떻게 알려줄지 고민 해놨는데 왜 안왔었냐고 해주셔서 죄송했고 정말 감사했다 ㅎㅎ )

 

4. 프로젝트 발표 🙋‍♂️

---

발표시간은 팀당 5분이 할당되었고 내가 발표를 맡았다.

 

발표직전 포토존에서 찍은 '식스센스' 단체사진!

다들 열심히 살다가 개발자가 되어 꼭 다시 만나기로 했다

 

약 200명의 사람들 앞에서 발표를 하는 경험은 처음이었다.

걱정도 많이 되었고 떨리기도 했지만, 많은 사람들 앞에서 발표하는 경험을 해보고 싶었다.

다행히 발표를 문제없이 끝냈고 홀가분하게 내려왔다.

 

헤커톤에서는 구현 상관없이 사회문제에 초점이 맞춰져있는 아이디어와 새로운 기술을 사용하는 아이디어에 초점이 맞춰져 있는 것 같아서 평가 기준이 조금 아쉬웠다. 아이디어와 구현수준에서 정말 잘했고 신박하다고 생각한 팀이 3팀 정도 있었는데, 3팀 전부 수상을 하지 못했기 때문이다 😞

 

발표 끝나고 프론트엔드 개발자분을 찾아뵙고 싶었지만,

대회 시간이 지체되어 중간에 일부 학생들은 버스 시간상 먼저 귀가해 만나뵙진 못했다.

 

우리 팀도 아쉽게도 수상은 하지 못했지만

2박 3일동안 최선을 다했기에 수상을 하지 못해도 다 같이 웃어 넘겼다.

이런 경험을 언제 다시 해보겠냐며 참가에 의의를 두었던 팀원들을 만나 정말 행복했다 !

 

 

발표가 끝나고 평소 관심을 가지고 있는 회사에 재직중인 멘토님께서 발표 칭찬을 해주셔서 기분이 좋았다.

프로젝트 마무리 단계에서 기획과 개발 과정에서 많은 도움을 많았는데, 마지막까지 자신감을 선물해주셨다.

너무 감사했습니다 :) 

 

5. 느낀점

---

1. 기획의 중요성 및 기획이 바뀌는 것을 두려워하지 말아라!

해커톤을 진행 하면서 기획의 중요성을 정말 크게 느꼈다. 초반 기획이 탄탄하게 잡혀있어야 개발이 수월하게 진행될 수 있다는 것을 느꼈다.

 

하지만 기획이 바뀌는 것에 두려워하지 않아도 된다는 것. 

우리 팀은 중간에 주제가 아예 바뀌었는데, 오히려 그 과정에서 기존 작성했던 코드를 바뀐 주제에 어떻게 하면 쉽고 빠르게 응용하여 적용할 수 있을지 고민해 볼 수 있었다. 

 

2. 유지보수 용이한 코드를 작성하는 것은 정말 중요하다!

또한 페이지와 컴포넌트별로 분리 하면서 개발을 진행했었기에, 코드를 재사용하고 수정하는 시간을 크게 줄일 수 있었다.

 

개발을 할 때 컴포넌트 별로 분리하고 중복되는 코드는 별도로 작성하는 등 유지보수에 용이하도록 했다. 덕분에 기획이 중간에 바뀌어도 기존의 코드를 재사용하여 빠르게 개발할 수 있었고, 팀원이 작성한 코드를 빠르게 이해할 수 있었다.

 

이를 통해 짧은 기한 내에 개발을 해야하는 상황이어도, 유지보수에 용이한 코드를 작고 중복 코드를 최소화 하는 것의 중요성을 깨달았다.

 

또한 핵심 기능만을 표현할 수 있는 UI와 UX를 디자이너 팀원과 함께 고민하며 사용자 경험을 최대화 시키는 방법을 탐구했다는데에 의의를 둔다.

 

3. QA는 선택이 아닌 필수!

 아무리 시간이 부족했어도 QA는 계속해서 진행했다. 개발이 먼저 끝난 팀원들에게 QA를 부탁하고자 Vercel을 활용하여 개발 버전을 배포했고 테스트를 진행하며 개발했다.

 

QA 과정에서 발견한 문제점은 '병명을 입력하는 인풋 창'에 오타가 발생해도 서버에 요청을 한다는 것.

이는 불필요한 서버요청이고 서버 비용이 증가할 수 있는 문제가 있었기에 정규식 표현을 활용하여 수정하였다.

 

또한 병원을 추천해주는 것에서 끝나면 사용자는 해당 병원의 위치를 지도 어플을 활용하여 재검색 해야하는 불편함이 있었다.

사용자 경험을 높이기 위해서는 병원을 클릭했을 때 지도로 위치까지 알려주는 기능이 추가 되어야겠다는 생각에 제출 마감 2시간 전에 빠르게 구글맵 API를 활용하여 지도 기능을 추가했다.

 

그 외로도 많았지만 이 2가지 기능은 멘토님들께서도 칭찬을 해주실 정도로 유의미한 기능들이었다. 

QA 과정을 거치지 않았다면 발견하지 못했을 문제점이었기에 QA의 중요성을 다시 한 번 깨달았다.

 

4. 혼자 고민하지 말고 함께 고민해라!

짧은 기간내에 개발을 해야하는 중압감 때문일까?

평소에는 쉽게 개발할 수 있을 것 같은 기능들도 쉽사리 진도가 나가지않았다.

초반에는 멘토님께 너무 사소한 질문을 하는 건 아닐까 하는 생각에 쉽게 다가가지 못했지만,

멘토님들께서 오히려 먼저 다가와서 여쭤봐주셔서 도움을 많이 받을 수 있었다.

 

이후부터는 충분히 고민을 해보아도 해결이 되지 않을 때면 멘토님들께 많이 여쭤보았다.

지금까지 어떠한 고민을 했었고, 어떠한 시행착오가 있었는지 충분히 설명을 드리고 도움을 받았다.

확실히 혼자 고민했던 부분을 함께 고민하니 쉽게 해결이 되는 문제들이 많았다.

 

혼자 고민을 하다보면 고정관념에 휩싸이거나, 구글링을 하더라도 현재 알고있는 지식 내에서만 머무를 확률이 높기 때문인 것 같다.

이번 해커톤에서 혼자가 아닌 '함께 고민하고 성장하는 것'의 중요성을 다시금 깨달았다. 

특히 개발자라면 이는 선택이 아닌 '필수중의 필수'라고 생각했다.

 

---

2박 3일동안 전형 진행중이었던 기업들의 면접준비와 PT과제를 병행하면서, 해커톤을 진행해야 해서 한숨도 못자고 참여했다.

팀원들 다 같이 쉴 때는 면접을 준비했고, 개발을 할 때는 해커톤에 온전히 집중했다. 

이 과정에서 지칠법도 한데 주변 팀원과 참가자들의 열정에 피곤도 잊고 몰입할 수 있었다.

이번 해커톤은 정말 색다르고 잊지못할 경험이다. 

 

해커톤에 참가하기 전에는 짧은 시간 내에 과연 유의미한 서비스를 개발하고,

이 과정에서 내가 배울 수 있는 것이 있을까? 하는 걱정도 있었지만 괜한 걱정이었다.

휴학을 하지않는 이상 다시 이 해커톤에는 참여하지 못하겠지만, 다른 해커톤에도 참여해보고 싶다는 생각이 들 정도이다.

 

힘들기도 했지만 즐거웠고, 개발자로서의 확신을 다시금 깨닫게 해주었던 경험이었다!