AWS Q 해커톤을 참여하며
개발자/엔지니어로 5년 차가 되었지만 해커톤 참여는 처음인데요....
긍정적인 경험은 자주 공유되지만 실패하고 넘어진 경험은 거의 공유되지 않습니다. 사실 성공 경험보다 더 도움이 되는 이야기는 실패한 경험입니다. 다른 사람의 실패를 깊이 들여다보면 그만큼 많은 것을 배울 수 있습니다.
<요즘 개발자> 고예슬, 임동준 저 | 한빛미디어
보통 이런 해커톤/대회 후기는 수상자들이 올리는 경우가 많습니다. 되돌아보자면 과거의 저도 그랬습니다.
하지만, 일반 참여자의 입장에서 작성한 후기/회고도 '왜 저렇게까지 하고도 수상하지 못했나', '어떻게 준비했나'를 되돌아보며, 저처럼 해커톤을 처음 참여해 보시는 다른 분들이 전략을 세우시는 데 유의미하지 않을까 생각해 보며, 회고글을 작성합니다.
아래부터는 글 작성 편의상 평어로 서술됩니다.
준비과정
어느 날 링크드인을 보다가 1등 상품이 무려 맥북 프로인 AWS 해커톤 공지글을 만났다. 맥북 프로에 흥분한 나는 바로 팀원들을 모았다. 회사에서 같은 개발팀으로 일하는 백엔드 엔지니어 1명, 프론트엔드 엔지니어 1명, 그리고 평소에 알고 지내던 풀스택 엔지니어 1명과 함께 팀을 결성했다.
해커톤 전날까지
사실 별거 안했다(...)
가장 시간과 공을 많이 들인 부분은 해커톤에서 개발할 서비스의 아이디어 선정/디벨롭이었다. 그러나 해커톤에 같은 팀이 되어 개발하더라도, 해커톤의 참여 목적에 따라 개발하고 싶은 서비스/아이디어가 다를 수 있고, 이 때문에 나중에 참여 의지가 약해지거나 "결국 ㅇㅇ한 아이디어로 했으면 좋았을 걸" 하는 갈등을 사전에 방지하기 위해, 팀원들의 해커톤의 참여 목적을 아이디어 선정 전에 싱크업했다.
목표에 따라 팀원명은 "프로 헌터스"로 정했다. (케이팝 데몬 헌터스에서 아이디어를 얻었다.)
수상이 목표였기 때문에, 해커톤의 출제(?) 목적을 생각하며, 수상에 좀 더 유리할 것 같은 아이디어를 전략적으로 정했다.
1일 차
1박 2일 동안 진행되는 해커톤이었는데, 1일 차에 별도의 장소제공이 없었기 때문에 2일 차 집결 장소인 AWS 오피스 근처에 숙소를 잡았다. 체크인 시간이 오후 2-3시 사이였는데, 1일 차 개발 일정은 아침 10시부터 시작되었기 때문에, 숙소 근처 카페로 오전 10시까지 집결했다. 그리고 다음날 오후 5시까지, 단 2시간 만을 자면서 29시간가량을 개발에 매진했다.
Amazon Q란?
- AWS 서비스와 개발에 특화된 챗지피티, 클로드 같은 서비스라고 생각하면 된다.
보통 이런 생성형 AI Agent는 rules, docs를 마크다운 형태의 문서로, 에이전트마다 정해진 디렉토리에 넣으면 에이전트가 알아서 해당 문서를 참고해 개발을 진행한다.
- rules : AI가 코드 생성 때 기본적으로 활용하는 AI를 위한 규칙 문서
- docs : 사람 작업자를 위한 공용 규칙 문서 용으로 디렉토리를 구분했다. (api 스펙, DB 스키마 등)
평소 회사에서도 AI를 적극적으로 사용하며 업무와 개발을 하는 편인데, 요번 해커톤같이 31시간 동안 시간을 집중해서, 여러 명의 팀원과 함께 한 레포지토리에서 개발을 진행하며 여러 번 배포하기 위해서 이 rules, docs를 전략적으로 공통 문서로 처음부터 잡고 넘어가야겠다 싶었다.
이 Rules, docs 작성을 해커톤에서 1일 차 개발을 시작하면서 가장 먼저 진행했다. Amazon Q를 적극적으로/창의적으로 활용하는 것이 심사 기준 중 가장 중요한 해커톤이니만큼, Amazon Q에게 우리의 목적과 상황, 맥락을 공유하여 문서를 생성했다.
- rules, docs 문서를 가장 먼저 직군별로 세팅
- 해당 문서는 main 브랜치에 위치해 서로 공용으로 사용했다.
해당 문서를 공용으로 만들고 세팅하는 데 많은 시간을 할애했다. 이 문서는 나중에도 업데이트할 수 있지만, 공용 문서기에 팀의 모든 개발자가 공통으로 사용하면서 일관된 개발 규칙/컨벤션으로 개발하기 위해서였다.
- 이 문서를 커밋하고 나니 첫날 오후 3시였다. 그만큼 초기 황금시간을 AI를 팀 차원에서 전략적으로 쓰기 위해 투자했다.
- 숙소에서 TV 화면으로 내 노트북 연결하고 팀원들이 같이 리뷰하면서 몹 프로그래밍 방식으로 진행했다.
하지만 해커톤이 끝난 이후 솔직히 회고하자면,
오직 AI(Amazon Q)만 문서를 열심히 읽고 맥락으로 활용했다.
나조차도 AI가 생성해 준 docs, rules 문서를 공들여 읽고 검토하지 않았다.
(rules는 평소에 사용하던 탬플릿을 사용해도 된다고 주최 측의 허락을 받아, 평소에 믿고 사용하던 rules를 재활용한 이유도 있었다.)
그래도 전략적으로 문서를 팀 차원에서 잘 사용해 보았다고 생각하는 사례를 말하자면,
초기 24시간 동안 개발해야 할 목록을 적은 plan 문서를 만들어,
- 팀원별 역할 명시
- 팀원별로 해야 할 작업 목록 체크리스트로 만들음
- git 파일에 포함시켜, 작업이 완료되면 AI에게 해당 항목 체크리스트 완료를 시켰다.
이때까지만 해도 AI가 6시간이면 된다는 작업 5분, 10분 만에 해주네? 우리 오늘 밤 안 새고 집 가서 자고 내일 아침에 다시 개발 시작해도 되겠네? 하는 장밋빛 미래를 꿈꿨다 😊
진행과정 / 개발하며
초기 개발과정에는 우리가 만들 서비스의 핵심 기능(MVP)을 정의/합의하고 핵심 기능부터 구현해 나갔다.
우리의 서비스 주제는 "운영 전담 인력이 없는 회사를 위한, 고객 CS 문의 시 (회사의 기존 응답/문서 히스토리를 바탕으로) 1차적으로 AI가 답변, AI의 답변에 고객이 불만족 시 바로 원클릭으로 사람 상담사 연결을 제공하는 AI기반 CS 문의 자동화 솔루션"이었다.
- 이를 위해 고객사에 붙일 챗봇 문의하기 기능(채널톡 같은 것) / 고객사가 사용하는 어드민 기능으로 크게 서비스를 2가지로 나누었다.
바이브코딩의 함정
해커톤에 같이 참여한, 우리 팀 백엔드 엔지니어분은 평소 백엔드 개발할 때 AI를 거의 쓰지 않는 편이다. AI보다 본인이 더 코드를 잘 짜기 때문이다. 평소 치밀하고 촘촘하게 계획 후, TDD 기반으로 개발하기 때문에 나중에 예상 치 못한 오류를 만날 일이 AI를 사용했을 때 더 높은 편이라, 주니어들이 기본 없이 AI를 사용하는 것에 회의적인 입장이셨는데,
이번 해커톤을 참여하면서는 100% 바이브코딩을 하셨다. (평소 대쪽 같은 흥선대원군의 면모를 보이던 팀원분이라 매우 흥미로웠다.)
이제 코드 작성의 패러다임이 사람이 작성하는 수제 코드 -> AI에게 프롬프트로 작성하여 AI가 짜주는 코드로 바뀌었다고 생각하는 나지만,
해커톤이라는 한정된 시간 안에 바이브코딩으로 하다 보니 AI 사용에 대쪽 같던 팀원분이
- main 브랜치로 체크아웃해줘
- 야 우리 엔드포인트 뭐 뭐 있냐
를 Amazon Q에게 물어보시는 상황을 지켜보며 되게 신선하고 재밌었다 ㅋㅋㅋㅋㅋ ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
하지만, AI에 전적으로 의존하는 바이브코딩을 하다 보니
- 문제를 해결하기 위해 A를 적용했다가, A가 아니라 B를 써야 한다고 A를 지웠다가, 다시 A로 복구하거나, 다시 B로 복구하는 상황이 지난하게 반복되어서 피로한 순간들이 있었다.
- 위 과정에서 서비스가 터지고 배포가 안 되는 순간들이 반복되어서 더 피로함을 느꼈다.
- docs, rules를 훌륭하게(?) 작성했음에도 문제가 반복되자 AI는 일단 빌드되어야 한다고 테스트코드를 지워버리질 않나(...) 커밋 히스토리나 docs, rules를 정말 맥락에 불러오는 건가? 싶을 때도 많았다.
(프롬프트에 docs, rules 참조해서 하라고 명시하면 그때는 또 잘 읽어왔다. 😇)
그건 그냥 너희가 AI 잘 활용 못한 게 아닌가? 하실 수도 있으니 조금 더 말해보자면,
우리는 전체 36팀 중 Amazon Q를 가장 많이 쓴 상위 3위 팀이었다.
- 물론 많이 호출한다고 잘 쓰는 건 아니지만, 그래도 이만하면 규칙 잘 먹여서 다양한 사례로 Amazon Q를 잘 썼음에도(활용 사례는 이 글을 계속 읽어보시면 더 나옵니다) 아 이건 아닌데(....) 하고 느끼는 점들이 있었다.
(그럼에도) Amazon Q 사용 팁
나는 평소에도 AI를 잘 활용한다고 팀 내에서도 (활용 사례를 자주 말하기 때문에) 인정(?) 받는 편인데, 이번 해커톤에서 AI Agent를 더 잘 활용하는 방법을 알게 되고, 더 잘 활용하는 방법/사례를 만나 나는 그동안 우물 안 개구리였구나 하고 느꼈다.
흥미로운 점은,
- Amazon Q의 경우 IDE 플러그인보다 cli가 더 빠르다고 초반에 느꼈는데 (AWS 직원 분 피셜) 진짜였다. (실제로 써보면 응답 속도가 확연히 다르다.) (플러그인과 cli의 아키텍처가 다르다고 들었다. - 이건 아직 제대로 찾아본 것은 아니라, 추가 확인이 필요하다.)
- Amazon Q IDE 플러그인의 경우 AI의 제안에 따라 파일 diff를 보기 좋게 보여줘서 사용하기엔 더 편했지만, 사용하면서 아 왜 이렇게 느려!!!!!!!!!!!!! (해커톤 중 시간 제한됨 이슈) 하면서 팀원들이 입을 모아 답답해하는 부분이 있었다.
- 반면 Amazon Q cli의 응답 속도는 IDE 플러그인에 비하면 선녀이다... 또한 터미널에 탭을 여러 개 띄워놓고 trust 모드로 cli를 쓰면, 각 작업당 plan.md를 먹이고 병렬 작업을 빠르게 할 수 있기 때문에 신세계였다. (AWS 히어로 현민님이 알려주심)
이 경험 이후로, 앞으로도 claude code, codex 등 다른 AI Agent를 사용할 때 IDE 플러그인과 cli의 아키텍처나 사용자 리뷰/평점을 보고, IDE 플러그인보다 cli가 더 사용성이 우수한 툴들은 cli 모드를 적극 활용할 예정이다.
타 팀의 발표를 보면 draw.io MCP를 써서 아키텍처 파일을 그린 후 굳이 사람이 손을 댈 필요가 없었다고 했는데, 우리 팀도 인프라 아키텍처를 그릴 때 Amazon Q를 활용했다. (대신 draw.io 에서 사용할 수 있는 형식으로 그려달라고 하고, IDE에서 draw.io 플러그인으로 AWS 서비스 아이콘? 배치는 쫌 손을 댔다.)
발표자료도 Amazon Q로 만들었다.
- 발표 내용에 중요하게 들어가야 하는 핵심적인 내용 / 해커톤 심사 기준 / 장표당 들어가야 하는 내용을 간단히 프롬프트로 입력 후
- 프레젠테이션의 전반적인 구조를 제안해 달라고 하고, 검토 후
- 2p 단위로 끊어서 Amazon Q에게 markdown 문서를 생성해 달라고 하고, 파일을 커밋했다.
팀원과의 갈등
적을까 말까 고민했으나, 회고 차원에서 공유해 본다.
이미 평소에 회사 팀에서 오랜 시간 합을 맞춰본 회사 팀원분들과는 해커톤 때에도 문제가 없었으나, 평소 일을 같이 해보지 않은 팀원분과 일하는 스타일이나 개발 방법이 맞지 않아 (나 혼자서 느끼기로는) 갈등이 있었다고 느끼는 순간들이 몇 차례 있었다.
- 초반에 서버리스로 개발 환경을 세팅하기로 하여 개발/배포 환경을 구성했는데,
- 실제로 어드민 기능을 개발/테스트할 때 서버리스로 API 호출/테스트하면서 생산성이 크게 떨어지는 이슈가 있었다.
- 서버리스 대신 Amplify로 배포하는 게 어떠냐고 팀원분이 제안했지만,
- (솔직히) 기존에 써보지 않은 배포 방식이라 회의적이었다.
하지만 우리는 목표를 달성하기 위해 모인 사람들이고, 정해진 시간 내에 끝마쳐야 하는 과업이 있는 사람들이었다. (솔직히) 나의 감정이 태도에 드러날 때도 있었지만 (이 글을 보실 그 팀원분께 : 죄송합니다) 평소 인프라를 해오며 개발자의 생산성/편의성이 누구보다 중요한 기준이라고 생각하던 나였다. 결국 Amplify로 어드민은 배포 환경을 구성하기로 했고, 결과적으로 그분의 선택이 맞았다.
이 결정은 어드민의 개발 생산성과 결과물에 정말 중요한 역할을 했다.
대고객 서비스의 배포 파이프라인은 AWS CDK + CloudFormation + 쉘스크립트로 개발자가 cli 명령어 하나만 입력하면 배포가 되게 구성했지만, 배포 과정에서 문제가 생기면 관련 에러/로그를 보여주지 않고(쉘스크립트를 잘 짰으면 해결될 문제였을 듯) 개발자가 하염없이 기다려도 배포가 안 되어서 답답할 때가 여러 번 있었다. 그래서 어드민의 경우 푸시만 하면 배포되가 되는 Amplify가 직관적이라고 느꼈다.
그래도 회고하면서 잘했다고 생각하는 점은, 내가 먼저 (시간을 가진 후) (환기 후) 감정을 추스르려고 노력하며 상대의 해결책을 받아들였다는 것이다. 내가 예민한 것 같은 순간에도, 이어서 그 점(제가 예민했던 것 같네요)을 상대에게 언급했다. 그리고 상대가 인프라 관련해서 어려움을 겪을 때 물심양면으로 도왔다.
결과적으로 누구 하나 이탈 없이 해커톤을 마무리했다.
수상을 지켜보며
사실, 열심히 했기 때문에, 그리고 결의가 옹골찼기 때문에 수상에 대한 기대가 있었다. 하지만 결과적으로는 다른 팀의 수상을 지켜보면서 깨달음과 배움을 여실히 느끼며, 내가 우물 안 개구리였구나 반성을 실시간으로 했다.
Amazon Q를 잘 쓴 팀은 AI를 기똥차게 활용했다. 예를 들어 AUSG 멤버들로 구성된 팀은 주니어들로 구성되었지만, AI Agent에게 "너는 10년 차 개발자인데, ㅇㅇ를 잘하고 ㅁㅁ에 전문성이 있어" 하는 Agent 문서를 상세히 6개 정도로 구성하여 총 11명의 팀원이 있는 효과를 발휘했다. (요새 AI Agent에는 이런 롤플레잉이 더 이상 유의미하지 않다고 어느 발표 자료에서 읽었는데, 아니었나 보다. 해당 팀의 결과물을 보니 역할을 부여받은 AI Agent는 그들의 역할을 충실하게 수행했다.)
#aws #megazonecloud #amazonq #hackathon #nova #ai | Eunji Lee
🏆[Amazon Q Hackathon 2025] 9월 5일 - 6일, 아마존 큐 해커톤에서 감사하게도 대상을 수상하였습니다!🎉 AUSG 친구들과 처음으로 함께 참가한 해커톤이었는데, 다 함께 어떤 기술들을 서비스에 어떻게
kr.linkedin.com
주제 선정도 창의적이라고 느꼈고, 영어 교육 서비스를 만들며 학습에 효과적인 실시간 피드백을 이미지와 음성, 채팅으로 주는 등 결과물이 놀라웠다.
챗봇은 해커톤에서 뻔한 서비스일까?
하지만 회고해 보면, 수상한 팀도 챗봇 형태가 많았다. 다만 스토리텔링 방식과 UX 방식에서 뻔한 챗봇이 아니라고 느끼게 만들었다는 점에서 감탄했다.
어떤 AWS 기술/서비스를 사용하는지도 차별점이 될 수 있다.
AWS Bedrock(Claude Sonnet 등의 AI Agent를 API로 호출해서 개발 시 활용할 수 있는 관리형 서비스)을 사용하는 팀이 많았다. 대상을 수상한 서비스는 AWS Nova (솔직히 처음 들어봤다)를 사용했는데, 대중적으로 익숙하지 않은(?) 서비스(EC2, ECS, Cloudfront 같은 서비스에 비해 비교적 잘 알려진 것 같지 않다는 의미이다)를 서비스에 맞게 잘 활용했다는 점에서 감탄했다.
발표 자료의 디자인은 정말 중요하다.
AWS 멘토님이 말하실 땐 네네😊 하고 넘겼는데... 진짜다.
스토리텔링으로 공감을 이끌어내는 게 중요하다.
수상 팀의 발표 과정에서, 이 제품이 왜 필요하다고 느꼈는지, 객관적인 자료 제시를 통해 이게 왜 시장에서 필요한 제품인지를 들으며 나도 고개를 끄덕거리면서 그들의 제품이 필요한 이유를 공감했다.
이 점에서 다시금 나는 우물 안 개구리였다고 느낀 게,
우리 팀이 해커톤에서 만든 서비스도 당장 팀원들이 우리 회사의 상황으로 인해 필요하다고 생각해 만들었기 때문에, 충분히 심사 과정에서 어필할 수 있다고 생각했지만 우리(나)만의 착각이었구나 느꼈다.
더 전략적으로 어필해야 했다. (이게 왜 필요한지 - 시장의 수요, 니즈 등을 객관적으로 제시해야 했다.)
잘한 점 회고
AI에 의존하다 보니 사람 메모리가 날아가는 순간을 자주 느껴서, 그걸 보완할 체계/시스템을 고민하고 실행했다.
- 해커톤 중 추가로 필요하다고 느낀 아이디어/의견 나온 거는 말로 그치지 않고 무조건 소통 채널(슬랙, 디스코드)에 기재했다.
- 추후 팔로업 했으면 실행했다고 체크했다.
개발/배포가 마음대로 되지 않아서 매몰되었다고 느낀 순간들이 있었는데, 중간중간 회고/방향성 체크를 제안하고 팀원들끼리 머리를 맞대고 아이디어를 나누었다.
처음 협업을 같이 해봐서, 아직 일하는 방법을 (내가) 잘 모르는 팀원에게 진행상황을 주기적으로 물어보고 도울 수 있는 상황이 있다면 일을 분담해서 도왔다.
아쉬웠던 점 회고
첫날 오후 6시까지는 모든 게 좋아 보였다. (AI가 6시간 걸릴 거라던 작업 5분 만에 되네 ㅎㅎ 오왕 밤샐 필요 없겠다)
그러고 사이트가 터지고 배포가 안되고 미궁 속에 빠지는 잃어버린 12시간이 찾아왔다.
열심히 밤을 새웠으나 시간을 들인 만큼 진척된 게 없다고 느꼈다.
왜 그랬을까? 사후 부검해 보자면,
- AI에 전적으로 의존했기 때문에 했던 걸 계속 엎어치고 엎어치고 하는 과정에서 시간이 불필요하게 낭비되었다.
- 배포가 안되거나 사이트가 터지는 상황이 반복적으로 발생해서 디버깅하느라 시간을 많이 썼는데,
- 그 뭐가 되고 안되고에 대한 분석/디버깅도 AI에게 전적으로 의존했다.
(나중에는 정신 차리고 AWS 콘솔 들어가서 로그 보면서 사람이 디버깅했다.)
그런데 2일 차에 다른 팀이 개발하는 방식을 보니 파일을 다 읽고 코딩하는 것 같다며 팀원분이 신기한 듯 말했는데, 정말 그게 차이점이었는지는 다른 팀의 개발 과정을 내가 실시간으로 지켜본 것이 아니라서 사실 잘 모르겠다.
TDD를 진행한다고 했지만, 배포 전에 핵심 기능이 제대로 동작하는지에 대한 테스트 자동화를 시간을 내어 먼저 셋업 했더라면 불필요하게 시간이 낭비되는 일을 최소화할 수 있었을 것 같다.
다음에 해커톤에 또 참여한다면
- AWS 대회라면 Kiro IDE를 써볼 것이다.
- 해커톤에서 권장하는 핵심 툴 (이 경우엔 Amazon Q)를 더 잘 활용하는 방법을 샅샅이 찾아보고 준비할 것이다.
- 심사 기준 / 규칙을 꼭 다 만족하했는지를 주기적으로 체크하는 방법을 체계를 만들어서 - 체크리스트를 만들어서 주기적으로 체크해야겠다.
- Amazon Q 활용 방법을 어필하는 것이 심사 과정에서 핵심적이었는데, 데모/심사위원 평가에서 그걸 충분히 잘 어필하지 못했다는 생각이 든다.
이번 해커톤에서 느끼고 배운 것
- AWS Bedrock에서 사용하는 AI 모델 중 어떤 것이 서비스에 최선인지 A/B 테스트 & 성능 체크를 하며 어떤 모델을 사용할지 근거로 삼을 수 있다는 것을 (다른 팀을 보며) 배웠다. 사실 업무를 하면서는 당연히 할 항목인데 해커톤에서도 그걸 하는 팀이 있다니 감탄했다.
- 무조건 최신/고사양 AI 모델이 더 좋은 게 아니구나를 느꼈다. (예 : Claude Opus 4.1) 오히려 Sonnet 4.0 이 응답 속도 면에서 프롬프트 최적화를 잘한다면 더 나을 수도 있다는 것을 (다른 팀을 보며) 배웠다.
- 토요일이었는데, 정말 많은 AWS 직원분들이 준비/심사위원으로 출근하시는 걸 보고 정말 AWS는 열정적인 회사구나 느꼈다. 특히 높으신 SA분들(!)까지 나와서 주말에 해커톤을 위해 시간을 사용하다니.... 정말 신기하고 놀라웠다.
이 글은 AI의 도움 없이 전적으로 사람의 손에 의해 쓰였습니다. 그게 더 진심을 잘 전달할 수 있고, 기억에 남는 방법이라고 믿습니다.
긴 글 읽어주셔서 감사합니다.
혹시나 궁금한 분들을 위해 저희 팀이 개발한 서비스의 링크를 남깁니다. 😃
https://github.com/PRO-HUNTER-X/team03-aws-hackathon
GitHub - PRO-HUNTER-X/team03-aws-hackathon
Contribute to PRO-HUNTER-X/team03-aws-hackathon development by creating an account on GitHub.
github.com