제품이라는 것은 생각보다 많은 이해관계 집단이 서로 복잡하게 얽혀 있습니다. 특히 소프트웨어 제품은 추상적인 부분이 많고, 다양한 인재의 직관과 판단이 서로 얽힌 채 개발이 이루어지기 때문에 의사소통 비용이 크기 마련입니다. 어쩌면 우리 중 일부는 그 과정 속에서 지치고, 때로는 마음의 상처를 받기도 합니다. 하지만 이러한 역경을 견디고 견뎌 제품을 출시하고, 대중의 관심과 응원을 받게 되면 언제 그랬냐는 듯 다시 회복하고, 더 좋은 제품을 만들기 위해 다시 몰입하게 됩니다.
제품 개발에는 그런 중독성이 있습니다. 한번 맛보면 쉽게 놓을 수 없는, 고통과 보람이 공존하는 일입니다.
저는 세 개의 회사를 거치며 지금도 현장에 서 있습니다. 사회적 문제를 해결하고자 하는 열망, 그리고 모든 이들이 "문제"라고 정의하는 것을 실제로 해결해내기 위해 매일 노력하고 있습니다. 소프트웨어 제품의 형태는 매우 다양합니다. 많은 대중이 매일 사용하는 서비스, 기업이 겪고 있는 문제를 쉽게 해결해주기 위한 SaaS, 특정 산업에 특화된 솔루션 등 그 종류를 일일이 나열하기 어려울 정도입니다.
하지만 형태가 무엇이든 그 안에는 공통적으로 수많은 사람의 노력이 겹겹이 쌓여 있습니다.
제품 하나에 얽힌 수많은 손길
하나의 예를 들어보겠습니다. 고객이 은행이나 ATM 기계에 직접 가지 않고도 송금이나 대출, 예적금 상품을 가입할 수 있는 금융 앱이 있습니다. 사용자에게는 간편한 화면 몇 개로 보이겠지만, 그 뒤에서는 다양한 외부 기관과의 통신이 이루어지고 있고, 데이터의 정합성을 맞추기 위한 복잡한 로직 흐름이 서로 얽혀 있습니다. 사용자의 개인정보와 서비스의 보안을 지키기 위해 보안팀과 개인정보 보호팀이 끊임없이 검증하고 있으며, 제품이 시장에 나오기 위해서는 경영팀과 마케팅팀이 시장 분석과 홍보 전략에 오랜 시간을 투자해야 합니다. 제품의 사용성을 챙기기 위해 디자이너들이 수많은 실험을 반복하고, 이 모든 것을 기획하기 위해 PO와 PM의 아이디어가 필요합니다. 이를 실제로 구현해줄 개발자도 필요하고, 운영 단계에 들어서기 직전에는 리스크팀과 컴플라이언스팀이 제품의 안정성과 잠재적 위험을 측정합니다. 출시 이후에도 내부 운영을 위한 어드민 시스템이 필요하고, 사용자의 목소리를 들어주는 고객 지원 창구와 이에 대응할 전문 인력까지 갖추어야 합니다.
우리가 일상처럼 사용하는 앱 하나에 이토록 많은 이해관계자가 얽혀 있다는 사실을 아는 사람은 생각보다 많지 않습니다.
세계적인 제품을 만드는 조직들은 이 복잡성을 본능적으로 이해합니다. Google이 검색 결과 하나를 보여주기 위해 수천 개의 마이크로서비스가 협력하고, Apple이 버튼 하나의 촉감을 위해 수십 번의 프로토타입을 거치며, Meta가 뉴스피드 알고리즘 하나를 바꾸기 위해 수백만 사용자를 대상으로 A/B 테스트를 수행하는 것은 단순한 완벽주의가 아닙니다. 제품이 닿는 사람의 수만큼, 제품에 대한 책임의 무게도 비례한다는 것을 알기 때문입니다. 규모가 다르다고 본질이 다른 것은 아닙니다. 사용자가 열 명이든 열억 명이든, 제품을 만드는 사람의 태도는 같아야 한다고 생각합니다.
제품의 사회적 무게
제품의 크기에 따라 사회적 영향도는 다를 수 있겠습니다. 하지만 저는 모든 제품이 크기와 관계없이 어느 정도의 사회적 영향을 주고 있다고 생각합니다. 누군가의 하루를 조금 더 편하게 만들어주는 작은 기능 하나도, 누군가의 업무 시간을 줄여주는 자동화 하나도, 결국은 사회를 구성하는 사람들의 삶에 닿아 있기 때문입니다.
저는 매일 이 생각을 잊지 않으려 합니다. 이러한 것들이 제가 일을 하는 의미이기 때문입니다.
실리콘밸리에서 자주 인용되는 말 중에 "We ship, therefore we are"라는 표현이 있습니다. 출시하지 않은 제품은 존재하지 않는 것과 같다는 뜻입니다. 하지만 저는 여기에 한 가지를 덧붙이고 싶습니다. 출시한 제품이 누군가의 삶을 실제로 바꾸지 못한다면, 그것 역시 존재하지 않는 것과 다르지 않습니다. 제품은 기능의 집합이 아니라, 누군가의 문제에 대한 우리의 대답입니다. 그 대답이 성의 없다면, 차라리 침묵이 나을 수도 있다고 생각합니다.
태도가 품질을 결정한다
매일 반복되는 로그 검색, 디버깅, 오류 모니터링, 신규 기능 개발, 유지보수. 어느 정도 업무에 적응된 상태라면 그다지 어렵지 않은 일들일 수도 있습니다. 익숙해진 만큼 무감각해지기 쉬운 일이기도 합니다. 그럼에도 저는 단 한 번도 이 일들을 간과하거나 느슨한 태도로 임한 적이 없습니다. 그 로그 한 줄이 장애의 원인을 알려주고, 그 에러 핸들링 하나가 누군가의 경험을 좌우한다는 것을 알기 때문입니다.
사소해 보이는 일일수록, 그 일을 대하는 우리의 태도가 해당 제품의 품질을 결정한다고 믿기 때문입니다.
Amazon에는 "Day 1"이라는 철학이 있습니다. 아무리 조직이 커지고 제품이 성숙해져도, 첫날의 긴장감과 고객에 대한 집착을 잃지 말라는 것입니다. 반대로 "Day 2"는 정체이고, 무관심이며, 결국 쇠퇴입니다. 저는 이 철학에 깊이 공감하고 동의합니다. 제품이 안정기에 접어들수록, 그리고 업무가 루틴이 될수록 우리는 자연스럽게 Day 2에 진입합니다. 어제와 같은 코드를 작성하고, 어제와 같은 방식으로 배포하고, 어제와 같은 수준의 리뷰를 합니다. 그것이 편안함인지, 아니면 무감각인지를 구분하는 것은 오직 본인만이 할 수 있습니다.
내가 팀원들에게 바랐던 것
그렇기에 저는 어쩌면 팀원들에게도 위와 같은 것, 그리고 저와 같은 마음 이기를 바라고 있었는지 모릅니다. 대단한 기술력이나 화려한 성과가 아닙니다. 자신이 만드는 것에 대한 진솔한 태도입니다. 내가 작성한 코드가 어디로 흘러가는지, 내가 내린 결정이 누구에게 닿는지를 한 번이라도 더 생각해보는 것. 당장 눈앞의 티켓을 처리하는 데 급급하기보다, 내가 지금 만들고 있는 것이 결국 어떤 사람의 어떤 순간에 쓰일지를 떠올려보는 것.
그런 마음으로 일하는 사람들이 모였을 때, 제품은 단순한 기능의 집합이 아니라 진짜 문제를 해결하는 도구가 됩니다. 그리고 그런 팀이 만든 제품은 사용자가 느끼는 사용성과 직결된다고 생각합니다.
하지만 현실은 다를지도 모릅니다. 저의 이 작은 기대가 현업에서 충족된 적은 전무했을지도 모릅니다.
코드 리뷰에 "LGTM"만 남기고 실제로는 한 줄도 읽지 않은 리뷰어를 여러 번 만났습니다. 장애가 발생했을 때 원인을 파악하려 하기보다 "내 코드가 아니다"라는 말부터 하는 동료를 보았습니다. 테스트 코드를 작성하자고 제안하면 "시간이 없다"는 답이 돌아왔고, 정작 그 시간은 같은 버그를 반복적으로 수정하는 데 쓰이고 있었습니다. PR 설명에 "왜 이렇게 구현했는지"를 적어달라고 요청하면 그닥 중요하지 않을 일에 신경쓰지 않는다는 듯한 태도로 일관한 사람들도 빈번했습니다.
가장 힘들었던 것은 기술적 부채를 방치하는 태도였습니다. "지금은 급하니까 일단 이렇게 하고, 나중에 고치자"는 말은 언제나 "나중에"가 오지 않는다는 것을 모두가 알면서도 반복되었습니다. 그 "일단"이 쌓이고 쌓여, 결국 시스템 전체가 누구도 자신 있게 건드리지 못하는 상태가 됩니다. 세계적인 엔지니어링 조직에서는 기술적 부채를 정기적으로 측정하고, 일정 비율의 스프린트를 부채 상환에 할당합니다. 그것은 사치가 아니라, 제품이 오래 살아남기 위한 생존 전략입니다. 하지만 제가 겪은 현장에서는 그런 논의 자체가 성립하지 않는 경우가 많았습니다.
실제 사례로 세 번째 회사에 제가 처음 입사했을 당시의 똑같은 기술 스택으로 셋팅돼있던 다른 방치된 어느 서비스는, 훗날 1년 반 뒤, 로컬에서 그 서비스는 작동되지 않았습니다.
조직 문화라는 이름의 실망
팀원 개인의 태도보다 더 깊은 실망을 안겨준 것은 조직 문화였습니다.
"엔지니어링 문화를 만들겠다"고 선언하면서, 정작 코드 리뷰 프로세스 하나 제대로 정착시키지 못하는 조직을 보았습니다. "데이터 기반 의사결정"을 강조하면서, 실제로는 가장 목소리가 큰 사람의 의견이 곧 결정이 되는 회의를 수없이 겪었습니다. "실패를 두려워하지 않는 문화"를 말하면서, 실패한 프로젝트의 담당자가 조용히 밀려나는 것을 목격했습니다.
문화는 슬로건이 아닙니다. 문화는 위기 상황에서 조직이 실제로 어떤 선택을 하는지로 드러납니다.
Google에는 "Postmortem without blame"이라는 원칙이 있습니다. 장애가 발생하면 누가 실수했는지를 추궁하는 것이 아니라, 시스템의 어떤 부분이 실패를 허용했는지를 분석합니다. 잘못은 개인에게 있지 않고, 그 실수를 방지하지 못한 시스템에 있다는 전제입니다. 이 원칙이 있기 때문에 엔지니어들은 두려움 없이 장애를 보고하고, 솔직한 분석을 공유하며, 결과적으로 시스템은 점점 더 견고해집니다.
반면 제가 경험한 조직에서는 장애 보고서가 곧 시말서였습니다. 원인 분석보다 책임 소재가 먼저였고, 재발 방지 대책은 "앞으로 더 주의하겠습니다" 한 줄로 끝났습니다. 주의력은 시스템이 아닙니다. 주의력에 의존하는 조직은 반드시 같은 실패를 반복합니다.
제품 방향성에 대한 논의에서도 실망은 이어졌습니다. 왜 이 기능을 만들어야 하는지에 대한 명확한 가설 없이, "경쟁사가 하니까", 혹은 "대표님이 원하시니까"라는 이유로 백로그가 채워지는 것을 보았습니다. 사용자 리서치 없이 출발한 기능은 출시 후 아무도 사용하지 않았고, 그 기능을 만들기 위해 쏟은 몇 주간의 노력은 조용히 묻히기 마련입니다. 그리고 또다시 새로운 기능이 같은 방식으로 시작되었습니다.
세계적인 제품 조직에서는 이런 낭비를 "output vs. outcome"이라는 프레임으로 구분합니다. Output은 우리가 만든 것의 양이고, outcome은 그것이 실제로 만들어낸 변화입니다. 기능 열 개를 출시했지만 사용자의 행동이 바뀌지 않았다면, 그것은 성과가 아니라 낭비입니다. 하지만 이 구분을 진지하게 받아들이는 조직을 만나기는 쉽지 않았습니다.
그리고 또 하나의 실망이 있었습니다. 기술 스택에 대한 맹목적 집착입니다. "우리 회사는 Spring Boot를 쓴다", "이 언어는 생태계가 작다", "그 기술은 현업에서 못 쓴다". 이런 말들이 마치 기술적 판단인 것처럼 포장되지만, 실제로는 익숙한 것에 대한 안주일 뿐인 경우가 많았습니다. Spring Boot를 쓴다고 기술 부채가 안 쌓이던가요? 인기 있는 프레임워크를 채택한다 한들, 그것을 다루는 사람의 태도가 느슨하면 기술 부채는 똑같이 쌓입니다. 특정 기술 스택에 대한 순수한 숙달도를 실력이라 부르는 문화, 문제를 정의하는 훈련보다 도구를 숙달하는 훈련에 더 익숙한 환경. 이것 역시 조직 문화의 병폐 중 하나라고 생각합니다. Google은 C++, Java, Go, Python을 문제에 따라 선택하고, Meta는 Hack, C++, Rust를 섞어 씁니다. 세계적인 엔지니어링 조직에서 "우리는 이 언어만 쓴다"고 고집하는 곳은 없습니다. 문제가 먼저이고, 도구는 그다음이기 때문입니다.
이것은 엔지니어링 문화 뿐만 아니라 제품에 임하는 타직군도 마찬가지리라 생각합니다.
그럼에도 불구하고
그럼에도 불구하고 일을 하며 지치는 일이 발생하는 이유는 무엇일까요?
일의 의미가 어쩌면 서로가 다를지도 모릅니다. 누군가에겐 아주 중요한 생계 수단일 수도 있지요. 하지만 다른 누군가에게는 본인의 성취를 이뤄내기 위한 수단 중 하나일지도 모릅니다. 또 다른 누군가에게는 그저 하루 여덟 시간을 채우는 일일지도 모릅니다. 이 차이 자체를 비난할 수는 없습니다. 사람마다 삶의 우선순위는 다르니까요.
하지만 그 차이가 제품에 고스란히 드러난다는 것이 문제입니다.
의미를 가지고 일하는 사람과 시간을 채우며 일하는 사람이 같은 코드베이스에 기여할 때, 코드의 온도가 달라집니다. 한쪽은 엣지 케이스를 고민하고, 다른 한쪽은 해피 패스만 구현합니다. 한쪽은 미래의 유지보수를 생각하며 이름을 짓고, 다른 한쪽은 temp, data, result 같은 이름을 아무렇지 않게 씁니다. 한쪽은 장애가 나면 새벽에도 달려오고, 다른 한쪽은 "내일 확인하겠습니다"라고 합니다.
이것을 두고 누가 옳고 그르다고 말할 수는 없습니다. 다만, 저는 전자의 사람들과 함께 일하고 싶었고, 그런 팀을 만들고 싶었으며, 그것이 여의치 않을 때 깊은 피로를 느꼈다는 것은 사실입니다.
이 글의 의미
제품을 만드는 일이 왜 의미 있는지, 그리고 그 의미를 지키기 위해 우리 각자가 어떤 태도를 가져야 하는지를 함께 나누고 싶었습니다.
우리가 매일 마주하는 코드 한 줄, 회의 한 번, 리뷰 코멘트 하나가 결국 제품이 되고, 그 제품이 누군가의 삶에 닿습니다. 그 사실을 기억하는 것만으로도 우리의 일은 충분히 달라질 수 있다고 저는 믿습니다.
완벽한 조직은 없습니다. 완벽한 팀도 없습니다. 하지만 "좋은 제품을 만들고 싶다"는 마음이 진심인 사람들이 모이면, 불완전한 조직에서도 놀라운 것들이 만들어집니다. 저는 그런 경험도 해보았기에 아직 이 자리에 서 있습니다.
다만, 한 가지는 분명히 하고 싶습니다. 좋은 제품은 좋은 문화에서 나옵니다. 그리고 좋은 문화는 선언이 아니라 실천에서, 위기의 순간에서, 불편한 대화를 회피하지 않는 용기에서 만들어집니다. 코드를 잘 짜는 것만으로는 부족합니다. 코드를 잘 짜는 사람들이 안전하게 의견을 나누고, 실패를 두려워하지 않으며, 서로의 성장을 진심으로 응원할 수 있는 환경. 그것이 저는 진짜 좋은 제품을 만드는 팀의 문화라고 생각합니다.
그리고 그런 문화를 만들지 못한다면, 아무리 뛰어난 개인이 모여도 결국 평범한 제품밖에 만들 수 없습니다. 저는 그것이 가장 아까운 낭비라고 생각합니다.