프로덕트를 향한 진짜 몰입

안녕하세요. 페이타랩에서 프로덕트를 향한 진심으로 개발에 몰두하고 있는 백엔드 개발자 도경윤입니다.

“업무 시간의 20%를 자신이 선택한 프로젝트에 자율적으로 사용할 수 있도록 허용한다는 Google의 20% 프로젝트”

“진행하던 프로젝트는 제쳐두고 하루 만에 아이디어 제안부터 배포까지 당근의 피처톤 데이”

위와 같은 개발 문화 이야기를 접하며 '우리 팀도 저런 문화를 가졌으면!' 하는 갈증을 느껴보신 적이 있으신가요?

활발한 사내 스터디, 정기적인 해커톤 개최, 혹은 상시적인 코드 리뷰 시스템 등은 개발자들이 스스로 성장의 재미를 발견하고 역량을 키울 수 있도록 지원하는 정말 매력적인 제도들이죠. 물론 저희 페이타랩에도 개발자들이 성장을 멈추지 않도록 돕는 다양한 제도와 문화가 있습니다.

하지만 이 글에서는 겉으로 드러나는 화려한 제도적 장치들을 넘어 저희 팀의 일상에 공기처럼 스며들어 있는 진짜 문화에 대해 이야기해 보고자 합니다.

회사의 문화를 소개하는 일은 사실 조금 부담이 되기도 합니다. 하지만 제가 약 3년의 시간 동안 팀원들과 함께 호흡하며 경험한 프로덕트팀의 문화는 분명히 자랑할 만한 가치가 있다고 확신합니다.

지금부터 우리가 어떤 문화 속에서 어떤 가치를 추구하며 프로덕트를 만들어 나가고 있고, 그 속에서 개발자들이 어떤 '진짜 재미'를 느끼며 성장하는지에 대한 저의 솔직한 시각을 공유해 드리겠습니다.

설계 우선주의

혹시 이런 경험 있지 않으신가요? 🤔

“그냥 일단 빠르게 구현합시다”

명확한 설계도 없이 시작된 프로젝트에서 기능이 추가될 때마다 결국 예상치 못한 버그가 터지고,

점점 복잡해지는 코드 속에서 발생한 문제를 정확하게 파악하지 못하여 매번 땜질식 처방을 반복하고,

그렇게 쌓여가는 기술 부채에 허덕이는···

무엇을 만들지, 어떻게 만들지 명확한 그림 없이 시작된 프로젝트는 끝없는 시행착오로 이어집니다.

이런 환경에서의 개발자는 많은 리소스를 투여했음에도 성과를 내지 못하고 오히려 '이 코드를 고치다 다른 부분이 망가지지는 않을까?' 하는 불안감에 시달리게 됩니다. 이는 개발 비효율을 극대화하고 개발자 개개인의 성장과 프로덕트를 만드는 재미까지 앗아가 버리죠.

하지만 저희는 다릅니다.

새로운 기능 개발이나 시스템 개선에 착수하기 전 '설계' 그 자체를 최우선으로 생각합니다. 마치 아름다운 그림을 그리기 전에 스케치와 습작을 반복하듯이, 우리가 만들 소프트웨어의 실제 비즈니스 문제(도메인)를 개발 코드로 옮기기 전에 명확하게 이해하고 그 구조를 단단히 잡는 과정에 집중합니다.

누군가는 말합니다.

"요즘처럼 빠르게 변하는 시장에서 그렇게 설계에만 시간을 쏟다 보면 정작 중요한 타이밍을 놓치게 될 텐데, 완벽한 계획을 세우기보다 일단 빠르게 실행하고 고객의 피드백을 받으며 개선해 나가는 것이 더 현명하지 않나요?"

물론 그럴 수 있습니다. 속도 면에서 뒤처질 수 있다는 우려도 충분히 공감합니다. 하지만 저희가 추구하는 것은 순간적인 속도가 아닌 지속 가능한 속도입니다.

단단한 암반을 다지고 주춧돌을 놓는 과정은 더딜 수밖에 없습니다. 하지만 그 과정이 있기에 10층, 100층 높이의 건물도 흔들림 없이 올릴 수 있습니다.

반면, 제대로 된 기초 공사 없이 모래 위에 빠르게 쌓아 올린 성은 작은 파도에도 쉽게 무너져 버립니다. 무너진 성을 재건하는 시간과 비용은 처음 기초를 다지는 시간보다 훨씬 큽니다.

'좋은 설계'에는 개발 속도를 늦추는 '당장의 비용'이 아니라, 미래의 예측 불가능한 문제들을 해결하고 더 빠른 확장을 가능하게 하는 가장 '확실한 투자'가 필요합니다. 이 투자를 통해 우리 팀은 밑 빠진 독에 물을 붓는 절망감 대신, 견고한 시스템 위에 새로운 가치를 자신감 있게 쌓아 올리는 성취감을 느낍니다.

이것이 우리가 추구하는 설계 우선주의의 핵심입니다.

복잡한 비즈니스 문제에 직면했을 때, 개발에 바로 착수하기보다는 '우리는 무엇을 만들려고 하는가?'라는 본질적인 질문과 '사용자가 정말 필요로 하는 것은 무엇인가?'라는 질문에 답하기 위해 심도 깊은 고민과 논의를 먼저 진행합니다. 

저희는 이러한 논의를 통해 프로덕트가 풀어야 할 문제를 구체적인 언어로 명확히 정의하고, 사용자 시나리오를 그려나가며 비즈니스 영역의 핵심 용어와 프로세스를 깊이 있게 이해하는 데 집중합니다.

설계 과정을 통해 개발자들은 단순히 기술적인 코드를 구현하는 수준을 넘어 프로덕트에 대한 이해도를 비약적으로 높이고 제대로 된 프로덕트를 만들고 있다는 강한 몰입을 경험할 수 있습니다.

이러한 체계적인 설계 과정은 발생 가능한 리스크를 사전에 최소화하여 개발 기간을 단축할 수 있도록 하며, 확장성 있고 유지 보수하기 좋은 견고한 프로덕트를 만드는 핵심 기반이 됩니다. 개발자들은 이러한 설계 우선주의라는 탄탄한 문화적 기반 위에서 오직 가치 있는 코드를 만드는 데만 집중하며 개발 본연의 재미를 온전히 느낄 수 있습니다.

Deep Dive into 'Why'

Why의 중요성은 이제는 정말 많은 회사와 조직에서 강조하고 있죠.

프로덕트의 본질적인 목적과 사용자 가치를 깊이 이해하지 못한 채 단순한 지시 수행자가 된 개발자들은 프로덕트와 함께 성장하는 즐거움보다는 '시키는 대로 코딩하는' 것에 대한 지루함과 무력감을 느끼기 쉽습니다. 그렇게 근본 원인이 해결되지 않은 채 같은 문제가 반복되고 사용자들은 계속 불편함을 겪는 악순환에 빠지게 됩니다.

'왜?'라는 질문 없이 그저 주어진 기능만 구현하고, 발생한 버그는 임시방편으로 해결하는 방식은 페이타랩에서는 있을 수 없습니다. 저희는 앞서 언급한 설계 과정에서부터 시작해 개발, 그리고 트러블슈팅과 시스템 성능 개선에 이르기까지 모든 과정에서 "Why?"라는 질문에 결코 타협하지 않죠.

그렇기 때문에 시스템에 어떤 이슈가 발생했을 때 단순한 문제 해결만을 목표로 하지 않습니다.

'왜 이런 현상이 발생했을까?', '이 문제의 근본적인 원인은 무엇일까?'라는 질문을 멈추지 않고 시스템의 깊은 곳까지 파고듭니다. 이 과정을 통해 표면적인 문제 해결을 넘어 재발 방지를 위한 근본적인 해결책을 찾아내고 시스템 전체의 안정성과 품질을 높이는 데 기여합니다.

실제로 저희 팀은 JVM기반 애플리케이션에서 OutOfMemoryError 문제를 경험한 적이 있습니다. 서비스 메모리가 꾸준히 상승하다가 Health Check 요청조차 응답하지 못하고 종료되는 심각한 장애가 발생한 것이죠. 일단은 서버에 할당된 메모리가 절대적으로 적어서 그런 거라 판단하고 메모리를 더 할당하여 임시 조치를 했습니다. 한동안 문제는 발생하지 않았지만 저희는 이 문제를 그대로 방치하지 않았고, 문제의 근본적인 원인을 추적했습니다.

“왜 메모리 사용량이 지속적으로 증가하지?”

“왜 GC가 정상 동작하는데도 메모리 할당 해제가 되지 않지?”

“왜 특정 API 호출 이후에만 메모리 사용량이 급격히 상승하지?”

수일간 원인을 찾아 헤매다 Heap dump를 확인한 후에야 겨우 원인을 파악할 수 있었습니다. 특정 API에서 실행되는 쿼리의 IN 절에 많은 파라미터가 포함될 때마다 새로운 QueryPlanCache가 생성되고 이 객체들이 메모리를 과도하게 점유함에 따라 지속적으로 메모리가 증가하여 결국엔 시스템 전체를 마비시키고 있었던 것입니다.

마찬가지로 원인을 파악한 이후, 문제를 해결하기 위한 방법을 고민하기 시작했습니다. QueryPlanCache가 많은 메모리를 점유하는 것이 문제이다 보니, 단순히 생각했다면 이 QueryPlanCache 개수를 줄이는 방식으로 문제를 해결할 수도 있었겠죠.

🤔 “QueryPlanCache가 많이 생기지 않도록 할 수는 없을까?”

JPA의 in_clause_parameter_padding 옵션을 적용해 캐시 효율을 높여보려 했지만, 실제 운영 데이터에서는 파라미터 수가 너무 많아 JDBC 드라이버의 IN절 파라미터 수 한계를 초과하며 오히려 에러가 발생했습니다.

🤔 “QueryPlanCache의 수를 제한하면 되지 않을까?”

이후에는 QueryPlanCache의 개수를 제한해 메모리 점유를 줄여 해결을 시도했고 에러는 더 이상 발생하지 않았지만, 캐시 히트율 저하로 성능이 저하될 수 있다는 문제가 있었습니다.

🤔 “그렇다면.. IN절 자체를 사용하지 않으면 되지 않을까?”

불필요하게 많은 파라미터가 IN 절에 포함되는 것이 문제이니 IN절을 사용하지 않도록 로직을 변경해 보았고, 더 이상 에러와 성능 문제 모두 발생하지 않았습니다.

🤔 “이번 문제는 해결했는데.. 이런 문제가 또 발생할 수 있지 않을까?”

문제는 해결했지만 같은 문제가 반복될 가능성은 여전히 존재했습니다. 그래서 최종적으로는 해결 시도를 통해 얻은 인사이트들을 모두 반영하여 시스템 안정성을 한층 강화했습니다.

모든 서비스에 in_clause_parameter_padding옵션을 적용하고 QueryPlanCache의 개수도 제한하여, 같은 문제로 인한 과도한 메모리 점유를 차단함으로써 문제의 재발 우려 제거와 더불어 성능 향상까지 꾀한 것이죠.

이 경험의 본질은 단순히 장애를 “해결했다”라는 사실이 아닙니다.

문제를 해결하는 전 과정이 Why에 대한 질문과 답변의 연속이었다는 점이죠. 이 과정을 통해 표면적으로 보았을 때는 결코 알 수 없었던 새로운 인사이트들을 얻을 수 있는 기회가 되었습니다. 그 결과는 단순한 문제 해결을 넘어 프로덕트의 품질 향상으로 이어졌고, 동시에 개발자 개개인에게는 문제의 본질을 끝까지 파고드는 경험으로 한 단계 더 성장할 수 있는 계기가 되었습니다.

이처럼 우리는 Why를 묻는 집요함을 통해 단순히 코드를 작성하는 것을 넘어 전체 시스템을 아우르는 깊이 있는 통찰력과 설계 역량을 기르고, 프로덕트 전반을 깊게 이해하는 데 필수적인 토대를 다집니다. 이렇게 우리 팀은 ‘진짜’ 문제를 ‘제대로’ 해결하는 개발의 즐거움을 경험하고 있습니다.

이 외에도, 저희 프로덕트팀은 개발자로서 시야를 넓힐 수 있는 특별한 경험을 제공합니다. 바로 '멀티 스쿼드' 경험을 통해서 말이죠.

Multi Squad

규모가 어느 정도 있는 회사에서 백엔드 개발자는 하나의 도메인에서 깊이 있는 역량을 쌓게 됩니다. 물론 이러한 경험을 통해 특정 도메인의 전문가로 성장하는 것 또한 중요한 가치 중 하나입니다. 특정 영역에 대한 깊이 있는 이해와 전문성은 그 자체로 큰 자산이 될 수 있으니까요.

하지만 저는 생각이 조금 다릅니다. 특정 도메인에 대한 이해도는 높아질 수 있겠지만, 자신이 만든 기능이 프로덕트 전체에서 어떤 역할을 하고 다른 도메인들과 어떻게 유기적으로 연결되어 사용자 경험을 완성하는지 큰 그림을 온전히 파악하기는 제한적일 수 있습니다. 이는 ‘내 손으로 이 모든 것을 만들고 있다’는 몰입감과 주인의식을 느끼지 못하게 할 수 있습니다. 개발자로서 하나의 완성된 작품을 만들어간다는 성취감 또한 폭넓은 이해와 연결될 때 더 커질 수 있겠죠.

페이타랩의 개발자들은 다양한 스쿼드에 유연하게 참여하며 여러 도메인과 비즈니스 로직을 직접 경험할 기회를 얻습니다.

1. 유연하고 폭넓은 기술 스택

   각 스쿼드마다 특성에 따라 다른 아키텍처 패턴, 라이브러리, 또는 최적화 기술이 적용될 수 있습니다.

   개발자들은 새로운 스쿼드에 참여하며 이러한 다양한 기술적 접근 방식에 노출되기에 실제 문제 해결 과정에서 새로운 기술을 학습하고 적용하는 기회를 얻습니다. 단순히 코드를 짜는 것을 넘어 '이 비즈니스 문제를 해결하기 위해 어떤 기술적 선택이 최적일까?'를 고민하는 안목과 역량을 키울 수 있게 되는 것이죠.

2. 고도화되는 문제 해결 능력

   여러 도메인을 넘나들며 시스템 간의 상호작용을 직접 경험하게 되면 특정 스쿼드에 국한되지 않는, 시스템 전체 관점에서 문제의 원인을 파악하고 해결하는 능력이 강화됩니다. 버그가 발생했을 때 어디서부터 찾아봐야 할지, 시스템 확장이 필요할 때 어떤 부분을 고려해야 할지 등 통합적인 사고가 가능해집니다.

3. 다차원적인 프로덕트 이해

   하나의 스쿼드에서는 미처 보지 못했던 다른 스쿼드의 비즈니스 목표, 사용자 여정, 그리고 기술적 특징을 직접 경험하게 됩니다.

예를 들어, 주문 도메인에서 일하던 개발자가 정산 도메인 스쿼드로 이동할 경우 주문 데이터가 정산 시스템에서 어떻게 처리되고 어떤 비즈니스 규칙과 연결되는지를 배웁니다. 이는 '내가 만드는 코드가 프로덕트 전체의 어느 부분에 영향을 미치고 어떤 가치를 창출하는가'에 대해 깊이 있게 깨닫게 되며, 개발자는 단순히 주어진 기능 구현을 넘어 프로덕트 전반의 흐름을 읽을 수 있는 시야를 가질 수 있습니다.

그 결과, 단순히 주문 기능 개발에 그치지 않고 주문 정책 변경이 정산 시스템의 복잡도나 잠재적 오류를 유발할 수 있음을 예측하여 사전 논의 과정에서 더 효율적인 설계 방안을 제안하는 등 더 적극적으로 의견을 제시하게 됩니다. 이러한 과정은 프로덕트 전반에 대한 이해도를 확장시킬 뿐만 아니라, 개인의 성장을 넘어 팀의 중요한 의사결정에 기여합니다.

이러한 멀티 스쿼드 경험은 다양한 환경에서의 문제 해결 능력을 기르고, 넓은 기술 스택을 경험해 볼 수 있는 기회를 통해 전체 시스템을 고려한 설계 역량을 발전시킬 수 있도록 돕습니다.

매 스쿼드마다 새로운 도전에 직면하며 성장하는 과정에서 우리는 끊임없이 스스로의 한계를 뛰어넘고 더 나은 개발자가 되어갑니다.

실제로 저는 3년간 근무하면서 14개의 스쿼드에 참여하여 프로젝트를 진행했고 페이타랩 시스템을 구성하는 대부분의 도메인을 경험하며 프로덕트 전문가가 되었다고 자부할 수 있습니다.

세 가지 문화의 시너지

설계 우선주의, Why에 대한 Deep Dive, 그리고 멀티 스쿼드 경험은 페이타랩 프로덕트팀이 가진 핵심 문화의 축이자 개발자들의 성장을 이끄는 강력한 동력이라고 생각합니다.

이 세 가지 문화가 유기적으로 결합될 때, 저희 팀원들은 그 어떤 화려한 제도나 문화보다도 강력한 동기를 얻으며 프로덕트를 '직접' 만들어 나가는 진정한 재미를 경험합니다.

우리는 깊이 있는 설계 과정을 통해 문제의 본질을 완벽하게 이해하고 Why라는 질문을 멈추지 않으며 근본적인 해결책을 찾아냅니다. 여기에 다양한 스쿼드 경험을 통해 하나의 도메인을 넘어 전체 프로덕트의 복잡한 연결 고리를 파악하며 프로덕트 레벨에서의 새로운 인사이트를 얻고 내 코드가 프로덕트와 비즈니스에 어떤 영향을 미치는지 명확히 인지하게 되죠.

이러한 문화 속에서 높은 수준의 기술적 완성도를 추구하고 사용자와 점주에게 실질적인 가치를 제공하며 우리 팀의 프로덕트가 어떻게 시장의 혁신을 이끌어가는지 생생하게 목격하고 있습니다.

내 손으로 프로덕트를 만든다는 것

만약 여러분이 코드를 넘어 비즈니스와 도메인을 깊게 이해하고 싶은 개발자라면,

그리고 프로덕트의 성장에 진정으로 기여하며 '나의 것'을 만들어가는 즐거움을 느끼고 싶은 분이라면,

우리의 문화 이야기를 엿보며 가슴이 뛰었다면!

페이타랩 프로덕트팀에서의 경험은 그 어떤 화려한 제도보다 큰 만족감을 선사할 것이라고 자신 있게 말씀드리고 싶습니다.

페이타랩의 문은 언제나 열려 있습니다. 우리는 끊임없이 배우고, 도전하며, 함께 성장할 동료를 기다리고 있습니다.

패스오더를 통해 시장의 혁신을 이끌어갈 이 곳에서, 당신의 역량을 마음껏 펼치고 진짜 재미를 함께 만들어갈 기회를 잡으세요.

당신의 합류를 진심으로 환영합니다.

Written by.

"진짜" 개발자로 거듭나고 싶다면?