2025 하지톤 (hajithon) 후기

2025년 7월 26일 ~ 27일 양일간 진행된 하지톤 참여 후기를 정리해본다.

하지톤은 홍익대 시각디자인과 소모임 '하이픈'과 컴퓨터공학과 개발학회 GDG 가 연합하여 주최한 무박 2일 해커톤이다.

막연하게 나가보고 싶다고 생각하고만 있었는데, 지뎃시 개발팀에서 같이 나가보자고 해서 함께 나가게 되었다.

개발팀 BE 4명중 3명이 참여했고, 해커톤 4개 팀에 각각 한 명씩 쪼개져서 들어갔다 ㅋㅋ

 

해커톤은 21일에 먼저 킥오프를 진행해서 해커톤 주제를 발표하고, 팀원과 아이스 브레이킹 이후 기획과 관련된 아이디어를 이야기 하는 시간을 가졌다.

이번 해커톤 주제는 probability (확률, 가능성) 로 '우연', '랜덤' 이 주요 주제였다.

 

킥오프 아이디어 논의 때, 그냥 고민이 있을 때 일기에 적어보내듯이 그냥 편지 같은 곳에 적어보내면 누군가 랜덤하게 고민을 받아서 답변을 보내주는 익명 랜덤 펜팔? 같은 서비스를 아이디어로 냈다.

그리고 다른 팀원이 이를 조금 더 고도화해서 고민의 카테고리를 정해서 작성하면, 누군가 그 고민을 먼저 본 한 사람이 이를 보고 답변을 보내주고, 질문자는 답변에 반응을 남길 수 있는 기획으로 발전시켰다.

 

서비스의 이름은 posth 로 post 와 path 를 합친 뜻이라고 한다.

21일 킥오프에는 일정이 있어 일찍 나갔고, 23일 팀 내 기획 회의에서는 급하게 일정이 공유되어 다른 일정으로 참여하지 못했었는데, 다들 처음이라 어색한 상황에서 디자이너 분들이 주도적으로 기획해주셔서 감사하게도 해커톤 전에 기획과 기본적인 디자인 틀을 확정지을 수 있었다.

 

 

23일 회의를 거쳐서 간단한 와이어 프레임과 UI 디자인 초안이 나오기 시작했다.

25일 해커톤 전날 백엔드 팀원과 온라인으로 회의를 하면서 ERD 와 필요한 API 명세를 미리 작성했다.

API 명세를 작성하는 과정에서 기획의 동작 과정에 궁금한 점이 있어 코멘트를 남겨두었는데, 디자이너분들이 빠르게 확인해주셔서 코멘트를 활용한 간단한 논의를 진행할 수 있었다.

 

 

 

그리고 다음과 같은 화면 레이아웃이 나왔다.

항상 디자이너 작업물을 볼 때마다 어떻게 이렇게 깔끔하고 예쁜 디자인을 단기간에 빠르게 만들어 내시는지 신기하다.

디자이너 분들은 거꾸로 12시간 만에 어떻게 실제로 동작하는 시스템을 개발해내는지 신기해 하시려나..

 

 

 

해커톤 당일 오후 5시에 입장해서 스티커와 명패를 받았다.

(스티커 상단의 'Go! Hajithon' 파트는 떼어서 노트북에 붙였다)

 

간단한 행사 소개 이후, 해커톤에 진행될 공간으로 이동해서 바로 개발을 시작했다.

우선 어떤 서비스든 무조건 회원, 로그인 과정은 거의 필수로 존재해야 하기 때문에, BE 팀원에게는 회원 엔티티와 회원가입 API 를 부탁드리고, 나는 스프링 시큐리티 세팅과 로그인 코드 구현을 맡았다.

시큐리티는 초기 세팅 이후에 거의 건들지 않다보니 계속 까먹어서 전날에 미리 간단하게 실습해두었는데, 그럼에도 불구하고 중간에 막혀서 GPT 에게 물어물어가며 구현했다.

 

그래도 전날 다시 공식문서로 공부해보면서 (이제서야긴 하지만..) 스프링 시큐리티의 큰 청사진을 이해하였다보니, 해커톤에서는 1시간 정도 만에 로그인, 토큰 인증 구현을 마칠 수 있었다.

(고급 백엔드 스터디를 하면서, 계속 머리를 싸매며 영어 원서를 읽었더니 영어 공식문서를 전보다는 좀 더 빠르게 이해할 수 있는 능력?이 생긴 덕분이었다)

전에 해커톤 할 때는 하루종일 8시간에 걸쳐 로그인을 개발했었는데, 스스로도 성장한 것 같아서 뿌듯했다.

 

이후로는 먼저 작업을 끝낸 사람이 API 명세 리스트를 보고 플로우상 먼저 필요한 API 를 개발하는 식으로 유동적으로 조절해서 개발을 진행했다.

백엔드 팀원은 프로젝트 경험이 비교적 적고, 해커톤은 처음이라고 들어서 큰 기대없이 참여했는데, git 도 익숙하게 잘 사용하시고, 서버 개발도 처음에는 조금 어설픈(?) 점이 있었지만, 간단하게 수정 부탁드리면 척척 깔끔하게 처리해주셔서 중반부부터는 믿고 의지할 수 있어 든든했다. (서비스의 핵심 로직인 랜덤 편지 리스트 선발 로직도 팀원이 개발했다!)

 

해커톤을 진행할 때 스스로 세웠던 목표는

 

1. 최소한 API 는 다 개발하기

2. 가능하면 화면까지 다 개발해서 잘 돌아가는 완성된 프로젝트로 발표하기

3. 협업 과정에서 팀원과 트러블 생기지 않게 잘 의사소통하기

 

이렇게 3가지였다.

결과적으로 1, 3 번을 달성할 수 있어서 매우 만족스러웠다.

2번은 백엔드가 API 를 빠르게 만들어주는 것 말고는 직접 관여할 수 없어서 내가 컨트롤할 수 있는 환경이 아니었다.

그래도 프론트에 정말 잘하는 친구가 있어서 정말 많은 화면을 개발해주었고 핵심 로직도 모두 개발이 되어서 꽤 만족스러웠다.

 

하지만 하면서 아쉬웠던 점도 있었다.

 

1. 처음엔 중요하지 않다고 생각해서, 이후에는 귀찮아서 배포와 배포 자동화를 미뤘던 점

배포와 배포 자동화는 '해커톤에 발표할 서비스가 돌아가는 데에' 필수적이지는 않았다.

로컬에서 프백 코드를 모두 올리면 배포 없이도 충분히 돌아가기 때문이다.

하지만 개발 과정에서 프론트가 백엔드의 API 명세를 확인하려면 (직접 손수 적지 않는 이상) 배포 환경에서 스웨거 같은 자동 생성된 문서로 확인하는 방법 밖에 없었고, 그러려면 배포가 필수적이었다.

 

그래서 처음에는 간단하게 내 개인 서버에 배포해두고, 자동화는 귀찮아서 안했다.

(정확히는 자동화를 하면서 들어가는 공수 + 체크하고 디버깅하는 공수에 들어갈 시간에, API 를 하나라도 빠르게 만들어서 완성시키고 싶었다. 배포 환경 만드느라 API를 못 만드는 건 더 최악이니까..)

 

하지만 그랬더니 서버의 수정사항을 반영하려고 할 때마다 로컬에서 빌드하고 - 도커 이미지 말고 - 허브에 푸시하고 - 서버에서 이미지 받아서 - 컨테이너 다시 실행하는 과정을 계속 손수 반복해야 했으며, 심지어 이 과정에서 로컬에서 빌드하는 과정을 까먹고, 코드 커밋만 한 다음에 도커 이미지를 말아보내서 "왜 커밋했는데, 이미지가 안 바뀌지?" 라는 바보같은 행동을 1시간 동안 하느라 시간을 버렸다.

(자동화된 환경에 적응된 것이 이렇게나 무섭습니다..)

 

그냥 처음부터 각잡고 배포하고, https 적용하고, 배포 자동화까지 한 다음에, 프론트에게도 그냥 바로 버셀에 배포하고 반영할 때마다 기능단위로 배포 시키라고 했으면 실시간으로 디자이너와 백엔드가 배포된 환경을 테스트하면서 진행할 수 있으니 더 효율적이었을 것 같다.

 

이 과정이 없어서 프론트는 로컬에서 개발한 화면을 직접 프론트에게 보여줘가며 피드백을 받아 고쳤고,

백엔드는 프론트 배포가 되지 않으니, 해커톤 종료 1시간 전에야 프론트 배포 기능을 기반으로 서비스를 사용하면서 피드백을 남길 수 있었다.

 

 

2. 프론트에서 문제가 생겨 막히고 있을 때, 내 파트가 아니니까..라는 마인드로 방치한 점

('내 파트가 아니니까' 의 구체적인 의미는 '내가 아는 분야가 아니라서 어차피 도움이 되지 않을 것 같으니까' 이다)

백엔드는 새벽 4시경 (프로젝트 종료 3시간 전) 모든 API 개발을 마무리하고 테스트용 데이터 세팅, 자잘한 수정사항 반영 등 리팩토링 작업에 더 집중하고, 디자이너를 도와 발표자료 제작을 도와드리고 있었던 상황이었다.

 

그런데 개발 종료까지 2시간 정도 남은 시점에서 홈화면과 통계 / 기록 조회 화면을 담당하신 프론트 분이 개발에 난항을 겪고 계신 것을 확인했다.

개발 중에 몇 번 API 응답 형식에 대해서 확인을 요청드려서 그때마다 빠르게 확인을 해드렸다.

하지만 프론트는 내가 어차피 모르니까 도움이 안될 거라고 생각했고, (오히려 잘 모르는데 옆에 붙으면 방해될 것 같기도 했고..)

그래서 그저 기다리면서, 나도 완성된 화면을 보고 싶은데, 그 분이 막히시는 걸 보면서 초조하기도 하고, 내가 도움이 되지 못한다는 것에 답답함을 느끼고 있었다.

하지만 개발 종료 1시간 전 쯤, 그 분이 막히셨던 이유가 API 호출시 400 에러가 나는 문제에서 발생한 것임을 알게 되었다.

 

요청 형식과 관련된 문제라서 서버에는 로그가 남지 않았고, 일단 몇 가지 해결 방법을 떠올려 제시해드렸지만, 그 해결방법은 기존 프론트 코드를 수정하는데 공수가 많이 드는 방법이라고 하셔서 결국 API 를 request 요청 데이터가 없는 방식으로 수정하였다.

하지만 그렇게 수정하였음에도 같은 문제가 계속 발생했고, 결국 그 분이 담당하신 화면 중 통계 / 기록 조회 화면은 개발하지 못하고, 홈 화면은 다른 프론트가 담당해서 개발하는 방식으로 해결되었으며, 프론트는 개발 시간 내내 빠르게 시간에 쫓기며 개발해야 했다.

 

만약 내가 적극적으로 어떤 문제인지 찾아가서 여쭤보고, 먼저 선제적으로 API 를 고치면서 적극적으로 수정에 도움을 드렸다면 더 여유있게 디버깅해서 어쩌면 진짜 모든 화면을 다 완성한 채로 해커톤을 마감할 수 있지는 않았을까? 하는 후회가 남았다.

 

그리고 그에 더해 애초부터 나도 프론트 지식이 어느 정도 더 있었더라면 좀 더 팀에 도움이 되었을텐데 하는 후회도 남았다.

그래도 프론트 경험이 조금은 있으니 정 안되면 지피티와 물어가면서 화면 그리는 거 정도는 도움을 줄 수 있지 않을까 생각했었는데, react, styled-component, redux 로 간단한 프로젝트만 몇가지 만들었던 경험만으로는 복잡한 디렉토리 구조와 처음보는 tailwind css 로 작성된 프로젝트를 빠르게 이해하는데 한계가 있었다.

 

그래서 꼭 해커톤 뿐만이 아니더라도 (하지만 해커톤을 한다면 거의 반드시..) 프론트 경험을 조금 더 쌓을 필요가 있겠다는 생각이 들었다.

이 경험이 있으면 프론트와 의사소통할 때 좀 더 깊은 대화를 나눌 수 있을 것이라고 생각하고, 실제로 다른 프로젝트를 할 때도 위에 적었던 기초적인 프론트 지식만으로도 프론트에서의 문제를 논의할 때 같이 참여해서 의견을 몇 가지 제시할 수 있을 정도의 도움은 되었기 때문이다.

 

https://2025-team01-posth-web-red.vercel.app/

POSTH

 

해커톤 개발이 끝난 이후에는 팀 별 발표를 진행하고나서 사진을 찍고 마무리 하였다.

그런데 '주요기능의 개발은 되었는데 부가 기능의 개발이 되지 않았다' 는 것을, '서비스의 개발이 다 진행되지 않아서 시연할 수 없는 것' 으로 이해하는 의사소통의 문제로... 발표 때 다른 팀은 간단하게라도 진행했던 시연을 우리팀만 하지 않은 상황이 발생했다.

정말 깔끔한 UI 에 부드러운 애니메이션까지 곁들여진 완성도 높은 프로젝트라고 생각했는데, 시연을 하지 못해서 너무 아쉬웠지만..

 

그래도 중간에 미니게임에서 상금을 다 받아서 4만원어치 편의점 자유이용권을 받아 간식도 이것 저것 많이 받고,

야식 먹으면서 이야기를 나누기도 하고, 처음보는 프론트, 백엔드 팀원과 협업도 해보고, 같이 프로젝트를 하고 있는 프론트 친구와도 협업하면서 더 친해지고, 해커톤 끝난 이후에는 다른 팀에 참가했던 분들과 만나서 밥먹으면서 더 친해지는 계기가 되어 정말 의미있는 시간이었다.

 

다음에 또 해커톤에 나갈 수 있는 기회가 있다면 (하지만 이젠 졸업이라서 나간다면 성인 대상 해커톤으로 나가야겠지만..ㅠㅠ) 또 나가보고 싶다.

 

해커톤 준비하신 분들, 참여하신 분들 모두 고생 많으셨습니다~