팀스펙터가 자랑하는 진짜 일하는 사람 인터뷰 2탄입니다.
*1탄 : 진짜 일하는 사람들 #1 ‘매출과 사용량을 책임지는 디자이너’가 되고 싶어요! - 진짜 나를 빛나게, 스펙터 Specter
많은 기업이 조직 문화나 회사 분위기를 문서화된 조직 문화 가이드북이나, 키워드로 소개합니다.
스펙터는 말합니다.
조직 문화는 ‘함께 일하는 사람들의 합’에서 시작한다고요.
합을 잘 알 수 있는 방법은 그 속에서 일하는 사람들의 이야기를 직접 들어보는 것 아닐까요?
스펙터 고객들이 겪는 문제를 제품 관점에서 해결하는, 진짜 일하는 개발자 매튜(Matthew)의 이야기를 시작합니다.
1. 진짜 일하는 개발자 : 매튜
자기소개와 현재 담당하는 업무를 간단히 소개해 주세요.
안녕하세요. 스펙터 프론트엔드 개발자 매튜입니다. 😃
주로 프론트엔드를 개발하고, AWS 인프라 환경을 구성/운영하는 역할도 겸하고 있습니다.
스펙터에서의 개발자는 어떤 역할을 수행하나요?
주로 제품 개발 전반을 담당하지만, 본인이 원하고 설득만 할 수 있다면 다양한 경험을 할 수 있습니다.
저는 Project Owner로 프로젝트를 리드하기도 했고, AWS 환경에서 인프라 관리도 담당하고 있습니다.
프로젝트가 스펙터의 방향성에 맞다면, 개발자도 프로젝트를 발제하고 주도하는 PO를 할 수 있습니다.
인프라 관리도 비슷합니다. 이전 회사의 풀스택 개발 경험을 바탕으로, 스펙터에 필요하다고 생각되는 인프라 환경을 직접 설계하고 제안했었습니다.
두 가지 모두 프론트엔드 개발자라면 경험하기 어려울 수 있는데요.
프로젝트를 잘 마무리하면서 동료들과의 신뢰를 쌓았고, 지금은 개발 리드분과 함께
스펙터의 인프라를 운영하고 있습니다.
2. 고객의 목소리보다 ‘이면의 니즈’를 찾는 개발
고객의 목소리로 개발이 시작된 경험이 있나요?
많은 기능은 고객사가 필요로 하는 것에서 시작합니다.
다만 꼭 그 목소리를 그대로 듣지는 않아요.
오히려 그런 니즈 속에 숨은 문제 해결 방법을 찾는 것 집중합니다.
무엇을 원한다는 건 해결하고자 하는 문제가 반드시 있기 마련이니까요.
그리고 언급한 기능이 아니라 더 간단하게 문제를 해결할 수도 있으니까요.
실제 고객사 중 특정 기능의 커스텀을 원하는 회사가 있었습니다.
원하는 기능을 그대로 만들기보단 왜 이 기능을 원했는지, 어떤 행동 시나리오에서 이 기능을 사용하려는지 등을 실제 고객과 가장 밀접하게 일하는 Activation팀과 함께
논의했습니다.
논의 과정을 거치면서 문제 해결 방법을 찾았고, 요청한 회사뿐 아니라 다른 기업도 쓸 수 있게 기능화했습니다.
고객의 진짜 니즈를 파악할 때 어떤 방식을 이용하시나요?
정성적인 데이터가 필요할 때는 주로 CX, Activation팀과 논의합니다.
정량적인 데이터(사용량)가 필요할 때는 Clarity나 실제 데이터를 보고 Redash를 활용해 대시보드를 만들어서 의사결정에 참고하는 편입니다.
3. 직설적인 피드백의 진짜 의미
개발자가 아닌 구성원과의 소통에서 기억에 남는 장면이 있다면요?
저는 PM 외에는 거의 소통을 하지 않는 개발자였습니다.
다른 소통은 불필요하다고 생각했거든요.
하지만 생각이 바뀌게 된 건, 작년 PO로 프로젝트를 리드하면서였어요.
다른 직군과 자유롭게 소통한 이후로 적극적인 소통이 필요하다고 생각했습니다.
제품을 바라보는 시선, 프로세스를 풀어내는 방식 등이 직군마다 달랐기 때문이죠.
덕분에 킥오프 미팅에서 방향성을 잘 잡을 수 있었고, 수많은 피드백으로 플로우차트를 그릴 수 있었어요.
이렇게 다양한 직군들의 의견을 듣고 풀어나가는 경험이 기억에 남습니다.
커뮤니케이션이 어려운 상황은 어떻게 푸시나요?
의견을 주고받는 게 어려웠던 적은 없었던 것 같아요.
원하는 방향을 먼저 이야기하고 제 생각을 풀어나가는 편인데요.
이야기하는 게 조심스러울 때도 있지만, 직설적인 피드백은 꼭 필요하다고 생각해요.
그 이유는 돌려 말하면 이해하지 못할 확률이 있기 때문이에요.
그 확률이 있는 소통은 결국 서로를 피곤하게 만들더라요.
그래서 명확히 제 뜻을 전달하며 소통하려고 합니다!
‘직설적인 피드백’이 더 나은 결과를 만든다고 생각하시나요?
제가 생각하는 직설적인 피드백은 원하는 결과를 명확하게 정의하는 것이라고 생각해요. 말투가 세거나 감정을 실어 말하는 게 아니라요.
예를 들어 “이거 왜 이렇게 했어요?”라는 질문이 있다면, 말 그대로 명확하게 ‘왜’에 방점을 두면 된다고 생각해요.
말투나 감정에 집중해서 ‘다른 방법이 있는데 왜 이렇게 했는지 비꼬는 건가?’라고 생각할 필요가 없는 거죠.
“아, 왜 이렇게 했는지를 설명하면 되겠구나”라고 받아들이는 게 중요하고요.
결국은 의도를 정확하게 전달하고, 그걸 열린 자세로 받아들이는 소통이 핵심이라고 봅니다.
저는 디자이너나 PM과 협업할 때, “이 기능이 정말 지금 필요한 걸까?”라는 질문을 자주 던져요. 최근 *팀 인사이드를 개편할 때도, 초기에 기획된 버튼이나 기능 중에서 지금은 필요하지 않은 것들을 서로 직설적으로 이야기하면서 빠르게 정리할 수 있었어요.
덕분에 사용자가 더 편하게 이용할 수 있는 화면을 만들 수 있었습니다.
*팀 인사이드 : 스펙터의 조직 문화 진단 제품
이런 경험으로 직설적인 피드백은 갈등을 만드는 게 아니라, 더 나은 결과를 만드는 도구라는 걸 다시 한번 느꼈어요.
4. 2주, 95%, 0건이 의미하는 것
가장 빠르게 기획 → 디자인 → 배포까지 이어진 프로젝트는 어떤 건가요?
최근에 진행한 것으로 비지정 평판 프로젝트를 활성화하기 위한 배포가 있었습니다.
기획부터 디자인, 개발까지 2주 만에 첫 개선 건을 배포했었던 기억이 납니다.
해당 프로젝트가 어떤 임팩트를 만들어 냈나요?
두 가지 방향에서 살펴볼 수 있을 것 같습니다.
프로젝트 전에는 비지정 평판 프로젝트 성공률이 70%였는데, 배포 직후 95%까지 끌어올렸고 리드타임도 3.4일에서 2.3일로, 32.4%가 단축되어 고객 경험이 좋아졌습니다.
그 결과 사용량이 기존 대비 105%가 상승했고 이에 따라 매출도 상승했습니다.
내부 리소스 문제도 해결했습니다.
기존에는 하루에 10건 이상 CX팀에서 대응해야 하는 건들이 발생했는데,
프로젝트 이후 대응 건이 0건인 날도 많아지며 리소스를 32%나 감소시켰어요!
CX팀에서 다른 업무에 더 집중할 수 있도록 생산성을 향상했죠.
이런 속도와 결과가 가능했던 비결은 무엇이라고 생각하세요?
프로젝트를 해야 하는 이유가 명확했고, 프로젝트 구성원 간 Align이 맞았기 때문에
잘 진행될 수 있었다고 생각합니다.
세부적으로는 이전에 비지정 평판 프로젝트의 PO 역할을 한 적이 있기에 방향성과
의사결정을 빠르게 할 수 있었고, 테크 리드분이 개발을 맡아주셨기 때문에
빠른 속도로 개발할 수 있었습니다.
또한 CX팀에서 먼저 수기로 프로세스를 개선해 효과가 검증되었고, 이것을 빠르게
플랫폼에 적용하면서 높은 성과를 낼 수 있었습니다.
5. 꾸준함과 전환점을 대하는 방식
주로 사용하는 툴이나 개인 루틴이 있다면요?
TickTick이라는 툴을 매일 사용해요.
매일 출근하면 Jira와 Teams를 확인하며 하루를 시작합니다.
그리고 TickTick으로 오늘 할 일을 정리하죠.
저는 기록하는 습관이 중요하다고 생각하는데요.
이렇게 기록해 두면 회고할 때 큰 도움이 되더라고요.
또 정리한 업무를 간단히 To-do 리스트 형식으로 Teams 스레드에 공유합니다.
이렇게 공유하면 서로의 업무 흐름을 자연스럽게 파악할 수 있어서 좋아요.
또 평소에 기술 토론이나 아티클 읽는 것을 좋아해서, 재미있거나 흥미로운 내용을
발견하면 팀원들과 자유롭게 공유하는 편이에요.
이렇게 작은 공유들이 팀 분위기에도 긍정적인 영향을 주는 것 같아요!
개발할 때는 GitHub Copilot이나 WindSulf 같은 AI 툴의 도움도 종종 받습니다.
(당연히 회사 지원!)
일할 때는 자율성과 책임이 함께 따르는데요. 어떻게 조율하나요?
저는 개발팀을 단순히 코드를 작성하는 것을 넘어, 비즈니스 문제를 기술적으로 잘 풀어내는 팀이라 생각합니다.
비즈니스 의사결정을 존중하면서, 기술적 측면에서는 어떻게 하면 이 문제를 가장
효과적으로 해결할 수 있을지를 고민하는 게 저희의 역할이라 보고 있어요.
이런 맥락에서 자율성과 책임은 함께 가야 한다고 생각합니다.
기술적인 선택을 할 때도 왜 이 기술이 필요한지, 무엇이 더 나아지는지를 충분히
설명하고, 팀원들을 설득하는 과정이 중요하다고 느껴요.
그리고 그 기술이나 프로세스가 저 혼자만 이해하고 유지할 수 있는 것이 아니라,
누구든지 유지 보수할 수 있도록 만드는 것 또한 중요한 책임이라고 생각합니다.
결국, 저는 이런 의사결정의 맥락(Context)을 공유하고 공감대를 만드는 것이
자율성을 책임 있게 사용하는 방식이라고 생각해요.
자율은 단순히 “내가 하고 싶은 대로 한다”가 아니라, 공동의 목표를 향해 더 나은 방향을 스스로 찾아가는 힘이라고 믿습니다.
스펙터에서 개발자로 일하며 성장했다고 느꼈을 때는 언제인가요?
스펙터에 합류한 지 2년이 넘었고, 개발자로는 4년 차가 됐습니다.
“내가 진짜 성장했나?”라는 질문을 스스로에게 던졌을 때, 지금은 확실히 “네!”라고 말할 수 있어요.
예전에는 괜찮다고 생각했던 코드들을 지금 보면 너무 복잡하게 만들어져있고, 유지 보수도 어려운 경우가 많았거든요. 그런 코드들을 하나씩 리팩토링하고, 더 나은 방향으로 바꿔 가는 과정을 통해 성장했다고 느꼈습니다.
그동안 혼자 고민하기보다는 스터디도 꾸준히 하고, 코드 리뷰나 토론도 자주 하면서
개발에 대한 생각의 깊이가 조금씩 깊어졌어요.
“이게 왜 좋은 코드일까?”라는 질문을 자주 던지면서 자연스럽게 더 좋은 코드를
쓰려고 노력하게 됐고요.
특히 PO 역할을 맡았던 시기가 큰 전환점이었어요.
개발만 하는 게 아니라, 다른 직군 분들과 대화하고 의견을 조율하면서 “좋은 결정”을 내리기 위해 되게 많이 고민했거든요.
혼자 결정할 수 없는 상황도 많아서 경험 많은 분들께 물어보고 조언을 듣고, 그걸
바탕으로 판단하고 실행하는 경험이 정말 큰 도움이 됐습니다.
요즘은 “일을 많이 하는 게, 꼭 잘하는 건 아니다”라는 걸 많이 느끼고 있어요.
그보단 “어떻게 하면 더 좋은 제품을 만들 수 있을까?”를 고민하는 게 진짜 중요한 것 같아요.
개발자는 코드만 잘 짜는 사람이 아니라, 사용자에게 좋은 경험을 줄 수 있도록 고민하고, 팀과 함께 더 나은 방향으로 나아가는 사람이니까요.
지금의 저는 숫자와 데이터로 이야기하고, 근거를 갖고 설득하며 더 나은 결과를
만들기 위해 계속 배우는 이에요.
그리고 앞으로도 계속 그렇게 성장해 나가고 싶습니다.
6. 스펙터다운 개발
매튜가 생각하는 ‘스펙터다운 개발’이란 어떤 모습인가요?
빠르게, 논리적인, 그리고 예측해서 움직이는.
스펙터다운 개발은, 무작정 시도하는 것이 아니라 명확한 맥락과 방향성 안에서
빠르게 실험하고 학습하는 것이에요.
그리고 그 안에서 동료들이 이해하고 공감할 수 있는 구조와 논리를 만드는 것,
지금만이 아니라 앞으로를 내다보며 유연하게 확장할 수 있도록 설계하는 것이 중요하다고 느낍니다.
앞으로 스펙터에서 해보고 싶은 일이 있다면요?
요즘은 어떻게 하면 더 유연한 구조를 만들 수 있을까?의 고민을 많이 하고 있어요.
같은 제품을 같은 사람이 오랫동안 개발하다 보면 어느 순간 머릿속에만 존재하는
컨텍스트가 쌓이기 마련이고, 그게 결국 구조의 경직성으로 이어지기도 하더라고요.
그래서 앞으로는 새로운 개발자분들이 합류했을 때도 맥락을 쉽게 이해하고 빠르게
적응할 수 있는, 더 유연한 구조를 만들어보고 싶어요.
개인의 경험이나 감각에 의존하기보다는, 명확한 기준과 흐름 속에서 함께 성장할 수
있는 개발 환경을 만드는 것.
그게 지금 제가 스펙터에서 가장 해보고 싶은 일입니다.
이 글을 읽고 스펙터에 관심을 가지게 될 개발자에게 한 마디~!
밖에서 보는 스펙터는 진짜 빙산의 일각이에요. ㅎㅎ
겉보기엔 단순해 보일 수 있지만, 실제로 들어와 보면 꽤 복잡한 플로우와 구조들을
어떻게 쉽게 만들 것인가에 대한 고민이 가득해요.
이 안에서 재미있고 도전적인 문제들을 함께 풀어보고 싶다면,
분명 좋은 경험이 되리라 생각합니다!
