해커톤 프로젝트가 CodeRabbit에서의 제 일이 되기까지
해당 블로그는 Ayush Sridhar 원저자의 글 'How a hackathon project turned into my work at CodeRabbit'을 번역한 것입니다. 더 나은 이해를 위해서 약간의 의역이 반영되었습니다.
10월 말, 저는 CalHacks 해커톤에서 받은 상을 찾으러 CodeRabbit 사무실을 방문했습니다.
그리고 몇 달 뒤, 저는 소프트웨어 엔지니어 인턴이 되어 같은 사무실에 걸어 들어갔습니다.
여기까지가 큰 줄거리입니다. 하지만 정말 중요한 부분은, 특히 여러분이 주니어 개발자라면, "와, 운 좋았네"가 아닙니다. 그렇게 되기까지 이어진 일련의 사건들입니다.
이 글은 필요 이상으로 힘겹게 느껴지는 시장에서 인턴 자리를 얻으려 애쓰는 주니어 개발자들을 위한 글입니다. 제게 통했던 "비공식 경로"를 나누고 싶습니다.
이 모든 일의 출발점이 된 기술 프로젝트는 merj였습니다. CodeRabbit을 활용해, LLM이 충돌을 제대로 해결하는 데 빠져 있던 재료인 의미론적 의도(semantic intent)를 채워 준 AI 기반 병합 충돌 해결 도구입니다.
지금 인턴으로서 무엇을 하고 있는지도 함께 이야기하겠습니다. 저는 그때의 핵심 아이디어를 그대로 가져와, 팀이 GitHub에 깔끔하게 녹아드는 워크플로로 PR 병합 충돌을 해결하도록 돕는 무언가로 발전시키고 있습니다.
10월: 해커톤의 혼돈에서 해커톤 우승까지
CalHacks는 가장 좋은 의미로 혼란스럽고 에너지가 넘칩니다. 절반쯤 짜다 만 데모, 절반쯤 졸고 있는 팀, 그리고 "저거 안 되네, 고쳐야 해"라는 말이 끊임없이 오갑니다.
저와 친구들은 많은 팀이 초반에 하는 일을 그대로 했습니다. 아이디어를 잔뜩 브레인스토밍한 다음, 스폰서와 참가자들을 찾아다니며 무엇이 현실적으로 가능한지, 그리고 주말 동안 만들기에 정말 재밌을 만한 게 무엇인지 물어봤습니다.
그때 저희는 CodeRabbit을 만났습니다.
그 시점에 저희는 "코드 리뷰 제품이 필요해"라고 생각하지 않았습니다. 저희는 해커처럼 생각하고 있었습니다. "36시간 안에 야심 찬 걸 하나 내놓고 싶은데, 급하게 밀어 넣는 변경들 속에서 이게 무너지지 않게 하려면 어떻게 해야 하지?"
저희는 CodeRabbit이 도움이 되겠다고 깨달았습니다. 그리고 그때 CodeRabbit의 개발자 애드보킷(developer advocate) Hendrik Krack을 만났습니다.
모든 것을 바꾼 순간이었습니다. Hendrik은 단순히 제품을 소개하는 데서 그치지 않았습니다. 그는 CodeRabbit이 저희 솔루션에 실제로 쓸모 있게 들어맞도록 프로젝트 아이디어 자체를 다듬는 일을 도와줬습니다.
초기의 발상은 전형적인 해커톤식 사고였습니다. "LLM에 컨텍스트를 좀 던져 넣고 알아서 해결해 주길 바라기."
Hendrik은 저희를 훨씬 나은 접근으로 이끌었습니다.
"모델에 날것의 디프만 주지 마세요. 각 사람이 무엇을 하려고 했는지에 대한 의미론적 이해를 주세요."
돌이켜 보면 당연하게 들릴 수도 있습니다. 하지만 해커톤 한복판에서는 "LLM이 알아서 해 주는 마법"에 기대기 쉽거든요. Hendrik은 LLM이 성공하려면 실제로 무엇이 필요한지 짚어 줬고 그게 저희 아키텍처의 핵심이 됐습니다.
해커톤이 진행되는 동안 저희는 Hendrik과 계속 연락을 주고받았고 CodeRabbit의 Dev Experience Lead인 Erik Thorelli도 만났습니다. 저희는 두 사람의 워크숍에 참석했고 여러 번 조언을 구했으며 배운 것을 바탕으로 아이디어를 계속 다듬어 나갔습니다.
발표 시간이 됐을 무렵, 저희는 실제 피드백을 받으며 다듬어 온 결과물을 선보이고 있었습니다. 심지어 저희가 만들던 것에 워낙 관심을 보여 준 덕분에 CodeRabbit 팀 앞에서 직접 발표할 기회까지 얻었습니다.
결국 저희는 CodeRabbit 트랙에서 우승했습니다. 상품도 근사했습니다. 메타 AI 안경, 그리고 그날 오후 CodeRabbit 사무실 방문이었습니다.
하지만 제 기억에 오래 남은 건 그 아이러니였습니다. 저는 해커톤 상품으로 그 사무실을 방문했고 3개월도 채 지나지 않아 같은 사무실에서 인턴으로 일하게 될 줄은 전혀 몰랐습니다.
CalHacks에서 만든 것: AI 기반 병합 충돌 해결 도구 merj
저희 프로젝트의 이름은 merj였습니다. "merge"처럼 발음하되 일부러 살짝 틀리게 지은 이름입니다.
문제: 병합 충돌은 소프트웨어 개발에서 가장 지루하고 성가신 부분 중 하나입니다.
하필 가장 안 좋은 순간에 등장합니다. 충돌 표시(conflict marker)만 보고 상황을 파악하기 어렵고 "마찰은 큰데 보상은 적은" 일의 완벽한 사례죠. 새로운 걸 만드는 것도 아니고 그저 다시 만들던 자리로 돌아가려 애쓰는 것뿐입니다.
그래서 저희는 이렇게 물었습니다. 병합 충돌을 해결하는 일이 명령어 하나 실행하는 것만큼 쉬울 수 있다면 어떨까?
사용자 경험
이 도구는 CLI였고 진입점은 단순했습니다.
merge pull
내부적으로는 평범한 git pull을 시도합니다. Git이 병합 충돌을 알리면 merj가 충돌 해결 워크플로를 실행합니다.
저희는 일부러 그렇게 설계했습니다. "또 하나의 AI 챗 도구"를 만들고 싶지 않았거든요. 개발자들이 이미 쓰고 있는 기존 워크플로에 그대로 들어맞는 무언가를 원했습니다.
가장 중요했던 부분, 상품은 아니었습니다
그 주말 동안 Hendrik은 저희가 "LLM 마법"에 기대지 않도록 콘셉트를 다듬는 일을 도와줬습니다. 그는 CodeRabbit의 의미론적 요약을 의도 레이어로 활용하는 방법을 알려 줬고 CodeRabbit이 어떻게 동작하는지, 저희 프로젝트에 어떻게 통합될 수 있는지 묻는 질문에 기꺼이 시간을 내어 답해 줬습니다.
Erik의 워크숍 덕분에 저희는 CodeRabbit을 더 깊이 이해했고 그 결과 통합은 두루뭉술함에서 벗어나 훨씬 실질적으로 바뀌었습니다.
저희는 계속 피드백을 받으러 돌아왔고 그때마다 프로젝트는 더 나아졌습니다.
이건 주니어 개발자로서 제가 얻은 가장 중요한 교훈 중 하나입니다.
도움을 요청하는 것도 하나의 기술입니다. 그리고 그 요청을 흐름을 타고 명확하게 잘 해내면, 경험 많은 엔지니어들은 오히려 먼저 나서서 돕고 싶어 합니다.
좋은 "도움 요청"은 이런 모습입니다.
- "목표는 이렇습니다."
- "지금까지 만든 건 이렇습니다."
- "잘 안 되는 건 이 부분입니다."
- "저희가 고민 중인 선택지는 두 가지입니다."
- "다음엔 무엇을 하시겠어요?"
이렇게 하면 스폰서 부스에서의 대화가 진짜 인연으로 바뀝니다.
후속 연락: 해커톤이 인턴십으로 이어진 과정
CalHacks가 끝난 다음 주, 저는 Hendrik과 Erik에게 연락해 인턴십 기회가 있을지, 그리고 그 과정을 헤쳐 나가도록 도와줄 수 있을지 물었습니다.
두 사람은 저를 CodeRabbit의 Applied AI 부문 VP인 David Loker와 연결해 줬고 저희는 인터뷰를 잡았습니다. 인터뷰는 해커톤의 연장선처럼 느껴졌습니다.
- 저는 저희 프로젝트 아키텍처를 꼼꼼히 설명했습니다.
- 후속 작업과 제품을 개선할 방법을 이야기했습니다.
- 이 아이디어가 CodeRabbit의 기존 제품에 어떻게 들어맞을지 논의했습니다.
- 기술적 선택과 실패 양상(failure mode)을 더 깊이 파고들었습니다.
저는 다음 날 오퍼를 받았습니다.
자랑하려고 이 이야기를 꺼내는 게 아닙니다. 요즘 같은 환경에서 중요한 무언가를 보여 주기 때문에 나누는 겁니다. 여러분이 어떻게 생각하고 만들고 반복하는지 이미 증거로 보여 줬다면, 사람들이 여러분을 믿기가 훨씬 쉬워집니다.
주니어 개발자를 위한 실용적인 조언 (다시 해도 이렇게 할 것들)
구체적인 조언으로 글을 마무리하고 싶습니다. 누군가 제게 이걸 좀 더 일찍 말해 줬으면 좋았을 거라는 아쉬움 때문입니다.
1. 진짜 엔지니어링 결정을 요구하는 것을 만드세요
튜토리얼도 괜찮습니다. 하지만 여러분의 궤적을 바꾸는 프로젝트에는 이런 것들이 있습니다.
- 제약
- 트레이드오프
- 실패 양상
- 실제 통합 지점
그런 프로젝트가 인터뷰를 심문이 아니라 대화처럼 느껴지게 만듭니다.
2. 아직 만드는 중일 때 도움을 요청하세요
"완벽"해질 때까지 기다리지 마세요.
피드백이 설계를 바꿀 수 있을 만큼 일찍 물어보세요.
3. 답하기 쉬운 질문을 하세요
상대의 시간을 존중한다는 건 침묵하는 게 아니라 명확하게 묻는 것입니다.
이런 것들을 보여 주세요.
- 무엇을 시도했는지
- 무엇이 깨졌는지
- 무슨 일이 벌어지고 있다고 생각하는지
- 어떤 피드백을 원하는지
4. 절박함이 아니라 증거로 후속 연락을 하세요
"제가 만든 것과 배운 것은 이렇습니다"라는 메시지는 기억에 남습니다.
"한 번만 기회를 주세요" 같은 뻔한 메시지는 그렇지 않습니다.
5. LeetCode는 관문을 통과하게 도와줍니다. 무언가를 만드는 일은 문을 새로 만듭니다.
인터뷰 준비도 중요합니다. 하지만 사람들의 시선을 끌고 기회를 만들어 내는 건 인상적인 무언가를 만드는 일입니다.
핵심은 이것입니다
제가 CodeRabbit에서 인턴 자리를 얻은 이유는 이렇습니다. 진짜 무언가를 만들었고 일찍 도움을 요청했으며 빠르게 반복했고 증거로 후속 연락을 했습니다.
놀라운 건 그 순환이 지금도 이어지고 있다는 점입니다. 주말 실험으로 시작한 해커톤 프로젝트가 이제 제가 인턴으로서 직접 맡게 된 실제 제품 과제로 자리 잡아 가고 있습니다.
힘든 환경에서 두각을 나타내려는 주니어 개발자라면, 혼자 틀어박혀 지원서만 더 열심히 넣지 마세요. 대신 스스로 자랑스러운 무언가를 만들고 그 결과물에 관심을 가질 만한 사람들 앞에 내놓으세요.
관련해서 CodeRabbit이 Claude 위에 기획 레이어를 만든 방법에서 의도를 코드 리뷰에 실어 나르는 접근을 살펴보실 수 있습니다. CodeRabbit으로 PR 리뷰 자동화 시작하기와 AI 에이전트를 신뢰하시나요도 함께 읽어 보시길 추천 드립니다.