Petnow Careers Interview

YoungTech Lead

복잡한 AI 제품을 안정적으로 빠르게 배포하는 방식

Young과의 대화는 펫나우의 앱, SDK, Web, Admin Console, AI 연구 환경을 하나의 제품 경험으로 안정적으로 연결하는 기술 리드의 역할을 보여줍니다. 빠르게 만들면서도 테스트 가능성과 관찰 가능성을 잃지 않는 기준을 확인할 수 있습니다.

앱, SDK, Web, 운영 도구가 함께 움직이는 구조에서 테스트 가능성과 개발 효율을 어떻게 높이는지 다룹니다.

Q01

펫나우에서 Tech Lead는 어떤 역할인가요?

제가 하는 일을 세 가지로 나누면, 첫 번째로 제품 전반의 기술 방향을 잡는 거예요. 저희 기술은 펫나우 앱뿐만 아니라 B2B 고객에게 SDK와 API로 배포되기도 하니까, 제품 안정성이 최우선이죠. 설계 단계에서 방향을 잘못 잡으면 저희 앱과 고객사 양쪽 모두에게 영향을 줘서, 기술 선택 및 아키텍처 결정에 신중을 기합니다. 두 번째로 팀원들이 업무에 집중할 수 있도록 개발 효율성을 높이는 인프라를 구축하는 일을 합니다. CI/CD 파이프라인부터 공통 프레임워크, 테스트 자동화, Tech Talk 세션 진행에 이르기까지 팀원들이 반복 작업에 시간을 낭비하지 않고 실제 기능 개발에 에너지를 쏟을 수 있도록 환경을 만들어 나갑니다. 세 번째로 시스템 설계에 참여해서 안정성, 테스트 가능성, 관찰 가능성을 높이는 방향으로 결정을 내립니다. 어떤 기술이나 구조를 쓸지 논의할 때 항상 "이걸 나중에 테스트할 수 있을까?", "문제가 생겼을 때 어디서 일어났는지 추적할 수 있을까?"라는 질문을 던지면서 설계에 참여합니다. 물론 직접 개발에 참여하기도 합니다. iOS/Android/Web 같은 프론트부터 서버 개발, AI 연구에도 직접 참여해 코드를 작성합니다. 회사 외부로 공개되는 개발 문서 작업도 진행합니다. 최근에는 회사 내에서 어떻게 하면 생성형 AI를 이용해서 "같은 시간 동안 일하고 더 많이 이룰 수 있을지"를 고민하고 있습니다.

Q02

제품 개발에 있어 가장 중요하게 보는 기준은 무엇인가요?

사용자가 복잡한 기술을 전혀 느끼지 않도록 하는 게 가장 중요해요. 사용자는 단순히 카메라를 켜는 것만으로 반려동물 등록이 완료되는 경험을 원하죠. 실제로는 실시간 AI 모델 추론, 이미지 품질 판단, 네트워크 통신 등 여러 복잡한 과정이 동시에 일어나요. 저희는 그 기술적 복잡성을 최대한 고객에게 노출하지 않으려 노력합니다. 또 신규 스펙이 빠르게 추가되어야 하는 상황이 자주 발생하는데, 그런 와중에 안정성까지 챙기려면 관찰 가능성을 높이는 게 필수적입니다. 로그, 메트릭, 트레이싱이 뒷받침되어야 문제가 어디서 발생했는지 빠르게 판단할 수 있고, 그래야 다시 다음 기능을 빠르게 만들 수 있죠. 결국 관찰 가능성이 뒷받침될 때 비로소 빠른 생산성이 나오는 거예요.

Q03

펫나우 제품의 안정성을 높이기 위해 가장 집중해온 부분은 무엇인가요?

저는 펫나우 앱, SDK, Web 등 전체 제품군이 일관되게 안정적으로 작동하도록 테스트 자동화와 CI 파이프라인을 주로 구축해 왔어요. 사람 수작업으로 모든 변경사항을 확인하는 것은 한계가 있기 때문에, 코드가 수정될 때마다 자동으로 테스트가 돌아가고 문제가 발견되면 배포가 막히도록 CI/CD를 강화했습니다. 또한 다양한 기기와 OS 환경에서 안정적으로 동작하는지 확인하기 위해 Firebase Test Lab, AWS Device Farm 같은 클라우드 기반 테스트를 도입했어요. 100개가 넘는 실제 기기에서 호환성 테스트를 돌리면서, 특정 기기에서만 발생하는 버그를 사전에 찾아내 해결하고 있어요. 결국 사람이 놓칠 수 있는 부분을 자동화된 프로세스와 도구로 채워나가는 데 가장 많은 노력을 기울였다고 할 수 있겠습니다.

Q04

개발 효율성을 높이기 위해 어떤 구조를 만들어가고 있나요?

전 분야 공통적으로, CI/CD 자동화 파이프라인을 구축해 사람의 손을 거치는 작업을 최소화했습니다. 개발 시에는 사내 서버를 이용해 테스트를 수행합니다. 파트별로 말씀드리자면, 먼저 React와 React Native, 모바일(iOS/Android) 쪽에서는 펫나우만의 하나의 디자인 시스템을 공유하고 있습니다. 그리고 이걸 MCP(Model Context Protocol)로 연동해서 LLM 기반 개발을 진행하고 있어요. 디자인 시스템이 MCP로 구조화되어 있으면 AI가 개발 맥락을 더 잘 이해하고 정확한 코드를 생성할 수 있거든요. AI 연구 측면에서는 모델을 테스트하기 위해 매번 작성해야 하는 반복적인 코드를 줄이는 구조를 만들고 있어요. 모델과 데이터를 DVC나 MLflow 같은 registry 방식의 중앙집중화를 통해 관리하니, 파편화된 데이터나 모델을 찾는 데 쓰던 시간이 줄었고 실험 결과의 재현성과 정합성도 높아졌어요. 백엔드와 인프라는 모노레포와 Terraform을 활용해서 효율을 높이고 있어요. 모노레포로 서비스 간 코드 공유와 변경사항 추적이 쉬워졌고, Terraform으로 인프라를 코드로 관리하니 환경 배포의 재현성이 보장되고 온보딩 시간도 크게 줄었어요.

Q05

테스트 가능성을 높이는 것이 왜 중요한가요?

저희가 만드는 제품 구조는 앱, AI 모델, 이미지 로직, SDK, Web, 운영 도구가 서로 얽혀 있는데, 한 군데를 고쳤을 때 다른 쪽에 어떤 영향을 미치는지 사람이 다 확인할 수는 없어요. 인력도 제한적이고요. 특히 B2B 고객사가 SDK를 연동할 때 안정적인 동작이 보장되지 않으면 신뢰를 쌓기 어렵죠. 그리고 요즘 AI 기반 코드 생성이 보편화되면서, AI가 쓴 코드의 정확성을 검증하는 테스트 자동화의 필요성이 더 커졌어요. Chat → Action → Test 흐름대로, AI의 잠재력을 온전히 쓰려면 검증 단계를 자동화하는 게 필수이고, 이 과정에서 테스트 가능성을 높이는 것은 더 이상 선택이 아니게 되었죠.

Q06

초기 제품과 비교했을 때 지금 가장 크게 달라진 기술적 변화는 무엇인가요?

초기엔 펫나우 모바일 앱만 관리하면 됐지만, 지금은 앱, Petify SaaS, iOS/Android/Web SDK, Admin Console 등 여러 제품이 함께 작동해요. 그런데 단순히 제품 수가 늘어난 것보다 더 큰 변화는 고객과 파트너가 많아지면서 안정성에 대한 요구가 훨씬 커졌다는 점이에요. 처음엔 펫나우 앱 사용자들만 신경 쓰면 됐지만, 지금은 B2B 고객사가 SDK를 연동해서 고객사 측 사용자에게 전달하는 구조잖아요. 그래서 한 곳에서 발생한 버그가 훨씬 많은 곳에 영향을 미칠 수 있어요. 이런 변화에 맞춰 테스트 가능성과 관찰 가능성을 구조 자체에 녹이는 작업을 해왔어요. CI/CD 파이프라인, 자동 테스트, 호환성 테스트, 모니터링을 제품 개발의 필수 단계로 만들었죠. 단순히 기능을 빠르게 만드는 것뿐만 아니라, 변경이 안정적으로 전달될 수 있도록 하는 게 지금의 가장 큰 기술적 변화라고 생각해요.

Q07

그 변화 과정에서 가장 어려웠던 기술적 전환점은 무엇이었나요?

기존 레거시 로직을 새로운 구조로 리팩토링해야 했던 작업들이 가장 어려웠어요. 클라이언트, SDK, 서버까지 전부 오랜 기간 쌓인 레거시가 있었는데, 단순히 고치는 수준을 넘어 구조 자체를 제대로 설계해야 했거든요. 문제는 레거시를 건드리는 순간 기존에 잘 돌아가던 기능이 망가질 수 있다는 거예요. 그게 가능해진 건 위에서 말씀드린 테스트 자동화랑 CI/CD가 있었기 때문이에요. 리팩토링 전후로 테스트가 자동으로 돌면서 회귀(Regression)가 발생했는지 바로 파악할 수 있었고, CI 파이프라인이 변경사항을 빠르게 검증해줬죠. 테스트 커버리지와 CI가 없었다면 레거시 리팩토링을 이렇게 무리 없이 진행하기 어려웠을 거예요.

Q08

앱, AI, SDK, Web, 운영 도구가 함께 움직이는 제품에서 엔지니어가 놓치기 쉬운 지점은 무엇인가요?

개발에 집중하다 보면 기능은 제대로 구현되었지만 사용성에 대한 고려를 놓치는 경우가 많아요. 예를 들어 SDK의 성능은 좋지만 촬영 가이드가 직관적이지 않아 사용자가 사용에 어려움을 느끼거나, SDK 연동은 됐지만 에러 메시지가 너무 기술적이어서 B2B 고객이 당황하는 경우죠. 기술적으로 완벽해도 사용자가 불편하면 의미가 없죠. 저는 클라이언트 개발 경험을 10년 넘게 가지고 있기 때문에 이런 부분을 비교적 잘 파악하고 지적할 수 있는 편이에요. 기능 구현이 끝난 이후 "사용자가 실제로 어떻게 느낄까?"라는 시야를 하나 더 넣는 게 중요하다고 생각해요. 팀원들이 개발에 집중할 때 제가 그 빈 공간을 채워주는 역할을 한다고 봐요.

Q09

펫나우에서 좋은 엔지니어링이란?

사용자가 기술의 복잡함을 느끼지 못하도록 만드는 거예요. 모든 게 배경에서 조용하게 돌아가고, 사용자는 그냥 카메라를 켜면 되는 게 저희가 만들고자 하는 경험이에요. 그리고 그런 경험을 확장 가능한 구조로 만들어야 해요. 펫나우 앱, B2B SDK, Web SDK가 함께 작동하고, 새로운 제품이나 파트너가 들어왔을 때 최소한의 변경으로 대응할 수 있는 기반이 중요하죠. 또 CI/CD, 테스트 자동화, Sentry 모니터링 같은 프로세스에 녹여 개개인에 의존하지 않는 안정성을 확보하는 게 좋은 엔지니어링이라고 생각합니다.

Q10

지금 펫나우에는 어떤 엔지니어가 가장 필요하다고 보나요?

지금 펫나우에 가장 필요한 엔지니어는 제품의 맥락을 잘 이해하고, 안정성과 개발 효율성을 함께 높여나갈 수 있는 분이에요. 단순히 기능이 동작하는지 확인하는 것을 넘어서, 우리가 왜 이 기능을 만들고 있는지, 고객이 어떻게 쓰는지 알고 있으면 자연히 안정적이고 확장 가능한 구조를 고민하게 되거든요. 또한 아무리 작은 기능도 운영 가능한 구조 안에서 끝까지 책임지는 마인드가 중요해요. 코드를 짠 것이 끝이 아니라, 테스트는 잘 되는지, 문서화는 되어 있는지, 운영에서 문제가 생겨도 추적하고 고칠 수 있는지까지 생각하며 마무리해야 하죠. 특정 영역에 치우치지 않고 전체 흐름을 바라보면서 제품의 품질을 함께 만들어갈 수 있는 엔지니어를 원해요.