1. Q 해커톤에 참가하게 되다.
'프로덕트 엔지니어'와 'AI-Native'라는 화두에 미쳐있다.
기술의 완성도를 넘어 제품의 성공에 집착하고, 그 과정을 AI와 함께 폭발적인 속도로 해내는 것.
미래의 개발 모습은 현재와 많이 달라질 것이다.
(이 생각의 배경과 철학에 대한 더 자세한 이야기는 아래 글로 따로 정리해두었어요.)
결국, 세상은 만드는 사람들의 것
1. 게임의 룰이 달라진다요즘 머릿속에 바이러스처럼 퍼져나가는 두 단어가 있다. 바로 '프로덕트 엔지니어(Product Engineer)'와 'AI-Native' 이다. 이 단어들은 단순히 새로운 기술 트렌드를 넘어, 개발
upcurvewave.tistory.com
믿음은 증명되어야 하고, 이론은 실전에서 검증받아야 한다.
그러던 중, 시험대가 될 기회가 찾아왔다. 바로 'AWS Q 해커톤'이었다.
어느 날 아침, 팀 채널에 한 팀원 분이 링크 하나를 툭 던졌다. 링크의 정체는 'AWS Q 해커톤'. "이거 저희랑 핏이 너무 맞는거같은데"라는 한마디에, 채널은 순식간에 달아올랐다.
"금요일 연차 필수", "이거 진짜 밤샘 각인데?" 같은 현실적인 우려가 잠시 오갔지만, "님들 하면 저도 함ㅋㅋ"이라는 대답들이 이어지며 분위기는 금세 하나로 모였다. 심지어 해커톤 홈페이지의 만듦새를 보며 "이거 프롬프트 한 방에 대충 만든 거 아니냐"며 농담을 주고받을 만큼, 우리는 이미 이 게임에 깊이 몰입하고 있었다.
결정은 순식간에 내려졌고, 대화는 곧바로 '어디서 모여서 밤을 샐 것인가'에 대한 구체적인 계획으로 넘어갔다.
주제는 'AI를 활용한 혁신적 개발'. 주말마다 모여 진행하던 asyncsite의 모든 정규 일정에 대해 '스탑 더 월드'를 시전하고, 즉흥적인 도전을 해보기로 했다.
2. 계획 : 먼저 우리가 한 일
해커톤까지 남은 시간은 약 일주일. 직장인들이어서 퇴근 후 저녁 시간에 온라인으로 모여 계획을 세우기 시작했다.
우리는 이렇게 아이디에이션을 했다.
먼저 각자 AI에게 해커톤 주제에 대한 질문을 던지며 아이디어를 수집해 문서로 정리했다. 그다음 단계가 핵심이었는데, 각자가 만든 아이디어 노트를 다시 AI에게 교차 검증시키며 생각의 빈틈을 메우는 방식이었다. 사람이 아이디어를 내면, AI가 비평가가 되어 아이디어를 단단하게 만드는 사이클을 거치고자 했다.
문서는 깃허브의 private 레포지토리로 관리했다. Claude Code나 Cursor 같은 CLI 기반 AI 에이전트가 폴더 구조 전체를 이해하고 파일을 능숙하게 다룬다는 점을 활용하기로 했다.
우리의 첫 번째 일은 비어있는 GitHub private 레포지토리를 만드는 것이었다. 이번 해커톤의 모든 과정을 '문서 주도 개발(Document-Driven Development, DDD)' 방식으로 진행하기로 합의했다. 모든 논의와 아이디어를 사람이 아닌, AI 에이전트가 가장 잘 이해할 수 있는 형태로 기록하고 관리하는 것이 핵심이었다.
각자 개인 브랜치에서 AI와 브레인스토밍하며 아이디어 문서를 만든 뒤, 터미널에서 CLI 에이전트에게 다음과 같이 명령을 내리는 식이었다.
"이 레포지토리에 있는 모든 아이디에이션 문서를 분석하고, 핵심 아이디어 3개로 요약해줘. 그리고 각 아이디어의 장단점을 비교하는 표를 새로운 마크다운 파일로 만들어줘."
이 방식 덕분에, 우리는 흩어져 있는 각자의 생각을 하나로 모으는 데 드는 시간을 획기적으로 줄일 수 있었다. AI가 객관적인 분석 리포트를 만들어주면, 우리는 그를 바탕으로 가장 본질적인 토론에만 집중하면 되었으니까.
수많은 아이디어들이 오갔고, 함께 모여 갑론을박을 거치며 최종적으로 'AI Chef Assistant'를 만들기로 결정했다. 기획 아이디어를 정한 뒤에는 실제적인 구상 단계로 들어갔다. 서버리스 아키텍처로 구상한 백엔드와는 별개로, 프론트엔드는 미리 간단한 프로토타입까지 만들어보며 사용자 경험의 그림을 구체화했다.
그리고 당일 계획은 심플했다. 미리 구상해 둔 설계를 바탕으로 20시간 안에 빠르게 개발을 끝내고, 남은 10시간 가량은 여유롭게 발표 자료를 만들어서 'Super Empowered AI Driven 개발을 소개해야지', 'AI 기반의 DDD (Document driven developemt)를 멋드러지게 소개해야지' 였다.
계획은 야심찼고, 모든 것이 순조롭게 흘러갈 것이라 믿었는데...
3. Amazon Q, 낯선데?
어색한 첫인사: 기대와 달랐던 Amazon Q와의 협업
나름 자신감에 차 있었다. AI-Native를 외치던 우리에게 AI와 함께하는 개발은 꽤나 익숙한 일상이었기 때문이다. 평소 사용하던 Claude나 Cursor+GPT5처럼, 이번 해커톤의 지정된 동료인 Amazon Q 역시 우리의 비전을 즉시 이해하고 멋진 코드를 척척 내어줄 것이라 기대했다. 이미 머릿속에는 꽤나 그럴듯한 프로토타입까지 그려둔 상태였기도 하고.
그런데 생각보다, Amazon Q와의 첫인사는 기대와 사뭇 달랐다.
평소 내가 사용하던 AI가 자유로운 아이디어를 빠르게 프로토타이핑하는 '크리에이티브 파트너'에 가까웠다면, Amazon Q는 AWS 생태계에 깊이 뿌리내린 '시스템 전문가'처럼 느껴졌다. 나는 멋진 스케치를 그려달라고 요청했지만, Q는 스케치보다는 완벽한 건물의 청사진을 그리는 데 더 특화된 도구였던 셈이다.
문제는 그 다름을 인정하지 않고, 우리가 정해놓은 익숙한 바운더리 안에 Q를 가두려 했다는 점이다. 나는 Q의 전문 분야인 AWS 아키텍처나 인프라 구성에 대한 심도 있는 질문을 던지기보다, 기존 방식대로 프론트엔드 UI를 한번에 그려달라는 식의 요구를 반복했다. 탁 트인 고속도로를 달릴 수 있는 F1 머신을 좁은 골목길로 억지로 밀어 넣으려 한 꼴이었다. 결국 Q와의 협업은 삐걱거렸고, 개발 속도는 좀처럼 붙지 않았다.
돌이켜 보면 클로드 코드에 너무 익숙해졌던 것 같다.
바로 그 경험에 너무 깊이 몰입한 나머지, 새로운 도구를 편견 없이 바라보지 못했다. 마치 평생을 한 종류의 명검만 다뤄온 장인이, 처음 보는 도끼를 쥐고 칼처럼 섬세하게 다루려 애쓰는 것과 같았다. Q의 특징과 강점을 파악하고 그에 맞는 새로운 사용법을 모색해야 했다. 하지만 Q를 있는 그대로 받아들이는 대신, 머릿속의 '클로드처럼 작동해야 한다'는 낡은 틀에 억지로 끼워 맞추려고만 했다.
그러니 녀석이 낯설고, 답답하게 느껴지는 것은 어쩌면 당연한 귀결이었다.
머릿속에 그려둔 높은 퀄리티의 프로토타입과 눈앞의 더딘 결과물 사이의 간극이 점점 초조하게 만들었던 것 같았다. 그리고 그 초조함은 결국 최악의 선택으로 이어졌다.
첫 번째 실수: 마이크로매니징의 시작
내 뜻대로 움직여주지 않는 동료를 길들이는 방법은 무엇일까. 나는 가장 익숙하고도 최악인 방법을 택했다. 바로 '마이크로매니징'이다.
"이 컴포넌트의 최상위에는 div를 하나 만들어 줘."
"그 안에 h1 태그를 넣고, 텍스트는 'AI Chef'로 해줘."
"자, 이제 그 밑에 p 태그를 추가하고, 글자 색은 #6B7280으로 지정해 줘."
Q를 더 이상 동료로 대하지 않은 것이다. 내 머릿속에 있는 프로토타입의 UI를 한 픽셀의 오차도 없이 그대로 복제해 내는 아바타, 내 손가락을 대신하는 키보드로 취급하기 시작했다. 전체적인 기능을 맡기는 대신, 변수명 하나, CSS 속성 하나까지 지시하며 녀석의 자율성을 완전히 빼앗았다. 스스로 생각할 기회를 주지 않고, 오직 나의 명령만을 수행하는 수동적인 도구로 격하시킨 것이다.
돌이켜보면 그렇게 답정너를 시전한 것, 이것이 가장 큰 첫 번째 실수였다.
해커톤의 본질은 '완벽함'이 아니라 '완성'이다. 정해진 시간 안에 아이디어를 실제 작동하는 무언가로 만들어내는 것이 핵심이다.
이걸 몰랐다. 엄밀한 의미에서, 아는데 몰랐다.
사소한 디자인 디테일이나 코드의 우아함은 그 다음 문제였다. 하지만 그 본질을 망각한 채, 내 머릿속의 '정답'을 구현하는 데에만 집착했다.
생각해보면 Q에게 더 넓은 재량권을 주고, 전체적인 기능의 완성을 맡겼어야 했다. 큰 그림만 그려주고 세부적인 구현은 전적으로 신뢰했어야 했다. 하지만 그러지 못했던 것이다. AI라는 새로운 패러다임의 도구를 손에 쥐고도, 나는 여전히 구시대의 작업 방식, 즉 모든 것을 내 통제하에 두려는 낡은 관성을 버리지 못했던 것이다.
어쩌면 이것이 진짜 '경험'에서 오는 역량의 차이가 아닐까 싶다. 얼마나 많은 기술을 아느냐가 아니라, 결정적인 순간에 무엇을 버리고 무엇에 집중해야 하는지를 아는지는 어쩌면 뼈저린 경험으로부터 체화된 지혜일 듯 싶다. 이번 31시간의 해커톤을 통해 그 값비싼 지혜를 이제 막 배우기 시작한 것 같다.
4. 완성된 프로덕트, 31시간 안에 만들기 : AI Chef Assistant
그렇게 삐걱거리는 협업과 서툰 지휘 속에서도, 시간은 흘렀고 코드는 쌓였다. 우리의 분투는 조금씩 형태를 갖추기 시작했다. 무질서해 보이는 벽돌들이 모여 마침내 하나의 집이 되어가는 과정이었다.
우리가 만든 프로덕트의 이름은 'AI Chef Assistant'이다.
프로덕트의 문제 정의와 비전
단순히 레시피를 검색해 주는 앱은 아니다. 완전히 다른 차원의 문제를 풀고 싶었다.
풀고 싶었던 문제
기존의 레시피 앱들은 거대한 '공공 도서관'과 같았다. 정보는 많지만, 나에게 딱 맞는 책을 찾으려면 스스로 전문가가 되어야 했다. 이 지점에서 두 가지 명확한 한계를 보았다.
- 개인화의 부재: 사용자가 케톤 다이어트 중인지, 특정 음식에 알레르기가 있는지, 오늘 저녁 요리에 쓸 수 있는 시간이 30분뿐인지, 기존 앱들은 전혀 관심이 없다. 그저 '닭가슴살'을 검색하면 수백 개의 닭가슴살 요리를 뱉어낼 뿐이다.
- 일방적인 정보 제공: 앱은 사용자가 검색어를 입력하기만을 기다린다. 사용자의 숨겨진 니즈나 맥락을 먼저 묻거나 이해하려는 노력 없이, 단편적인 키워드에 대한 결과값만 돌려주는 수동적인 정보 창고에 머물러 있었다.
'AI Chef'의 비전: 당신만을 위한 영양사 겸 셰프
'AI Chef Assistant'는 이러한 문제를 해결하기 위해 탄생했다. 우리 비전은 모든 사용자가 자신만의 개인 영양사이자 전담 셰프를 갖게 하는 것이었다.
- 검색에서 '대화'로: 저희는 사용자가 키워드를 입력하는 대신, AI와 대화하며 자신의 상황을 설명하는 방식을 택했다. AI가 먼저 사용자의 목표와 제약사항을 이해하고, 그에 맞는 최적의 솔루션을 제안하는 '능동적인 어시스턴트'를 구현하고자 했다.
- 초개인화된 솔루션: 이 대화를 통해 'AI Chef'는 다음과 같은 지극히 개인적인 질문에 구체적인 답을 줄 수 있다.
- "오늘 저녁, 나의 케톤 다이어트 14일 차를 위한 닭가슴살 요리"
- "혈당 관리가 필요한 아버지를 위한 일주일치 식단"
- "남은 예산 2만 원으로 만들 수 있는 2인분 건강식"
핵심 기능과 사용자 경험
이러한 비전을 현실로 만들기 위해, 사용자 경험의 핵심이 될 두 가지 기능에 집중했다. 하나는 사용자의 복잡한 맥락을 '어떻게' 이해할 것인가에 대한 답이었고, 다른 하나는 그에 대한 결과물을 '얼마나' 실용적으로 제공할 것인가에 대한 고민이었다.
Feature 1: '대화형 인터페이스'로 맥락 수집
사용자가 수많은 필터를 직접 설정하는 복잡한 UI 대신, 셰프와 대화하듯 편안하게 자신의 요구사항을 전달하는 '챗봇 형태의 인터페이스'를 선택했다. 이를 통해 사용자는 자연스럽게 자신의 깊은 맥락을 AI에게 알려줄 수 있다.
- 단계별 질문 플로우: AI는 영리하게 질문의 순서를 조절한다. "어떤 건강 목표를 가지고 계신가요?"라는 큰 질문으로 시작해, 사용자의 답변에 따라 "혹시 특정 알레르기가 있으신가요?", "오늘 요리에 사용할 수 있는 예산은 얼마인가요?" 와 같이 꼬리를 무는 질문을 던져 필요한 정보를 수집한다.
- 직관적인 선택지 제공: 사용자의 피로도를 줄이기 위해, 주관식 답변 외에도 "15분 이내", "30~60분" 등 직관적인 버튼 선택지를 제공하여 빠르고 막힘없는 경험을 설계했다.
Feature 2: '실용성'을 더하는 최종 결과물
아무리 좋은 레시피라도 실생활에서 활용할 수 없다면 의미가 없다고 생각했다. 그래서 최종 결과물에는 '실용성'을 더하기 위한 장치들을 포함시켰다.
- 상세 레시피와 맞춤 영양 정보: 기본적인 조리법과 함께, 사용자가 설정한 목표(예: 케톤식)에 맞춘 칼로리, 탄수화물, 단백질, 지방 등의 상세 영양 성분 분석표를 제공하여 식단 관리의 효율을 높였다.
- 실시간 식재료 가격 분석: 저희 프로덕트의 핵심 기능이다. 네이버 쇼핑 API를 실시간으로 연동하여, AI가 제안한 레시피에 필요한 모든 식재료의 현재 최저가와 예상 총비용을 계산해 보여준다. 이를 통해 사용자는 예산에 맞춰 메뉴를 최종 결정할 수 있다.
기술 아키텍처
이처럼 역동적이고 개인화된 경험을 단 31시간이라는 제한된 시간 안에 구현할 수 있었던 비결은, AWS 위에 구축한 똑똑하고 효율적인 '서버리스 아키텍처' 덕분이었다. 복잡한 어플리케이션을 구동시키는데 시간을 낭비하는 대신, 오직 비즈니스 로직과 사용자 경험에만 집중할 수 있었다.
'AI Chef'를 움직이는 핵심 엔진들
1개의 StepFunction과 10개의 람다로 구성되어 있다. 그리고 Bedrock, DynamoDb, OpenSearch 등의 Aws 고유 서비스들을 이용했다.
- 두뇌 (The Brain) -
AWS Bedrock (Claude 3 Sonnet):
애플리케이션의 핵심 두뇌 역할은 AI 모델이 담당했다. AWS Bedrock을 통해 강력한 LLM인 Claude 3 Sonnet 모델을 활용했다. 이 모델은 사용자와의 대화에서 수집된 복잡한 맥락(건강 목표, 예산, 알레르기 등)을 종합적으로 이해하고, 창의적이면서도 논리적인 맞춤형 레시피를 생성하는 역할을 수행했다. OpenSearch 를 붙여 13만 건의 영양소 데이터에 특화된 RAG를 사용했다. - 지휘자 (The Conductor) -
AWS Step Functions:
모든 작업의 흐름을 지휘하는 오케스트라의 지휘자는 Step Functions였다. 사용자의 레시피 생성 요청이 들어오는 순간, Step Functions는 복잡한 워크플로우를 시작한다. 각기 다른 역할을 수행하는 여러 Lambda 함수들을 동시에, 혹은 순서에 맞게 호출하며 전체 프로세스가 물 흐르듯 진행되도록 조율했다. - 전문가 (The Specialists) -
AWS Lambda:
지휘자의 신호에 따라 각자의 전문 분야를 처리하는 실행 유닛은 총 7개의 Lambda 함수들이었다. 특히 Step Functions를 통해 세 가지 핵심 작업을 병렬로 동시에 처리하여 응답 시간을 획기적으로 단축했다.- 레시피 생성 Lambda: Bedrock API를 호출해 레시피 텍스트를 생성
- 가격 분석 Lambda: 네이버 쇼핑 API를 호출해 실시간 가격 정보를 수집
- 영양 분석 Lambda: 생성된 레시피의 영양 정보를 계산
- 이 세 가지 작업이 동시에 실행된 후, 마지막 Lambda 함수가 그 결과들을 하나로 취합하여 사용자에게 최종 결과물을 전달하는 구조이다.
- 기록 및 소통 - DynamoDB & API Gateway:
사용자와의 대화 내용, 세션 정보, 최종 결과 등 모든 데이터는 NoSQL 데이터베이스인 DynamoDB에 기록했다. 사용자의 웹 브라우저와 이 모든 백엔드 시스템 간의 소통 창구는 API Gateway가 담당했다.
겉보기엔 그럴듯했다. 어쨌든 우리는 아이디어를 실제 작동하는 MVP로 만들어내고 있었다. 하지만 나의 잘못된 고집과 비효율적인 협업 방식이 쌓아 올린 기술 부채는, 마감 시간이란 압박 앞에서 위태로운 소리를 내기 시작하고 있었다.
5. 절망과 깨달음의 마지막 4시간
가장 후회되는 순간: 사소한 버그 하나가 불러온 최악의 선택
마감까지 남은 시간, 4시간 30분.
전쟁 같던 이틀이 지나고, 우리 앞에는 그럭저럭 작동하는 'AI Chef'가 있었다. 이제 남은 것은 약간의 다듬기 작업과 발표 준비뿐이라고, 모두가 안도하고 있었다. 바로 그 평온의 순간, 문제가 터졌다.
문제는 정말 사소했다. 결과 화면의 여러 탭 중 '영양소' 탭 하나가 간헐적으로 제대로 표시되지 않는 버그였다. 최악의 경우, 발표 때는 이 탭을 클릭하지 않으면 그만일 정도의 작은 흠집. 하지만 며칠 밤을 새운 개발자의 눈에는 그 작은 흠집이 거대한 균열처럼 보였다. 완벽한 마무리를 하고 싶다는 욕심이 이성을 마비시키기 시작했다.
모두가 그 버그 하나에 끙끙대며 매달리던 그때, 내가 입을 열었다.
"이참에 배포 방식을 좀 더 깔끔하게 통일하죠. 지금 수동으로 올린 것들이 꼬인 걸 수도 있으니, AWS에 올라간 람다랑 API 게이트웨이를 다 내리고, 잘 되는 거 하나를 표본으로 해서 다시 올립시다."
지금 돌이켜보면 제정신이 아니었다. 그것은 합리적인 제안처럼 들렸지만, 실상은 늪으로 스스로 걸어 들어가는 최악의 선택이었다. 마라톤 완주를 코앞에 두고 갑자기 신발 끈을 고쳐 매겠다며 주저앉은 꼴이었다.
우리는 사소한 버그를 잡기 위해, 이미 잘 작동하고 있던 서버의 심장을 스스로 멈춰 세우기로 결정했다. 이것이 이번 해커톤에서 내가 내린 가장 후회되는 결정이었다.
깊어지는 수렁: 잘못된 신념이 허비한 2시간의 기록
우리가 옳다고 믿었던 그 계획은, 사실 베스트 프랙티스와는 거리가 멀었다. 하나의 yml 설정 파일을 만들어두고 나머지 서비스는 그것을 그대로 복사해서 이름만 바꿔 배포하자는 전략. 그것은 유지보수가 재앙에 가까운 최악의 '안티패턴'이었다. 하지만 당시의 우리는 그게 가장 합리적이고 깨끗한 방법이라는 잘못된 신념에 사로잡혀 있었다.
시계는 무정하게 흘러갔고, 우리는 스스로 파놓은 수렁에서 허우적대기 시작했다.
복사해서 붙여넣은 설정 파일들은 예상대로 제대로 작동하지 않았다. 하나의 문제를 해결하면 다른 곳에서 새로운 에러가 터져 나왔다. 우리는 근본적인 접근법이 틀렸다는 사실을 인정하는 대신, 눈앞의 에러 메시지를 잡는 데에만 매달렸다. 늪에 빠진 사람이 발버둥 칠수록 더 깊이 가라앉는 것처럼, 우리의 노력은 상황을 점점 더 악화시킬 뿐이었다.
결국 우리가 그 헛된 신념과 씨름하는 동안, 황금 같은 두 시간이 증발해 버렸다.
원래대로라면 프로덕트를 안정시키고, 발표 자료와 데모 시나리오를 준비하는 데 썼어야 할 시간이었다. 특히 우리 프로덕트의 강점을 어필하기 위해 3시간가량 문서화에 집중하려던 계획은 물거품이 되어버렸다.
시계를 확인했을 때, 정신이 아득해졌다. 우리는 사소한 버그 하나를 잡으려다, 이제는 아예 전체 프로덕트가 동작하지 않는 최악의 상황에 직면해 있었다. 마감까지 남은 시간은 단 2시간 남짓이었다
포기와 자포자기: 데모조차 불가능할 위기, Mock API를 결심하다
마감 2시간 전, 우리는 마침내 항복을 선언했다.
"안되겠다. 그냥 원래 하던 대로 하자."
깨끗하고 일관성 있는 배포라는 허울 좋은 목표는 버렸다. 이제 목표는 단 하나, '어떻게든 데모만 가능하게 만들자'였다. 우리는 다시 Q에게 하나씩 수동으로 배포를 시키며 급한 불을 끄려 했다.
하지만 재앙은 거기서 끝나지 않았다. 우리가 '깨끗한 표본'이라고 믿었던 소스 코드는, 사실 지난 이틀간 우리가 수동으로 고쳐왔던 수많은 버그 패치가 반영되지 않은 엉망인 상태였다. 하나를 살리면 다른 하나가 죽고, API는 응답하지 않았으며, 다음 스텝으로 넘어가지 않는 치명적인 버그들이 연쇄적으로 터져 나왔다.
상황은 2시간 전보다도 악화되었다. 그때는 적어도 작동하는 무언가라도 있었지만, 이제 우리 앞에는 완전히 망가진 코드 덩어리뿐이었다.
마감 1시간 전. 팀에는 침묵이 흘렀다. 패배감이 공기 중에 무겁게 떠다녔다. 거의 자포자기한 목소리로 말했다.
"...그냥 Mock으로 하죠."
Mock API. 개발자에게, 특히 해커톤 참가자에게 그것은 패배 선언과 같다. 실제 서버와 통신하는 '살아있는' 프로덕트가 아니라, 그저 정해진 가짜 데이터를 보여주는 '죽은' 껍데기일 뿐이니까.
하지만 우리에겐 다른 선택지가 없었다. 우리는 지난 48시간의 노력을, 우리의 아이디어를, 우리의 자존심을 모두 내려놓고, 그저 화면 껍데기라도 보여주기로 결정했다. 그것이 우리가 할 수 있는 전부였다.
마지막 40분의 기적: 모든 것을 내려놓고 Q에게 온전히 맡겼을 때 일어난 일
Mock API를 빠르게 만들었고 가까스로 돌아는 가는 서비스로 '보이게' 되었다.
그것으로 데모 영상과 소개 이미지들을 만들 수 있었다.
허탈하게 앉아있던 그 순간, 문득 이런 생각이 들었다.
'도대체 '진짜' 정답은 뭐였을까?'
어차피 망한 거, 오답 노트라도 쓰자는 심정이었다. 뒤늦게 AWS 서버리스 배포의 베스트 프랙티스를 찾아보기 시작했다. 그리고 그곳에서 'AWS SAM(Serverless Application Model)'이라는, 우리에겐 생소한 이름을 발견했다. 프로젝트 전체를 하나의 템플릿으로 관리하고 배포하는, 우리가 어설프게 흉내 내려고 했던 바로 그 방식의 '정답'이었다.
사실은 테라폼 같은 IaC(Infrastructure as Code) 도구의 존재를 알고 있었다. 머리로는 그것이 '정답'에 가깝다는 것도 어렴풋이 인지하고 있었다.
하지만 머리로 아는 것과, 압박감 속에서 능숙하게 쓸 수 있는 것은 전혀 다른 차원의 문제였다. 당장 눈앞의 불을 꺼야 하는 상황에서, 익숙하지 않은 SAM 템플릿의 문법을 공부하고 설정 오류를 잡는 데 시간을 쏟는 것은 더 큰 재앙을 불러올 것이라 지레짐작했다. 그것은 순전히 '인간'의 속도와 학습 곡선만을 기준으로 한, 치명적인 오판이었다. 그러니까, AI를 외치면서도 계산서에 'AI'라는 변수를 빠뜨리고 있었던 것이다.
마감까지 남은 시간, 40분.
이미 자포자기한 상태였다. 될 리가 없다고 생각했다. 하지만 그냥 이대로 끝내기엔 너무 분했다. 밑져야 본전이라는 심정으로, 나는 Q에게 마지막 명령을 내렸다. 이전처럼 세세한 지시가 아니었다. 모든 것을 내려놓은, 온전한 위임이었다.
"우리 프로젝트, 지금부터 AWS SAM 방식으로 전체 배포해 줘."
"지금 올라가 있는 거 상관 없어 다 지워도 돼. 네가 알아서 그냥 전부 작동하게 완벽하게 되게 해줘. 네가 알아서 다 해줘 !!!"
그때부터 믿을 수 없는 광경이 펼쳐졌다.
별 기대 없이 바라보던 화면에서, Q가 스스로 template.yml 파일을 생성하고, 우리 프로젝트의 복잡한 구조를 분석해 리소스를 정의하기 시작했다. 그리고는 우리가 지난 두 시간 동안 그토록 고통받았던 배포 과정을 거침없이 실행해나갔다.
가장 충격적인 순간은, Q 역시 우리가 겪었던 똑같은 에러들을 마주쳤을 때였다. 권한 문제, CORS 오류, 의존성 충돌... 하지만 녀석은 우리처럼 당황하거나 좌절하지 않았다. 에러 로그를 읽고, 스스로 해결책을 찾아 코드를 수정한 뒤, 다시 배포를 시도했다. 그 모든 과정이 인간의 개입 없이 자율적으로, 그리고 순식간에 일어났다. 우리는 그저 스크린에 쏟아지는 로그를 넋 놓고 바라볼 뿐이었다.
그리고 마침내. 마감 10분 전.
배포 성공 메시지가 터미널에 찍혔다. 거짓말처럼, 우리의 'AI Chef'는 완벽하게 동작하고 있었다.
그 순간 터져 나온 감정은 기쁨이라기보다 경외에 가까웠다. 그리고 머리를 한 대 세게 맞은 듯한 깨달음이 찾아왔다.
"와... 처음부터 이렇게 했어야 하는 거구나."
상은 못 탔지만, ‘삽질의 증거’를 받다
결과적으로, 우리는 대상도, 기술 혁신상도 받지 못했다. 마지막 40분의 기적이 아니었다면 데모조차 못 했을 우리에게 어쩌면 당연한 결과였다.
하지만 아주 예상치 못한 '상'을 하나 받았다. 바로 'Amazon Q 전체 사용량 2등'이었다. 처음에는 어리둥절했지만, 이내 그 의미를 깨닫고 헛웃음이 나왔다. 겉으로 보기엔 우리가 얼마나 처절하게 헤맸는지 보여주는 '삽질의 증거'처럼 보였다.
하지만 다시 곱씹어보니, 어쩌면 그게 전부가 아닐지도 모른다는 생각이 들었다. 우리의 압도적으로 높았던 Q 사용량은, 우리가 해커톤 내내 고수했던 급진적인 AI-Native 방식의 당연한 결과는 아니었을까?
우리는 이번 해커톤에서 철저한 '문서 주도 개발' 원칙을 지켰다. 기획과 설계 문서를 AI가 가장 잘 이해할 수 있는 형태로 먼저 만들었고, 팀원들은 코드 한 줄 직접 작성하지 않았다. 심지어 AI가 생성한 코드를 눈으로 직접 확인하지 않고, 오직 문서와 테스트 결과만을 믿고 다음 단계의 명령을 내렸다. 이런 방식은 자연스럽게 AI와의 수많은 상호작용을 유발한다.
물론, 마지막 몇 시간 동안의 처절한 몸부림이 사용량 수치를 폭증시킨 것 또한 사실이다. 결국 이 상은 우리의 'AI-Native라는 방향성에 대한 확신'과 '경험 부족에서 온 처절한 삽질'이 뒤섞인 결과물일 것이다.
우리는 해커톤 내내 '전통적인 서버 개발'의 감각에서 벗어나지 못했다. 어떻게든 배포 방식을 완벽하게 통제하고, 모든 인프라를 내 손으로 직접 구축해야 한다는 강박. 그것이 좋은 개발자의 덕목이라는 낡은 믿음에 갇혀있었다. 나름 AI-Native를 외치고 있었지만, 우리의 몸과 머리는 여전히 과거의 패러다임에 묶여 있었던 것이다.
이번 해커톤에서 진짜 중요한 것은 그런 것이 아니었다. 핵심은 '얼마나 AI를 믿고, 핵심 가치에 빠르게 도달하는가'였다. 우리는 우물 안 개구리였다. 우리가 아는 AI 활용법이 전부인 줄 알았지만, 세상은 이미 저만치 앞서나가고 있었다.
상은 못 탔지만, 우리는 그보다 더 값진 '패배의 경험'과 우리가 갇혀 있던 '우물'의 크기를 정확하게 알게 되었다.
6. 결론: AI 시대, 개발자의 길을 다시 묻다
31시간의 처절한 삽질과 마지막 40분의 기적. 돌이켜보면 Amazon Q는 단순히 코드를 짜는 도구가 아니었다. 온몸으로 우리를 부딪쳐가며 새로운 시대의 개발 방식이 무엇인지 가르쳐 준 혹독한 스승이었다. 그 스승이 내게 남긴 두 가지 깨달음은 다음과 같다.
겸손: 세상은 넓고, 진짜 강자는 많다
우리는 꽤 자신만만했다. asyncsite에서 AI를 활용해 빠르게 프로토타입을 만드는 우리만의 방식이 꽤 앞서나간다고 생각했다. 하지만 그건 우리만의 우물 안에서나 통하는 이야기였다.
해커톤에서 마주한 다른 팀들, 특히 최종 우승팀의 결과물을 봤을 때의 충격을 잊을 수 없다. 특히 '노션 마스터 페이지'에 담긴 기획안을 Amazon Q가 읽어 컨텍스트 주입을 자동화하고, Draw.io Mcp를 Q에 연결해 '다이어그램'으로 된 설계도를 생성하는 것으로 시각화를 자동화하고, 또 개발은 그 설계도를 기반으로 진행되는 식의 찐 AI Native 개발 프로세스가 너무 큰 임팩트가 있었다.
문서를 사람이 만들고 AI가 읽는 우리의 방식도 충분히 혁신적이라 생각했는데, 기획안으로부터 핵심 설계 문서 자체를 MCP를 이용해 연결하는 것에 거리낌이 없는 모습을 보며 놀랐다. 진정한 의미의 '문서 자동화'였다.
이런 접근은 단순히 '잘 만들었다'의 차원이 아니다. AI를 활용하는 방식, 문제에 접근하는 철학 자체가 우리와는 다른 궤도에 있었다. 우리는 AI를 '빠른 손을 가진 신입'처럼 쓰고 있을 때, 그들은 AI를 '전략을 이해하는 파트너'로 활용하고 있었다.
진정한 성장은 내가 서 있는 우물의 크기를 아는 것에서 시작된다고 생각한다. 이번 해커톤은 내게 그 우물의 크기와 함께, 드넓은 세상의 존재를 알려주었다.
가능성: "야, AI 개발, 그렇게 하는 거 아니야!"
마지막 40분의 기적 이후, 머릿속에서 이런 외침이 들리는 듯했다. "야, AI 개발, 그렇게 하는 게 아니야!"
우리의 가장 큰 실수는 AI를 인간처럼 대하려고 했던 것이다. 세세하게 지시하고, 결과를 하나하나 확인하고, 내 통제하에 두려는 것. 그것은 AI의 가능성을 억누르는 최악의 방식이었다. 우리는 AI라는 슈퍼카를 놔두고, 1단 기어만 넣은 채 시내 주행을 하고 있었던 셈이다.
진정한 AI-Native 개발은 '위임'에서 시작된다. '어떻게'를 지시하는 것이 아니라, '무엇을' 원하는지를 명확히 알려주고 그 과정 전체를 온전히 믿고 맡기는 것. AI가 항상 정답이 아닐 수도 있다. 하지만 먼저 그 정답에 대해서, 베스트 프랙티스에 대해서 탐색하라고 하면, AI는 꽤 잘 한다.
우리가 마지막 40분에 절박하게 던졌던 "AWS SAM으로 전체 배포해 줘"라는 단 한마디의 명령. 그리고 그 이전에, "이 방식에서 베스트 프랙티스는 뭐야?" 라고 먼저 물었어야 했던 것. 그것이야말로 우리가 처음부터 했어야 할, 새로운 시대의 소통 방식이었다.
AI는 인간 동료가 아니다. 지치지 않고, 불평하지 않으며, 감정에 휘둘리지 않고 오직 목표를 향해 나아가는 완전히 다른 종족의 파트너다. 이 파트너의 가능성은, 우리가 인간적인 통제의 관성을 버리는 만큼만 열린다.
이미 다가온 미래
또 한번 확신하게 됐다.
경쟁의 구도는 'AI vs 인간'이 아니라는 것. 이미 낡은 프레임이다. 새로운 시대의 경쟁은 전혀 다른 축에서 벌어지고 있다.
바로 'AI를 쓰는 사람'과 'AI를 '잘' 쓰는 사람'의 대결이다. 그리고 AI를 '안'쓰는 사람은 당연히 이 경쟁에 끼지도 못할 것이 너무 자명하다.
31시간 동안, 우리는 그 두 가지 모습을 모두 보였던 것 같다. 처음 30시간 동안의 우리는 약간 중간 정도 포지션이 아니었나 싶다. AI를 쓰긴 쓰지만, 윽박지르고, 하나하나 가르치고, 의심하며 그저 그런 결과물밖에 만들지 못했다. 반면 마지막 40분의 우리는 후자에 가까웠다.
AI의 본질을 이해하고, 목표를 위임하고, 그 능력을 온전히 신뢰하며 기적 같은 결과를 만들어냈다.
최근 '마이리얼트립'은 iOS, 백엔드 개발자 직군을 폐지하고 모두 '프로덕트 엔지니어(PE)'로 통합하겠다는 파격적인 선언을 했다. AI가 코드를 짜주는 시대에 더 이상 기술 스택의 경계는 무의미하며, 중요한 것은 문제를 정의하고 끝까지 해결하는 능력이라는 것이다.
미래는 생각보다 훨씬 빨리 도착할지 모른다. AI를 활용하는 것은 기본값이다. 생존과 도태는 '얼마나 AI를 깊이 이해하고, 새로운 방식의 협업을 통해 압도적인 성과를 만들어내는가'에 따라 갈리게 될 것이라는 생각에 점점 더 확신이 생긴다.
패러다임의 전환기에는 언제나 말이 많다. "아직은 시기상조다", "이전 방식이 더 안정적이다", "그건 진짜 실력이 아니다" 와 같은 논쟁들. 역사를 돌이켜보면, 모든 거대한 기술적 변화는 언제나 비슷한 저항을 거쳐왔다.
하지만 진짜 위험은 이런 시끄러운 논쟁이 아니라, 소리 없이 서서히 올라가는 물의 온도에 있다.
서서히 뜨거워지는 냄비 속의 개구리가 위험을 감지하지 못하고 결국 삶아지는 것처럼, 패러다임의 전환 또한 그렇게 예고 없이, 그러나 결정적으로 다가온다. 변화를 인지했을 때에는, 이미 너무 늦었을지도 모른다.
늘, 그런식이다.
경험을 통해 얻게 된 것들
이번 해커톤은 머릿속에서 그려오던 그림이 현실의 압박과 만났을 때 어떤 모습으로 나타나는지 확인할 수 있었던 값진 실험이었다.
31시간 동안의 서툰 실패는 우리가 아직 낡은 관성에서 얼마나 자유롭지 못한지를 보여주었던 것 같다. 또 마지막 40분의 성공은 우리가 가고자 하는 방향이 틀리지 않았다는 가능성을 증명해주는 값진 경험이었던 것 같다.
결국 중요한 것은 계속해서 만들어보고, 부딪혀보는 경험 그 자체다. 대단한 선언이나 구호보다는, 작은 성공과 실패의 경험을 통해 우리의 방식을 꾸준히 다듬어 나가는 것.
그렇게 할 수 있는 실험을 계속해나갈 생각이다.
https://github.com/awsqhackathonXddeokssang/team21-aws-hackathon
GitHub - awsqhackathonXddeokssang/team21-aws-hackathon
Contribute to awsqhackathonXddeokssang/team21-aws-hackathon development by creating an account on GitHub.
github.com
재밌는 에피소드 1.
디버깅을 해야하는데 자꾸 로그를 못 찾는 현상이 있었다. 찍고 찾고 찍고 찾고 반복하다가 빡이쳐서 CloudWatch 가격 신경 쓰지말고 풀세트로 모두 적용하라고 했다. 아래는 대화 복원한 기록이다. 이거 때문에 진짜 엄청 웃었다.
재밌는 에피소드 2.
새벽 세시에 먹는 치킨은 ㅈㅁㅌ이다. 어쩔수가 없다.
'회고' 카테고리의 다른 글
| 결국, 세상은 만드는 사람들의 것 (0) | 2025.09.07 |
|---|---|
| 설정 파일 한 줄이 1TB 디스크를 마비시킨 사건: 미니PC로 운영하는 12개 마이크로 서비스 장애 회고 (4) | 2025.08.16 |
| 제가 만든 AI가 처참히 패배했습니다 (그리고 그보다 짜릿한 순간은 없었습니다) (4) | 2025.08.01 |
| 테스트 30분 → 3분: MSA 인증 시스템과 E2E 자동화 플랫폼 20시간 구축 썰 (3) | 2025.07.13 |
| 프론트 제가 한번 세팅해봤는데요 (← 프론트 1도 모르는 백엔드 개발자) (1) | 2025.07.07 |
