코드를 넘어 비즈니스를 봅니다.

올웨이즈의 성장을 지탱하는 핵심 동력 중 하나는 광고 시스템입니다.

SDK 연동부터 수익 지표 개선까지, 광고 시스템의 프론트엔드 영역을 책임지고 있는 박수연님을 만나 치열한 환경에서 엔지니어가 성장하는 법에 대해 이야기를 나누었습니다.

수연님 안녕하세요, 자기소개 부탁드립니다.

안녕하세요, 올애즈팀 프론트엔드 엔지니어 박수연입니다. 저는 광고 SDK 연동부터 수익 지표 개선까지, 올웨이즈 광고 서비스의 프론트엔드 영역을 담당하고 있어요. 단순히 UI를 그리는 것을 넘어, 광고의 안정성과 수익성을 동시에 확보할 수 있는 기술적 기반을 다집니다. 고객 경험과 이익 창출 사이에서 팀이 더 빠르고 과감하게 실험할 수 있도록 튼튼한 서포트 시스템을 만드는 것이 목표입니다.

다소 안정적이었던 이전 직장과는 다른 환경인 레브잇을 선택하셨는데 어떤 이유였나요?

편한 곳보다는 '내가 진짜 성장하고 있는지'를 확인할 수 있는 곳이 필요했어요. 연차가 쌓이면 익숙한 패턴대로 일하게 되는데, 저는 그 익숙함이 정체처럼 느껴져서 무서웠거든요.

레브잇은 목표가 높고 속도가 압도적이라 제가 직접 판단하고 움직여야 하는 상황이 끊임없이 발생해요. 처음엔 정말 힘들었지만, 그만큼 제가 달라졌다는 걸 매일 체감하고 있어 후회는 없습니다.

외부에서 보던 레브잇과 실제 합류 후 느낀 개발 문화의 차이가 있다면요?

입사 전에는 "개발자가 아니어도 개발을 할 수 있는 곳"이라는 이미지가 강했어요. 실제로 와보니 그 말은 반은 맞고 반은 틀리더라고요.

가장 충격적이었던 건, 클린코드 책에서 '나쁜 예'로 등장할 법한 코드들이 곳곳에 포진해 있었다는 점이에요(웃음). 처음엔 엔지니어로서 당황스러웠죠. 그런데 시간이 지나면서 생각이 완전히 바뀌었습니다. 그 '나쁜 코드'들이 매달 수억 원의 수익을 창출하고 있었고, 비즈니스의 가파른 성장을 실시간으로 견인하고 있었거든요.

그때 처음으로 체감했어요. '나쁜 코드'라는 기준은 생각보다 훨씬 맥락 의존적이라는걸요. 기술적 결함이 있어 보여도 비즈니스 타이밍을 적중시켜 생존을 증명해낸 코드라면, 그 시점에는 '최선의 코드'였을지도 모른다는 거죠. 물론 이후에 "아, 이래서 이런 구조는 피해야 했구나"라며 몸소 고생하며 배운 코드들도 많고요.

비즈니스를 성공시키는 코드의 힘과 유지 보수를 위해 지켜야 할 원칙의 소중함, 이 양극단의 경험을 동시에 할 수 있는 곳은 정말 흔치 않을 거예요. 레브잇은 엔지니어에게 '무엇이 진짜 우선순위인가'를 가장 치열하게 고민하게 만드는 곳입니다.

프론트엔드 엔지니어로서 해결해야 했던 가장 난이도 높은 기술적 문제는 무엇이었나요?

AppLovin 광고 로드 실패 이슈가 가장 기억에 남아요. 유저 리포트를 통해 처음 인지했는데, 간헐적으로 발생하는 문제라 재현 자체가 불가능했거든요. 앱과 웹 사이의 복잡한 상태를 다뤄야 하는 구조인 데다, 외부 SDK 특성상 내부 흐름을 완전히 파악하기 어려운 상황이었죠.

그래서 단순히 코드 수정에 그치지 않고, 로그를 촘촘히 쌓으며 관찰 가능한 구조를 만드는 작업부터 다시 시작했습니다. 광고 유형별로 로딩 상태 관리를 세분화하고, 실패 시 유저가 직접 재시도할 수 있도록 UX도 개선했어요.

우선 특정 진입점 하나에만 적용해 데이터로 안정성을 검증했는데, 유저들이 광고를 정상 시청하고 보상까지 잘 챙겨가는 것을 확인했습니다. 덕분에 확신을 갖고 이번 주에 서비스 전체로 기능을 확장할 수 있었죠. 로그를 통해 유저가 막히는 지점을 명확히 파악하게 되면서, 외부 SDK 연동 시 구현과 동시에 모니터링 체계를 구축하는 것이 저만의 확고한 원칙이 되었습니다.

빠른 배포 VS 유지 보수성과 유저 경험, 이 사이에서 어떻게 균형을 잡으며 속도를 내고 계신가요?

저는 한 번에 한 가지 문제를 뾰족하게 해결하는 방식을 선호해요. 큰 덩어리로 묶어 한꺼번에 배포하기보다, 작게 쪼개서 여러 번 배포하는 것이 결국 훨씬 안전하고 빠르다고 믿거든요.

최근에는 AI를 워크플로우에 적극적으로 활용하고 있어요. 단순히 코드 한 줄을 묻는 게 아니라, 전체 맥락을 공유하고 최종 목표를 설명한 뒤 코드를 짜게 하는 방식이죠. 덕분에 일주일 정도 걸릴 것으로 예상했던 작업을 단 하루 만에 끝낸 적도 있어요. 오히려 AI의 생산 속도가 너무 빨라 제가 최종 테스트와 코드 검토를 따라가는 데 병목이 생길 정도였죠. 속도를 내는 방식 자체가 완전히 바뀌고 있다는 걸 느낍니다.

유저 경험에 대한 고민은 개발 과정에서 자연스럽게 녹여내요. 직접 코드를 짜며 느껴지는 개선점들을 PO와 실시간으로 소통하며 즉각 반영합니다. 빠르게 할 수 있으면서도 임팩트가 크다는 판단이 서면, 작업 중간에 바로 추가해요. 개선을 위해 따로 시간을 내기보다, 개발 흐름 속에서 유연하게 반영하는 것이 훨씬 자연스럽고 효율적이라고 생각합니다.

개발 과정에서 PO와 실시간으로 소통하며 UX를 개선하신다고 했는데, 혹시 지표를 올리기 위해 직접 설계를 제안해 성과를 낸 구체적인 사례도 있을까요?

보물찾기 기능 개선이 대표적이에요. 보물찾기는 CTA 버튼을 클릭하며 올팜 재화를 받는 기능인데, 일반 피드 사이에 광고 피드를 끼워 CTR을 높이는 구조였어요. "안드로이드에서 광고 피드 터치가 한 번에 안 되는 버그"를 해결해달라는 요청을 받았는데, 자세히 들여다보니 더 손봐야 할 문제들이 보였어요.

우선 광고 터치 지연 문제의 경우, 광고가 미리 로드되지 않아 바인딩에 시간이 걸리고 스크롤할 때마다 다시 로드해야 하는 구조가 원인이었어요. 이를 해결하기 위해 광고 피드를 Overlay로 분리해 일반 피드처럼 애니메이션이 동작하게 설계했고, 결과적으로 피드와 같은 UX로 한 번에 터치되도록 개선했어요.

여기에 유저가 광고 위치를 예측해 피하기 쉽다는 점을 포착해 랜덤 간격 노출을 제안했고, 광고를 불필요하게 많이 요청하던 메모리 누수 문제도 미리 3개만 로드해 재활용하고 적절히 destroy하도록 수정했습니다.

이러한 개선 방향을 PO 분께 직접 제안해 실행했고, 결과적으로 월 수익이 3배 이상 성장하는 성과를 얻었습니다.

의사결정을 내릴 때 가장 중요하게 생각하는 원칙은 무엇인가요?

"이게 지금 가장 큰 문제인가?"를 스스로 묻습니다. 좋아 보이는 것과 지금 해야 하는 것을 구분하는 게 핵심이죠. 저는 지표 임팩트, 복구 가능성, 다음 작업에 미치는 영향이라는 세 가지 기준으로 우선순위를 정합니다.

또, "이 결정이 나중에 팀에게 부채를 남기는가?"도 고려해요. 혼자 올애즈 스쿼드의 프론트엔드를 담당하고 있어, 내가 만든 코드가 미래의 나 혹은 새로 합류하는 엔지니어의 속도를 얼마나 늦추는지를 항상 의식하게 됐어요.

동료(PO, 엔지니어)들과 소통할 때 수연님만의 원칙이 있다면요?

기술적 맥락을 상대방의 언어로 번역하는 것입니다. 비개발 직군에게는 개발 상황을 통번역 해 주어 오해를 줄이고, 엔지니어와 협업할 때는 PR에 비즈니스 맥락을 상세히 적습니다. 광고 도메인은 코드만 봐서는 의도를 파악하기 어렵거든요. '왜 이렇게 짰는지'를 알아야 더 본질적인 리뷰가 오갈 수 있고, 나중에 다른 사람이 봐도 맥락을 잃지 않을 수 있습니다. 이 연결이 잘 될수록 팀이 더욱 빠르게 움직일 수 있다고 생각해요.

1~2년 전의 나와 비교했을 때, 가장 레벨업 되었다고 느끼는 지점은 어디인가요?

레브잇에 와서 앱 개발을 처음 시작했는데 10억 넘는 매출이 걸린 코드를 수정해야 했던 때가 있었어요.

그때 제가 스스로 잘했다고 생각하는 건, 겁을 먹기보다 지표로 즉시 확인하고 문제가 생기면 바로 롤백할 수 있는 구조를 먼저 구축한 것이었어요. 안전장치를 먼저 만드니 배포가 두렵지 않았고, 해결 여부가 데이터로 바로 증명되니 다음 문제에도 훨씬 빠르게 집중할 수 있었거든요.

기술적으로는 광고 네트워크의 복잡한 구조와 외부 SDK 설계에 대한 이해가 정말 깊어졌습니다. 이제는 새로운 네트워크를 연동할 때 어디서 병목이 생길지 미리 보일 정도예요.

무엇보다 가장 큰 변화는 일에 대한 정의가 바뀌었다는 점입니다. 단순히 코드를 짜는 것을 넘어, 내가 만든 결과물로 인해 지표가 실제로 움직여야 비로소 일이 끝난 것이라고 생각하게 되었습니다.

어떤 프론트엔드 개발자가 레브잇에 합류하면 좋을까요?

'내가 지금 해결해야 하는 진짜 문제가 무엇인지'를 명확히 정의할 줄 아는 분이 잘 맞을 것 같아요. 문제의 본질을 정확히 알아야 불필요한 곳에 힘을 빼지 않고, 정말 집중해야 할 핵심에 에너지를 쏟을 수 있거든요.

물론 구현을 잘하는 것은 엔지니어로서 기본입니다. 하지만 저는 그 위에 한 층 더 쌓여 있는 고민을 함께하고 싶어요. '내 코드가 유저에게 어떤 실질적인 영향을 주는지', '비즈니스 지표를 어떻게 움직이는지'를 데이터로 같이 들여다볼 수 있는 분이라면 최고의 동료가 될 수 있을 거라 확신합니다.

마지막으로, 레브잇 엔지니어로서 남기고 싶은 발자취가 있다면 무엇인가요?

우선 제가 지금까지 쌓아온 광고 도메인 지식과 복잡한 코드의 맥락들을 체계화해서, 팀 전체의 강력한 자산으로 만들고 싶어요.

기술적으로는 한 단계 더 나아간 구상을 하고 있습니다. AI 에이전트를 활용해 광고 SDK 연동 지식과 우리만의 코드 베이스 설계를 학습 시키는 것이죠. 이를 통해 이슈가 발생했을 때 진단부터 수정 PR 제출까지 시스템이 자율적으로 처리할 수 있는 환경을 만들고 싶어요.

엔지니어로서 제가 생각하는 진짜 임팩트는 제가 밤을 새워 문제를 해결하는 것이 아니라고 생각해요. 장기적으로는 '나 없이도 완벽하게 돌아가는 구조'를 설계하는 것, 그것이 팀과 회사에 남길 수 있는 가장 거대한 기술적 발자취가 아닐까 싶습니다.