각설, 개강을 했으니 뭐라도 해야지~하며 있던 차에 학생회에서 해커톤 공지가 올라왔다. 이름하야 KW-HACKATHON.

... 나가야겠지? 그렇게 시작된 우당탕탕 해커톤 도전기! 시즌 1 에피소드 0 시작!

팀 결성

공지가 올라왔다는 것조차 몰랐을 적에, 저번에 프로젝트를 같이 한 누님한테서 카톡이 왔다. 팀을 모집할때 신뢰할 수 있는 사람을 구하는 것은 매우매우 어려운 일이기에, 덥석 같이하자고 제안을 했다. 그렇게 이 팀(팀장 없음, 팀원 3명)의 전설은 시작된 것이다.

아 나머지 팀원 한명은 그 누님이랑 같이 하기로 했던 사람이란다. 그렇게 3인 팀이 된 우리는 4인으로 팀 결성을 하면 가산점을 준다는 것을 알았다.

가산점은 절대로 참을 수가 없기 때문에 냅다 23학번 선배님에게 같이 하자고 하였다. 생각해보니까 디자이너 데려오는게 낫나? 싶긴 했지만, 쩔수니까 엔지니어링으로 찍어눌러보자.

그렇게 팀을 짜고 아이디어 회의를 하다 보니까, 아니 이거 4인 가산점에 더불어서 다전공 가산점이 있더라고요???? 이럴줄 알았으면 다른 학과 사람 끌고왔지... 제발... 복수전공도 인정 부탁드려요... ㅎㅎㅎㅎ

왜.. 우당탕탕인줄.. 아시겟죠...?

아이디어 찾기

아이디어는 여러개가 나왔다.

1안. 배리어프리 맵: 휠체어 사용자를 위한 월계1동 언덕 반영 지도 (+엘리베이터 포함 경로)
2안. 사이버-인력사무소: 매학기 인수인계에 시달리는 사장님들을 위한 매뉴얼 제작기 (+ 메뉴얼이 있으니까 긴급 대타 구하기도 가능하겠네..?)
3안. 병원/약국 맵: 야간 운영/휴일 운영/24시간 운영 등 필터링이 들어간 의료 지도
4안. 폐지 수집 어르신들을 위한 경사 반영 지도: 1안과 매우 유사하다. 여러 목적지 설정과, 폐지 정보를 준다는 것 정도?
5안. 생활 인수인계 서비스: 재건축 아파트들이 많은 월계1동의 특징을 살려, 미용실 어디가 괜찮아요? 등 커뮤니티

투표 결과, 야호야호 내가 낸 2안이 당첨되었다~! 그런데 큰일났다. 팀원들이 뭔가 마음속에서 걸리는게 있는 것만 같다.

... 그렇게 아이디어 디벨롭 회의 전까지 몇개의 아이디어가 더 나왔다.

6안. 빌라 주차장 공유 서비스
7안. 마감세일 픽업 서비스
8안. 픽업 with 용기
9안. N개로 나눠서 담아주세요~ 픽업

사실 7, 8, 9안은 하나의 안건이기는 했다. 하지만 이미 있는 서비스라는 이유, 법적 리스크 등의 이유로 전부 기각되었다.

그렇게 10안이 탄생했다.

10안. 월계 이사 엔드-투-엔드 도우미 월퍼(월계 퍼날라)

대충 방 비교부터 대형 폐기물 처리, 계약서 불리 문항, 계약서 기반 Chatbot 등을 제공해주는 서비스였지만... 기각!

해커톤을 진행하며 이정도 규모의 팀에서 이렇게 많은 아이디어가 나온게 처음이라 당황스러웠다. 내 아이디어가 그렇게 별로였나...

아이디어 결정

그렇게 8시에 시작한 우당탕탕 아이디어 회의가 새벽 1시에 끝나고, 결국은 2안으로 가기로 했다...

사실 문제해결형 해커톤이 아니라, 서비스를 만들어야하는 해커톤이라 10안을 제외하고서는 BM이 빈약하거나 유사서비스가 있다는 것이 크게 작용했다.

10안은 사실 아이디어 회의가 끝나고 나서 나온 안건인지라, BM과 유사서비스 면에서는 자유로웠지만 주민투표를 많이 받지 못할 것이라는 의견이 있어 기각되었다.

이후에도 뭔가 주제가 마음에 들지 않는 눈치였다. 뭔가 다들 주제에 공감하고, 이 주제에 확신이 있어야 다들 의쌰의쌰해서 개쩌는 프로덕트가 나올 것 같은데, 팀장된 사람으로서 걱정이 많다.

그렇다. 내가 팀장이 되었다. 왜지?

어쨋든 팀명은 지역 단기근로. 줄여서 지단이다. 마스코트는 계란으로 하기로 했다. 지단 올라간 떡국이 먹고싶어졌다.

지원서는 아래에 첨부하겠다.

지원서

지원 동기

월계1동은 청년과 지역의 상생이 특히 중요한 지역입니다. 월계1동은 비교적 작은 생활권 안에 광운대학교가 자리하고 있으며, 광운대학교에는 2026년 4월 기준 학부생 8,393명과 대학원생 1,558명, 총 9,951명의 학생이 재학하고 있습니다. 서울시와 광운대학교 역시 월계1동 일대를 캠퍼스타운 사업 대상지로 지정하고, 대학·청년·지역·공공의 자원을 연결하는 지역 활성화 사업을 지속해 왔습니다.

이러한 지역에서 대학생의 아르바이트는 청년과 지역 상권이 가장 직접적으로 만나는 접점 중 하나입니다. 2026년 알바천국이 대학생 902명을 대상으로 조사한 결과 80.2%가 2학기 대학가 아르바이트를 계획하고 있었으며, 선호 업종은 외식·음료 53.5%, 유통·판매 38.3%, 서비스 31.4% 순이었습니다. 또한 근무지를 선택할 때 근무시간 42.2%, 근무지 위치 36.8%, 근무지까지의 거리 34.3%가 주요 고려 요소로 나타났습니다. 전국 대학생을 대상으로 한 조사이므로 월계1동 자체의 고용구조를 직접 보여주는 수치는 아니지만, 대학생의 아르바이트 수요가 학교 주변 생활권과 시간표에 밀접하게 영향을 받는다는 점을 보여줍니다.

저희가 찾은 문제는 지역의 업장은 학기와 관계없이 정해진 시간 동안 운영되는 반면, 대학생의 생활은 학기마다 달라진다는 점입니다. 같은 조사에서 대학가 아르바이트를 원하는 학생 가운데 34.2%는 3개월 이상 6개월 미만, 31.3%는 1개월 이상 3개월 미만의 근무를 희망했습니다. 전체의 65.5%가 6개월 미만의 근무를 희망한 것입니다. 학생에게는 자연스러운 학기 단위의 생활 변화가 업장 입장에서는 근무시간 재조정과 인력 교체의 원인이 될 수 있다는 점을 찾았습니다.

저희는 학생의 유동성 자체를 문제로 보기보다, 업장의 노하우가 구전이 아닌 문서로서 축적되어 이를 바탕으로 청년 인력이 지역 안에서 유연하게 이동할 수 있는 구조에 주목했습니다. 광운대학교와 주변 상권이 하나의 생활권 안에 밀접하게 연결된 월계1동이라면, 각 업장이 개별적으로 인력을 확보하고 교육하는 방식에서 벗어나 학생들의 경험과 가용 시간을 지역 전체가 함께 활용하는 새로운 상생 모델을 만들 수 있다고 보았습니다.

해결하고 싶은 문제 및 아이디어 개요

아르바이트 인력 문제는 새로운 사람을 구하는 것에 더불어 여러가지 추가 문제점이 존재합니다. 새로운 근무자가 들어올 때마다 점주나 기존 근무자는 매장의 업무 방식과 주의사항을 다시 교육해야 하고, 갑작스럽게 결원이 발생했을 때는 동종 업계에 종사했더라도 해당 업장의 특징을 몰라 충원을 못한다는 문제입니다.

실제로 아르바이트생을 고용하고 있는 점주 222명을 대상으로 한 조사에서는 82.0%가 ‘알바생의 갑작스러운 출근 노쇼·퇴사’를 인력 운영의 가장 큰 고충으로 꼽았고, 28.4%는 아르바이트생의 스케줄 조절을 어려움으로 꼽았습니다. 전체 점주의 76.2%는 급하게 바로 출근할 사람이 필요했던 경험이 있다고 응답했습니다. 그런데 즉시 출근할 사람을 새롭게 채용할 때 가장 많이 우려한 부분 역시 ‘업무 적응 및 업무 역량’으로 41.0%를 차지했습니다.

즉, 지역 안에 지금 일할 수 있는 사람이 존재하는 것과 그 사람이 실제로 새로운 매장에서 일할 수 있는 것은 다른 문제입니다. 편의점이나 PC방, 코인노래방, 볼링장과 같이 1인 근무가 잦은 생활밀착형 업장에는 결제나 고객 응대처럼 다른 매장에서도 활용할 수 있는 공통 경험이 있는 반면, 시설 관리 방법, 물품 위치, 교대 절차, 마감 방식, 돌발 상황 대응처럼 해당 업장에서 다시 익혀야 하는 정보도 존재합니다. 이 때문에 기존의 구인·구직 서비스가 사람을 빠르게 연결해주어도 점주 입장에서는 새로운 사람을 실제 업무에 투입하기 위한 교육과 인수인계의 부담이 큽니다.

저희는 이 문제를 해결하기 위해 먼저 업장별 AI 룰북을 기반으로 한 온보딩 서비스를 제공합니다. 점주와 기존 근무자가 업무 과정과 주의사항을 평소 설명하듯 입력하면, AI가 이를 업무별/상황별로 구조화하여 해당 업장만의 지식베이스를 구축합니다. 새롭게 근무하는 사람은 출근하기 전에 필요한 업무를 학습할 수 있고, 근무 중에도 “이 상황에서는 어떻게 처리해야 하는지”, “마감할 때 어떤 순서로 해야 하는지” 등을 질문해 해당 매장의 정보를 바탕으로 즉시 답을 받을 수 있습니다. 사람이 교체될 때마다 처음부터 반복했던 교육을 한 번 구축하고 지속적으로 업데이트하는 지식으로 바꾸는 것이며, 중간 관리자 부재의 문제를 해결하는 것입니다.

그리고 저희는 이러한 온보딩 체계가 갖춰졌을 때 지역 단위의 인력 공유가 가능해진다고 보았습니다. 학생은 자신의 근무 가능 시간과 기존 업무 경험을 등록하고, 특정 업장에서 갑작스러운 결원이 발생하면 해당 매장 근무 경험, 유사업종 경험, 근무 가능 시간 등을 바탕으로 적합한 사람을 연결해줍니다. 익숙하지 않은 업장에 투입될 경우에는 기존에 구축된 AI 룰북이 빠른 적응을 지원합니다. 기존 플랫폼이 사람이 필요한 곳과 일하고 싶은 사람을 연결하는 것에서 시작했다면, 저희는 사람이 업장 사이를 이동하기 어렵게 만들었던 교육의 장벽을 먼저 낮추고 그 결과로 인력을 공유한다는 점에서 차이가 있습니다. 실제로 광운대 주변 매장 점장 인터뷰 결과, 결원 발생이 잦을 때가 존재하였으며 이때 온보딩을 도와줄 매뉴얼과 비슷한 매장 근무 경험이 있는 사람이 있다면 충분히 임시 고용할 의향이 있다고 응답하였습니다.

여기에 온보딩을 위해 구축한 업장 정보의 일부를 일반 사용자에게도 활용합니다. 예를 들어 콘센트 유무, 단체 이용 가능 여부, 좌석이나 시설의 특성, 이용 가능한 서비스 등을 등록해 두면 사용자는 “4명이 모여 노트북으로 공부하기 좋은 곳 있어?”와 같이 자신의 상황을 자연어로 질문할 수 있습니다. 시스템은 월계1동에 등록된 업장 가운데 사용자의 조건에 맞는 장소를 찾아 그 이유와 함께 추천합니다.

이렇게 되면 AI 룰북은 한 번 작성하고 끝나는 매뉴얼이 아니라 업장 내부에서는 새로운 근무자의 온보딩과 인력 공유를 돕고, 외부에서는 고객이 해당 업장을 발견하도록 돕는 지역 데이터가 됩니다. 점주에게도 교육 부담 감소와 인력 확보뿐 아니라 새로운 고객 유입이라는 서비스 이용 동기가 추가됩니다.

서비스의 지속가능성 역시 이 구조에서 확보하고자 합니다. 업장은 AI 룰북과 온보딩, 인력 공유 기능을 이용하기 위한 서비스 이용료를 지불하며, 일반 사용자가 이용하는 지역 탐색 서비스에서는 지역 업장의 프로모션과 광고를 별도로 제공할 수 있습니다. 광고 여부는 일반 추천 결과와 구분해 추천 자체의 신뢰성을 유지합니다.

결과적으로 학생에게는 공강이나 비어 있는 시간을 활용해 추가적인 근로 기회를 얻고 기존 아르바이트 경험을 지역 안에서 이어갈 수 있는 환경을, 점주에게는 반복적인 교육과 인력 공백에 대한 부담을 줄이면서 새로운 고객에게 발견될 수 있는 채널을 제공할 수 있습니다. 일반 주민과 학생에게도 필요한 조건에 맞는 지역 업장을 보다 쉽게 발견할 수 있는 방법을 제공합니다.

저희는 궁극적으로 업장의 노하우와 청년의 노동, 지역의 소비가 월계1동 안에서 연결되어 순환하도록 돕는 서비스를 만들고자 합니다.

끝!

그러니, 한 단어씩 분해해보겠습니다.

Origin(출처)?

만약, https://www.example.com/login에서 로그인을 한다고 했을 때, https://api.server.com/auth/login로 로그인 정보를 보낸다고 합시다.

위 주소로 로그인 요청을 보낼 때, 우리는 요청 헤더를 같이 보내게 됩니다. 이때, 요청 헤더는 다음과 같습니다.

POST /auth/login HTTP/1.1
Host: api.server.com
Origin: https://example.com
User-Agent: Mozilla/5.0
Accept: application/json

🧐 위의 예시에서 알 수 있듯, Origin은 어디에서 웹 콘텐츠로 접근했는지를 나타냅니다.

(Source: Toss Payments 개발자센터 문서)

구체적으로는, 웹에서 Origin은 접근한 URL의 프로토콜, 호스트(호스트 이름, 포트)로 정의됩니다.

Cross-Origin(교차-출처)

이렇게 Origin을 이해하였으니, Cross-Origin(교차 출처)이 의미하는 '출처가 교차한다'라는 것이 무엇인지 자연스럽게 이해가 될 것입니다. 정리해보면, Cross-origin은 자원을 주고 받으려는 두 출처가 서로 다르다는 뜻입니다.

만약 프론트엔드가 3000번 포트를, 백엔드가 3001번 포트를 사용한다면 프론트엔드에서 백엔드로 보내는 API 요청 또한 Cross-Origin에 해당하게 됩니다. 이는 URL의 포트가 다르기 때문입니다. 👍

또한, www.example.com에서 api.example.com으로 요청을 보낼 때에도 Cross-Origin에 해당합니다. 이는 호스트 네임(도메인)이 다르기 때문입니다. 즉, 서브 도메인이 다르면 다른 도메인으로 인식합니다. (⚠️엄밀하게는, 호스트 이름과 도메인 이름은 다릅니다. 이를 다룬 글은 추후에 업로드 하겠습니다.)

정리하자면,

CORS는 자신과 프로토콜 또는 호스트가 다른 출처로부터 자원을 가져오는 것이 되어야겠지만, 그렇지 않습니다. 😠 왜냐하면 CORS는 일종의 메커니즘이기 때문입니다.

그래서 CORS의 정확한 정의는 다음과 같습니다. 브라우저가 자신과 프로토콜 또는 호스트가 다른 출처로부터 자원을 가져오는 것을 허용하도록 서버가 허가해주는 HTTP 헤더 기반 메커니즘입니다. 즉, 사용자가 브라우저 내에서 https://example.com라는 웹사이트를 열었고 웹사이트가 https://server.com에게 "너희한테 있는 사진 하나만 쓸게."라고 요청을 보냈을 때 브라우저가 이를 읽을 수 있게 서버가 허가해주는 HTTP 헤더 기반 메커니즘입니다.

위 문장은 자칫 "서버가 허가한다"는 행위를 중심으로 볼 여지가 있습니다.🫢 그런데 사실 CORS는 브라우저의 보안 모델이기에, 서버가 아닌 브라우저를 중심으로 봐야합니다.

브라우저는 기본적으로 SOP(Same-Origin Policy, 동일 출처 정책)을 따르기에, 다른 출처에서 자원을 받아오면 이것을 차단합니다. 🥲 이 SOP 정책에 예외를 추가해주는 것이 CORS입니다.

즉, CORS라는 메커니즘으로 SOP 정책에 예외를 추가하여 다른 출처에서 자원을 받아오는 것을 허용하는 것입니다. 이러면 이제 CORS가 메커니즘이라는 것이 이해가 됩니다.

그래서 백엔드 개발을 하다보면, 혼자 Postman으로 테스트할 때는 잘 동작하던 코드가 프론트엔드와 연결되는 순간 CORS 에러가 발생하는 것을 볼 수 있습니다. 😭😭😭😭 (제가 그 문제를 마주쳐서 정리할 겸 블로그 글을 작성중이긴 해요...)

CORS의 동작 과정

기본적인 CORS 동작 과정

1. 브라우저는 교차 출처 요청(Cross-Origin Request)를 보낼 때 자동으로 Origin헤더를 추가합니다.

이 헤더는 CORS 요청을 판단하는 필수 신호입니다.

하지만, POST/PUT 등 일부 요청은 비-CORS 상황(Same-Origin Request)에서도 출처를 나타내는 헤더가 추가되기에 Origin 존재 -> 교차 출처 요청은 아닙니다.⚠️

2. 서버는 응답에서 다음 헤더들로 " 이 요청들은 공유해도 된다"고 알려줍니다.

Access-Control-Allow-Origin: https://example.com

위 헤더는 https://example.com에서는 응답이 공유 가능하다는 것을 나타냅니다. 만약 어느 사이트에서나 응답을 공유하도록 하고 싶다면, URL 대신 *을 사용합니다.

만약, 요청에 쿠키나 Authorization 등 credentials가 포함된 경우에는 * 사용이 제한되며,

Access-Control-Allow-Credentials: true

헤더가 필요합니다.

복잡한 CORS에서의 동작 과정

하지만 만약 CORS가 복잡한 경우에는 예외적으로 CORS-preflight Request(CORS 사전 요청)을 먼저 보내게 됩니다. 🫨🫨🫨 (이때, CORS-preflight Request는 브라우저에 의해 자동으로 수행됩니다.)

복잡한 CORS?

여기서 복잡한 경우란 다음과 같습니다.

• Content-Type이 브라우저의 안전 목록(safelist)에 없을 때
• 브라우저의 안전 목록에 없는 커스텀 헤더를 사용할 때
• GET/HEAD/POST 외의 메서드를 사용하여 요청을 보낼 때
• credentials 포함 여부 조건을 충족 할 때. 즉, 복잡한 CORS 요청이란 <form>으로 실행될 수 없는 요청이거나 브라우저가 보안상 위험하다고 판단하는 요청입니다.

CORS 사전 요청

CORS 사전 요청이란, CORS 프로토콜을 서버가 이해할 수 있는지 확인하는 역할을 하는 CORS 요청입니다. 이 요청은 OPTIONS 메서드를 사용하여 동일 엔드포인트(예: /api)로 보내집지며, 다음 헤더를 포함합니다.

• Access-Control-Request-Method: 동일한 자원에 대한 실제 CORS 요청이 어떤 HTTP 메서드를 사용할 수 있는지를 확인합니다.
• Access-Control-Request-Headers: 동일한 장원에 대한 실제 CORS 요청이 어떤 헤더를 사용할 수 있는 지를 확인합니다.

이 중 두번째 Access-Control-Request-Headers는 커스텀 헤더를 사용할 때에만 포함됩니다.

CORS 사전 요청에 대한 서버의 응답은 헤더를 포함할 수 있습니다.

• Access-Control-Allow-Methods: CORS 프로토콜을 위해 해당 URL이 지원하는 HTTP 메서드를 나타냅니다.
• Access-Control-Allow-Headers: CORS 프로토콜을 위해 해당 URL이 지원하는 헤더를 나타냅니다.
• Access-Control-Max-Age: 위 두가지 헤더의 정보를 캐시할 수 있는 시간을 나타냅니다. 단위는 초이며, 기본 값은 5입니다.

서버의 응답이 "허가"일 때, 브라우저가 Preflight에서 요청한 메서드/헤더가 있다면 이에 대응하는 응답헤더는 필수적으로 작성하여야합니다. 서버의 응답이 "불허"일 때는 모든 헤더를 보내지 않아도 됩니다.

또한, CORS 사전 요청에 대한 성공 응답은 200 또는 204와 같은 정상 상태 응답으로 제한됩니다. 상태 코드가 2xx가 아닌 응답은 성공적이지 않은 것으로 간주되며, 실제 요청으로 이어지지 않습니다.

이런 과정을 거쳐 CORS 사전 응답이 성공한다면, 브라우저가 실제 CORS 요청을 다시 보냅니다.

오늘은 팀플하다가 백엔드 API를 프론트엔드에 연결했더니 갑자기 CORS 에러가 뜨길래 이것 뭐예요?????? 하면서 CORS에 대해 정리해보았습니다.

글 적으면서 참고한 문서들은 아래에 적어둘게용.

Reference. https://docs.tosspayments.com/resources/glossary/cors#웹의-발달과-cors https://developer.mozilla.org/ko/docs/Web/HTTP/Guides/CORS https://developer.mozilla.org/ko/docs/Glossary/Origin https://fetch.spec.whatwg.org/#http-cors-protocol https://aws.amazon.com/ko/what-is/cross-origin-resource-sharing/