좋은 개발자는 코드보다 문화를 남긴다
- 진우 정
- 10월 27일
- 6분 분량
최종 수정일: 10월 27일
안녕하세요, 은석님. 은석님의 소개를 부탁드려요.
안녕하세요. 저는 핀다의 VP of Engineering을 맡고 있는 김은석이라고 합니다.
저는 약 20년에 걸쳐 한화 S&C, 신세계 I&C, 쿠팡, NHN, 야놀자 등에서 테크 기반 경력을 갖고 있는 그야말로 개발자입니다. 저를 한 마디로 정의하자면, 일을 할 때는 물론이고 일상에서도 상식적이고도 일관된 사람이라고 생각합니다. 상식적인 기준과 일관적인 태도로 구성원들이 성장할 수 있는 환경을 만들고, 이를 통해 테크 조직과 회사 전체를 성장시키는 방향으로 이끌어가고 있습니다.
핀다에 와서 동료들에게 가장 많이 하는 말은 ‘함께 일하고 싶은 사람이 되면 좋겠다’예요. 개발 성과만으로 인정받을 수 있다고 생각하는 개발자도 있지만, 실제로는 단순히 개발만 잘한다고 해서 함께 일하기 좋은 사람이라고 할 수는 없습니다. 협업이 어렵다면 누구도 함께 일하고 싶어하지 않죠.
그래서 저는 개발 역량뿐 아니라 조직의 구성원으로서 필요한 다양한 역량을 균형 있게 갖추는 것이 중요하다고 생각합니다. 그렇게 할 때 더 큰 시너지를 낼 수 있고, 그 결과가 상식적이고 합리적인 평가로 이어진다면 결국 본인과 회사 모두에게 분명한 동기부여가 된다고 생각합니다.
대기업에서 스타트업으로 넘어오신 뒤로 꾸준히 플랫폼 서비스를 개발해오셨네요. 그 이유가 궁금합니다. 또, 플랫폼 서비스를 만드는 과정에서 어려움을 이겨내는 비결이 있다면 무엇일까요?
네 맞아요. 저는 대기업부터 스타트업까지 여러 회사를 거쳐왔습니다. 특히 플랫폼 서비스 회사에 매력을 느껴 이 산업군에서 경력을 키워가고 있는데요, 플랫폼을 통해 사용자들이 겪는 불편함을 해결하는 과정에서 새로운 가치를 만들어낼 수 있다는 점이 매력적이었어요. 우리가 만들어낸 새로운 가치를 고객에게 빠르게 평가받을 수도 있고요.
이러한 가치를 만들어가는 과정에서 프로젝트에 참여하는 모든 구성원들이 고객의 문제를 명확히 이해하고 공통의 목적 의식 하에 우리 플랫폼이 필요하게 만들어가는 것이 중요하죠.
제가 플랫폼 서비스를 좋아하지만, 운영·개발·고도화 측면에서 어려움도 분명히 있습니다. 그중 대표적인 것이 바로 ‘기술 부채’라는 함축적인 단어로 표현될 수 있을 것 같습니다. 저에게 기술 부채는 한편으로는 부담이지만, 동시에 아주 흥미로운 요소이기도 합니다.
기술 부채가 제대로 관리되지 않으면 프로덕트의 고도화와 함께 그 규모도 커지면서 결국 악순환에 빠지게 되죠. 이럴 때면 “정말 귀신 같다”는 생각이 듭니다. 과거의 의사결정이 마치 지금 와서 “언제 갚을 거야?” 하고 계속 물어보는 느낌이거든요. (웃음)
또 한 가지 흥미로운 점은 성장과 성취의 관점입니다. 프로덕트 과제를 통해 성장하는 것도 즐겁지만, 기술 부채를 하나씩 풀어내며 얻는 배움과 성취감은 또 다른 매력이 있습니다. 이런 경험은 개발자의 자존감을 높이고, 확신을 가지고 동료들을 설득하거나 리딩할 때에도 긍정적인 영향을 줍니다.
그래서 저는 기술적 의사결정을 내릴 때 항상 효율성과 장기적인 비용 관점과 성장 요소 등을 함께 고려하고 있으며 핀다에서도 기술 부채로 인한 스트레스를 흥미로움으로 전환해, 그것을 우리 모두의 성장의 발판으로 삼으며 하나씩 해소해 나가고 있습니다.
기술부채는 사실 눈에 잘 보이지 않아서, 신경을 쓰고 있지 않으면 놓치게 마련인 것 같습니다. 은석님만의 노하우가 있다면요?
노하우까진 아니고, 개인적인 성정이 좀 숫자에 민감하고 눈에 거슬리는 게 있으면 못 넘기는 편이라서 그런 것 같습니다. (웃음) 당장 해결할 순 없겠지만 Backlog로 체계적으로 관리하면서, 작은 단위의 phase로 나누어 기회가 될 때마다 혹은 직접 기회를 만들어서 조금씩이라도 꾸준히 개선을 이어갑니다. 어떤 과제는 1~2년이라는 긴 시간이 걸리기도 하지만, 결국에는 끝내 해결해내는 편입니다.
당연히 외부에서 알기 어려운 일이기 때문에 바로 평가를 받기는 어렵지만, 언젠가는 이 일의 가치를 인정받을 수밖에 없다고 장담합니다. 기술부채를 들여다보고 하나하나씩 뜯어서 올바르게 고쳐가는 것, 그리고 고쳐나간 것에 대한 드라마틱한 효과를 몸소 체험하는 것이 일을 하는 데 있어 동기부여가 될 수밖에 없다고 확신해요.
핀다에서의 역할
핀다 VP of Engineering으로서, 스스로에게 부여한 미션이 궁금합니다.
개발자는 시도할 때 가장 빛을 발합니다. 이러한 시도를 잘 할 수 있는 환경을 만드는 것이 저의 역할이라 생각해요. 다 같이 좋은 방법과 아이디어를 내고, 액션으로 실행한 뒤 회고하는 환경이요. 회고 이후에는 더 발전된 아이템을 발굴하고 실행하는 선순환 사이클을 만들어낼 수 있도록 인프라 차원에서든 문화 차원에서든 아낌 없는 지원을 하자는 게 저의 미션입니다.
다른 테크 기업과 비교했을 때, 핀다에서 개발자로 일하는 건 무엇이 다른가요?
핀테크 플랫폼이라는 규제산업임에도 불구하고 핀다의 개발 환경은 굉장히 유연한 편이에요. 규제산업은 망분리 등으로 인해 생산성 확보가 어려운 경우가 많은데요, 핀다 대표님들은 최대한 개발 생산성을 확보할 수 있는 보안 및 규제 환경을 만들어주고 계십니다.
또한 핀다는 AI를 업무적으로나 서비스적으로 활발하게 활용하면서 작고 강한 조직을 현실화시키고 있는 게 큰 특징입니다. 실제로 AI툴을 아낌없이 지원하고 인프라 환경도 가장 트렌디합니다. 이러한 개발 환경으로 확보한 시간을 더욱 건설적인 일에 쏟을 수 있는 게 가장 큰 장점이죠.
핀다 개발 조직은 AI를 어떻게 활용하고 있나요?
개발자들은 UX 디자이너들과 일하는 경우도 많은데, 디자인 코드 자동화, 이슈 로그 발생 시 자동 분석 기능 등 업무 효율을 높이는 것부터 적용하고 있어요. 이런 일들이 시간적 비용을 꽤 필요로 하는데요, 이런 시간들을 AI로 해결하고 저희는 고민과 설계에 충분한 시간을 더 많이 부여하고 있습니다.
충분한 고민과 설계를 하지 않고 프로젝트를 실행하면 꼭 회고 때 후회를 하더라고요. 한정된 리소스를 최소화하려다 보니 불가피하게 차선책을 택하는 경우도 있었는데, 이제 AI 덕분에 차선책이 아닌 최선책을 선택할 수 있으리라 생각합니다. 이후에는 코드 리뷰를 AI와 함께 할 수 있도록 활용하려고 준비 중입니다.
핀다를 만드는 개발 문화
핀다 개발팀의 규모가 궁금해요. 타팀과의 협업은 어떻게 이뤄지나요?
핀다 앱 서비스는 기능조직으로 팀이 쪼개어져 있습니다. 핀다의 코어 기능인 비교대출 플랫폼의 ▵금융상품 ▵자산관리와 마이데이터 ▵회원 및 CRM시스템을 개발하는 백엔드 조직이 있고, 프론트 개발을 맡는 ▵웹 ▵앱 팀과 ▵QA ▵데브옵스, DBA 조직 등 총 8개 팀으로 구성돼 있습니다.
핀다에는 이른바 ‘기획서’라 불리는 ‘디자인닥’ 문화가 있는데요. 기획자가 기획서를 쓰고 업무 관계자들에게 모두 공유한 뒤 리뷰를 받는 문화죠. 이만큼이나 테크 리뷰도 많이 하던데, 이에 대한 의도와 과정이 궁금합니다.
테크 리뷰 역시 디자인닥 리뷰와 동일한 프로세스로 진행됩니다. 기획서 단계에서 미처 챙겨보지 못했던 기술 영역에서의 리뷰도 전반적으로 점검해야 하거든요. 이 프로젝트가 어느 정도 리소스가 들어가고 어떤 결과를 가져올지 예측해보고 그만큼의 효과를 낼 수 있는지에 대하여 업무 참여자 모두가 공감대를 형성할 수 있어야 해요.
개발자와 기획자는 이 단계에서 수많은 조율을 하며 테크스펙을 수정해나갑니다. 기술 레벨에서 어떻게 구현할 수 있는지, 어렵지만 구현했을 때의 기대효과가 성과 측면에서 얼마나 좋을지 등을 감안하여 업무 레벨과 범위를 산정할 수 있거든요.
결국, 기획자, 디자이너, 개발자 등 각 역할을 맡은 모든 분들이 근본적으로 ‘이걸 내가 왜 해야 하는지’를 정확하게 이해하고, 내 역할과 차례를 정의할 수 있어야 오너십을 갖고 프로덕트를 탄탄하게 만들어갈 수 있습니다.
핀다 서비스에서 티 나지 않지만 반드시 챙겨야 하는 기본기는 무엇인가요?
본인이 생각했을 때 ‘옳다’고 믿는 일을 추진하는 것입니다. 이는 단순히 개인이 하고 싶은 대로 한다는 뜻이 아니라, 문제 해결을 위한 여러 가능한 방안 중에서 가장 합리적이고 최선의 선택을 하고 실행하는 힘을 의미합니다. 겉으로 보이는 일만 하면, 제대로 된 성과를 낼 수 없다고 생각합니다.
품질 관리 측면에서의 이슈관리를 예로 들어보자면 아무리 작은 이슈라도 민첩하게 대응하고 재발방지 대책을 마련하면 두 번 다시는 그 이슈가 우리를 괴롭히지 않습니다. 또, 작은 이슈가 알고 보면 코어 시스템의 큰 문제로 번지는 경우도 허다합니다. 따라서 우리는 아무리 작은 이슈라도 돋보기로 들여다보고 제대로 고쳐둬야 해요.
신규 서비스가 많아질 때 개발팀은 어떻게 대응하나요?
앞서 말씀드린 팀 운영 원칙대로 진행하는데요. 이른바 ‘원소스 멀티유즈’를 위해 아키텍처를 설계합니다. PLCC나 자산관리처럼 새로운 서비스를 붙일 때, 이미 구축된 인증·보안·로그·배포 체계를 재활용할 수 있도록 구조화해두었죠. 덕분에 새로운 시도가 시장에 빠르게 나올 수 있습니다.
핀다는 실제로 다양한 시도와 회고가 가능한 환경인가요?
네, 핀다의 가장 큰 장점입니다. 실행하고 회고하며 회고한 부분을 반영해 개선된 실행을 이어가며 서비스와 개인이 함께 성장할 수 있거든요. 이런 시도와 회고는 시간을 많이 투자해야 하기 때문에 환경 조성이 가장 중요합니다. 저는 이러한 환경을 만드는 것에 가장 큰 역할을 하고 있어요.
또한, 여러 가지 시도가 시스템 장애나 오류로 번지지 않도록 Feature Flag나 Canary Release를 적극적으로 활용합니다. 실패가 곧 고객 피해로 이어지지 않도록 방어망을 갖췄기에, 개발자들은 안심하고 실험할 수 있죠. 그리고 실패 후에는 반드시 회고를 통해 학습을 남깁니다.
개발팀의 개별 리더들에게 요구하는 리더십이 있으신가요?
별도의 리더십을 강요하지는 않습니다. 팀마다, 리더마다의 색깔이 있기 때문에 그들을 존중합니다. 다만, ‘리드가 왜 필요할까요?’, ‘왜 00님이 리드를 맡아야 할까요?’라는 질문을 종종 드리는데요, 이 질문을 드리면 대개 역할에 대해 깊은 고민을 하시는 편이에요. 이럴 때 저는 완벽한 기대값을 달성하기 위한 리더의 역할을 요구합니다.
저는 컴퓨터공학도니까 CPU를 예로 들어볼게요. 만약 성능이 굉장히 뛰어난 CPU를 여러 개 붙여서 병렬로 업무를 처리해야 한다고 생각해보세요. 이럴 경우 여러 개의 CPU를 꽂아둘 코어가 굉장히 중요한데요, 여기서 코어는 팀 리더의 역할이라고 봅니다. 아무리 성능이 좋은 CPU여도 코어가 부실한 곳에 꽂혀 있으면 무용지물이거든요.
좋은 하드웨어가 있다 해도 무의미한 일을 주면, 결과 또한 의미가 없게 되는 거죠. 1+1=2가 1+1=1.9999999가 아닌 것처럼, 완벽한 기대값을 내기 위해 코어의 역할과 성능이 꽤나 중요합니다.
마지막으로, 핀다 개발자를 지원하는 모두에게 해주고 싶은 말씀이 있다면요?
제가 대기업에서 스타트업으로 넘어갈 때 ‘제대로 피드백을 받고 성장하고 싶다’는 생각이 가장 많았어요. 사실 대기업에서는 상부에서 시키는 일을 잘 하고, 말을 잘 듣는 게 중요한 구조다 보니 개인의 역량이 성과로 이어진다고 해도 그 평가를 바로 받기가 어려울 수밖에 없거든요. 그렇지만, 핀다와 같은 스타트업은 기회가 많고 내가 해낼 수 있는 성장 발판이 많다고 생각합니다.
핀다에서 다양한 시도를 통해 개인과 서비스의 성장을 체감하고 싶은 모든 분들은 꼭 지원해주세요. 자신의 실력을 발휘하고 맞춤형 피드백과 다같이 성장하는 문화를 만들어갈 수 있습니다!
*핀다의 백엔드 개발자 채용 공고가 궁금하다면? 👉📌핀다 백엔드 개발자 채용 공고 확인하기
*핀다의 핵심가치가 궁금하다면? 👉핀다답게 일하는 방법, <핵심가치 2.0> 콘텐츠 보기
핀다 팀에 대해 더 알고 싶다면, 핀다포스트 ‘사람이 핀다’ 시리즈를 꼭 읽어주세요. :)
핀다는 지금 백엔드 개발자를 모시고 있어요.
핀다의 핵심 서비스를 담당하는 백엔드 개발자의 역할을 해내고 싶다면,
지금 핀다호에 탑승하세요!🚀✨
Interviewee 김은석
Interview·Edit 차수연
Photo 정진우
