창의력을 발휘해서 메인 프로덕트에 기여하기

안녕하세요, 최근 Creatrip에 입사한 이후 정신없는 나날들을 보내고 있는데요. Frontend Engineer로 입사한 제가 현재 어떻게 회사에 적응하며 기여하고 있는지를 이 글에서 풀어보려고 합니다.

이 글에서는 단순히 제가 메인 프로덕트의 태스크를 할당받고 업무를 수행하는 이야기가 아닙니다. AI Cell에서 주 업무를 수행하면서도, AI를 활용해 메인 프로덕트에 기여하는 저의 이야기를 담은 글입니다.

어떻게 기여할 것인가

간략히 소개하자면, 저는 Frontend Engineer로 팀에 합류하여 AI Cell에서 AI를 활용한 Product 개발과 DX 개선 업무를 맡고 있습니다. 하루하루가 새로운 도전이고, 매 순간 어려운 문제와 마주하는 환경이 제 일상이었습니다. 그러다 보니 메인 프로덕트에 관한 태스크가 주어지지 않았고, 주어진 작업을 하는 것만으로도 시간이 매우 빠듯했습니다. 물론 AI 관련 업무는 매우 흥미로웠습니다. 새로운 도전이 주는 색다른 경험과 어려움을 해결하는 과정에서 느끼는 성취감이 있었습니다.

그러나 한편으로는 Frontend 개발자로서 생태계에 관여하고, Frontend에 기여하고 싶다는 욕심이 있었습니다. 그래서 매번 PR을 보려고 노력하고, 슬랙 채널에서 나누는 대화도 따라가려 노력했습니다.

하지만 팀원들과 대화하고 PR을 살펴보고 리뷰를 남기고, 질문을 하는 것만으로는 Frontend 개발자로서의 갈증이 채워지지 않았습니다. 저는 코드를 작성하고, 버그를 고치고, 실제로 서비스에 영향을 주는 직접적인 기여를 하고 싶었습니다. 하지만 여기에는 몇 가지 장벽이 있었습니다…

REST API만 다뤄본 저에게 GraphQL은 낯선 영역이었고, 다양한 어권의 다국어 i18n 시스템은 복잡했으며 팀의 컨벤션은 익숙하지 않았습니다. 물론 시간을 내서 도메인 문서를 정독하거나 코드베이스를 플로우 차트로 그려가며 이해하는 방법도 있었지만, 문서의 파편화로 모든 도메인 지식을 흡수하기란 쉽지 않았고 AI Cell 업무와 병행하기에는 현실적으로 무리가 있었습니다.

그리고 무엇보다 문서와 코드를 몇 시간 동안 읽기만 하는 건 제 취향이 아니었습니다!

생각을 행동으로

관찰하기

생각으로만 해결되지 않는 문제라는 것을 알기에 이 문제를 어떻게 해결할 수 있을지를 고민하였고 무작정 슬랙의 버그 신고 채널을 관찰하기 시작했습니다. 버그 신고 채널은 실시간으로 발생한 버그와 QA 도중 발견된 버그들이 올라오는 채널로 문제가 올라오면 신속하게 대응을 해야만 합니다.

서비스 운영 경험이 있는 개발자라면 이러한 이슈들이 서비스에 얼마나 큰 영향을 미치는지, 그리고 이에 대응하는 것이 얼마나 큰 피로도가 드는 일인지 아실 겁니다. 가령 새벽에 결제 이슈라도 발생한다면 그 영향은 매출에 직결되는 문제이고 자다 깨서 대응을 해야 하기 때문에…. 상상만 해도 끔찍합니다.

Creatrip 역시 예외는 아니었습니다. 월 150만 명이 사용하는 글로벌 여행 플랫폼에서는 다국어 키 하나가 누락되는 것만으로도 UX 저하와 신뢰도 하락으로 이어집니다. 작은 버그 하나의 파급력이 상당했죠.

그렇다면 도메인 지식도 부족하고, 기술 스택도 낯선 제가 이 문제를 어떻게 해결하고 저의 갈증을 채울 수 있었을까요?

AI와 함께 접근하기

"도메인 지식이 부족해도, 기술 스택이 낯설어도, 잠재적 버그를 찾아내는 역할로 기여할 수 있지 않을까?”

저는 이슈가 발생한 환경에 놓이면, 이를 해결하기 위해 빠르게 도메인을 배울 수 있고 기술 스택과 컨벤션을 익힐 수 있다고 생각합니다. 문제 해결이라는 명확한 목표가 있을 때 학습 효율이 가장 높다는 것을 경험으로 알고 있었거든요.

하지만 메인 프로덕트에서는 제가 해결할 이슈가 할당되지 않았습니다. 그렇다면 제가 직접 이슈를 찾아내면 되지 않을까요?

이때 떠올린 것이 바로 AI였습니다. 코드 리뷰 과정에서 사람이 놓치기 쉬운 패턴들, 특정 조건에서만 발생하는 히든 케이스들을 AI가 자동으로 탐지할 수 있다면? 저는 이미 팀에서 잘 구축해둔 AI PR Review Action을 활용하기로 했습니다.

AI PR Review Action은 사용자의 의도를 파악하는 Intent Layer를 통해 요청을 분류하고, 각 의도에 맞는 프롬프트와 도구를 주입하여 Claude Agent SDK를 호출하는 구조였습니다. 지금까지는 빠른 속도와 준수한 성능의 Sonnet 4.5 모델로 대부분의 상황에서 효용을 보이고 있었지만, 심층적인 코드 분석에서는 한계가 있었습니다.

프롬프트나 로직의 문제가 있었을 수도 있지만, 몇 차례의 실험을 진행해본 결과 Sonnet 4.5 모델은 다양한 히든 케이스에 대한 시나리오별 심층 분석을 생각보다 잘 수행하지 못한다는 사실을 알게 되었고 Reasoning 특화 모델인 GPT-5-Codex High를 활용한 새로운 접근법을 추가했습니다.

처음 PR Review Action이 요청되었을 때, haiku 모델을 이용해서 사용자의 의도를 미리 파악하게 하고 DEEP_DIVE 인텐트가 감지되면 Reasoning에 강점을 가진 OpenAI Agent SDK를 호출합니다.

GPT-5-Codex High 모델은 스스로 잠재적 버그를 탐지하고 히든 케이스를 포함한 시나리오별 테스트 코드를 작성한 이후 테스트를 실행하여 검증합니다. 즉 AI가 사람과 같이 코드를 보면서 스스로 의심스러운 부분을 찾아 깊이 분석하도록 설계했습니다.

그 결과는 상상 이상이었습니다.

AI가 발견해준 잠재적 버그들은 사람들이 리뷰에서 놓치기 쉬운 패턴들을 찾아냈습니다. 레거시부터 최근에 추가된 코드까지 폭넓게 이슈를 탐지해주어 인지하지 못한 영역까지도 조기에 대응할 수 있는 환경을 마련해주었습니다.

그리고 저는 이를 해결해나가는 과정에서 “왜 이게 버그인지”를 이해하기 위해 주변 코드를 읽어야 했고, 그 과정에서 도메인 지식을 흡수하고 팀의 기술 스택과 컨벤션을 자연스럽게 익힐 수 있었습니다. 또한 테스트 코드를 추가하여 안정성을 높이고 레거시 마이그레이션까지 직접적인 기여를 할 수 있게 되었죠.

저에게 이 방식은 문서를 정독하는 것보다 훨씬 실용적이고 빠른 학습 방법이었습니다.

마치며

생각을 생각에 그치지 않고, 행동으로 옮긴 결과 제가 원하는 결과를 얻을 수 있게 되었고 그게 저만의 기여 방식이 되었습니다.

돌이켜보면, 이 방법이 가능했던 건 어쩌면 Creatrip의 팀 문화 덕분이었습니다. 정해진 온보딩 프로세스를 따르라고 강요하지 않았고, 오히려 각자의 방식으로 창의력을 발휘해 어떠한 방식으로든 문제를 해결할 수 있도록 장려해주었죠. "이렇게 해야 해"가 아니라 "네 방식대로 해봐"라고 말해주는 환경 말이죠.

그래서 저는 저만의 방식으로 버그를 발견했고, 이를 해결해나가는 과정에서 자연스레 도메인 지식을 흡수하고, 버그를 고치면서 기술 스택과 컨벤션을 배울 수 있었습니다. 결과적으로 제가 선택한 이 우회로가, 정석 루트보다 저에게는 더 빠르고 재미있는 길이었던 것 같습니다.

제 이야기를 읽어 주셔서 감사합니다 🙇‍♂️