P.E.C 참가자 인터뷰

여러분은 개발자로서 가장 도전적이었던 순간을 떠올려 본 적 있으신가요? 때로는 익숙한 방식을 벗어나 새로운 구조를 도입하거나, 사용자의 진짜 문제를 해결하기 위해 기획과 개발의 균형을 맞추는 과정에서 우리는 더 깊이 성장하곤 합니다. 이번 인터뷰에서는 Product Engineer Camp(P.E.C)를 통해 성장한 동희님의 이야기를 소개합니다. 동희님은 현재 신사업 팀에서 프론트엔드 개발을 담당하며, 두 개의 제품을 성공적으로 출시했습니다. 특히 문서 기반 검색 시스템과 LLM을 활용한 문서 작성 지원 프로그램을 개발하며 FSD(Feature-Sliced Design)와 zustand를 도입해 프로젝트를 혁신적으로 리팩토링한 과정을 생생하게 들려주셨습니다. P.E.C를 통해 단순히 코드를 작성하는 개발자가 아닌, 사용자 경험을 주도적으로 개선하는 개발자로 변화한 동희님. FSD와 zustand를 결합해 복잡한 프로젝트를 체계적으로 관리하고, 사용자 중심의 철학을 실제 업무에 적용해 나가는 동희님의 경험은 많은 개발자들에게 실질적인 인사이트를 제공할 것입니다. 사용자를 위한 더 나은 제품을 만들기 위해 끊임없이 고민하고 도전한 동희님의 이야기, 지금 바로 만나보세요! Q. 요즘도 신사업 팀에서 계속 계신가요? 네, 올해 정말 바빴습니다. 제품 두 개를 출시했거든요. Q. 와, 두 개나요? 어떤 제품인지 간단히 설명해주실 수 있나요? 첫 번째는 문서를 업로드하면 색인을 하고 문서 기반으로 검색할 수 있는 시스템이에요. 프론트엔드는 다른 개발자 한 분과 함께 작업했죠. 두 번째는 ChatGPT나 SOLA 같은 LLM 모델을 활용해 문서를 작성할 수 있도록 도와주는 프로그램인데, 이건 프론트엔드 전체를 제가 혼자 담당했어요. Q. 혼자서 전체를 다 하신 거라니 대단합니다. 어려운 점은 없으셨나요? 두 번째 프로젝트는 UI는 간단했지만, 비즈니스 로직이 많아서 설계가 쉽지 않았어요. 특히 zustand를 사용해 전역 상태를 관리했는데, 이 프로젝트 특성상 props drilling만으로 해결이 안 되는 부분이 많았거든요. 그래서 zustand로 전역 상태를 관리했지만, 의존성 관리가 쉽지 않아 고생했죠. + (인터뷰어 의견) 맞아요. zustand를 그냥 사용하면 의존성이 꼬일 수밖에 없는 부분이 있을것 같아요. 클린 아키텍처에서 사용하는 usecase 개념을 zustand와 결합해서 설계하는 방향도 있더라고요. 이때 각 컴포넌트가 특정 스토어에만 의존하도록 스토어를 분리하는 작업이 정말 중요하더라고요. Q. FSD(Feature-Sliced Design)도 도입하셨다고 들었는데요. 어떤 과정으로 적용하셨나요? 이 프로젝트에서 FSD를 처음으로 적용했어요. 기존에는 모놀리식 구조로 개발을 시작했는데, 비즈니스 로직과 UI 코드가 한곳에 섞여 있어서 유지보수가 너무 힘들었어요. 그래서 FSD 구조로 리팩토링을 시작했죠. 처음에는 중요한 기능부터 차근차근 구조를 바꿨고, 시간이 생길 때마다 나머지 부분도 리팩토링을 진행했어요. Q. FSD 구조로 전환하면서 가장 큰 변화는 무엇이었나요? 가장 큰 장점은 비즈니스 로직과 공통 UI를 명확히 분리할 수 있었다는 거예요. 예를 들어, 공통 UI는 shared 폴더에, 특정 기능은 features 폴더에 배치하면서 코드의 위치가 명확해졌죠. 이전에는 모든 게 한 폴더에 몰려 있어서 찾기가 어려웠는데, 지금은 유지보수가 훨씬 쉬워졌어요. Q. 리팩토링 과정에서 어려움은 없으셨나요? 당연히 있었습니다. 특히 기존 구조가 의존성이 많아서 처음에 손대기가 쉽지 않았어요. 그래서 중요도가 높은 기능부터 FSD 구조로 리팩토링을 시작했고, 시간이 생길 때 점진적으로 나머지 코드를 수정했어요. 또 zustand와 FSD를 결합하는 과정에서 스토어 설계를 새로 해야 했는데, 스토어 간 의존성을 최소화하는 작업이 특히 어려웠어요. Q. 이런 리팩토링 작업은 당장 성과가 보이지 않을 텐데요. 힘들지 않으셨나요?

[P.E.C 졸업생 인터뷰 권효진] 사용자 중심의 개발과 끊임없는 성장 이야기 👉 영상: https://youtu.be/vSIb2sPdu9U?si=NSh1KT-JLPjox1Ie 여러분은 개발자로서 어떤 순간에 가장 큰 성장을 느끼시나요? 많은 개발자들이 실제 문제를 해결하고, 사용자와 직접 소통하며, 제품을 개선하는 과정에서 큰 성장을 경험한다고 합니다. 이번 인터뷰에서는 Product Engineer Camp(P.E.C)를 통해 성장한 권효진님의 이야기를 소개합니다. 권효진님은 현재 카프카 모니터링 툴을 만드는 스타트업 스피타에서 프론트엔드 개발을 담당하고 있습니다. 초기 멤버로서 다양한 역할을 수행하며, 팀을 이끌고 있는 권효진님은 P.E.C를 통해 어떤 변화를 경험했는지, 그리고 현재 진행 중인 프로젝트와 앞으로의 계획에 대해 진솔하게 이야기해주셨습니다. 개발자라면 누구나 한 번쯤 고민해봤을 사용자 중심의 개발 철학과 실제 업무에서의 적용 방법, 그리고 스타트업에서의 도전과 성장을 권효진님의 경험을 통해 생생하게 들어보세요.(최대한 어투를 살리기 위해 원본 그대로 담고자 했습니다.) Q: 현재 하고 계신 일에 대해 소개해 주세요. A: 저는 카프카 모니터링 툴을 만드는 회사인 스피타에서 프론트엔드 개발을 담당하고 있어요. 저희는 카프카 모니터링만 하는 것이 아니라 파이프라인 구성이나 다른 서비스들도 제공하고 있어요. 제 역할은 개발만 하는 건 사실 아니고, 서비스 기획이나 다른 일들도 하고 있습니다. 아무래도 인원이 적다 보니까 스타트업이니까 처음부터 끝까지 다 일을 하고 있어요. 현재는 프론트엔드 팀 3명을 이끌고 있습니다. Q: 회사의 규모와 현재 상황은 어떤가요? A: 저희 회사는 현재 15명 정도 있어요. 아직은 가야할 길이 먼 초기 스타트업이에요. 인당 매출이 2억 정도가 나와야 한다고 생각해서, 아직 충분히 회사 성장의 여지가 있다고 보고 있어요. Q: 포지션에는 어떤 변화가 있었나요? A: 처음에 개발팀이 세 분 계셨는데, 지금은 제가 리드 아닌 리드, 리드까지는 좀 웃기지만 그렇게 하고 있어요. 회사에 가면 의외로 일을 할 수 있는 시간이 그렇게 많지 않더라고요. 회의도 많고, 되게 작은 것들도 다 어쨌든 의사결정을 해야 되니까요. 또 저희는 인원이 적다 보니까 제가 직접 고객사에 가서 저희 대시보드 사용자 교육을 하는 경우도 있고, 카프카 관련해서 알려드리는 경우도 있어요. Q: 현재 진행 중인 주요 프로젝트는 무엇인가요? A: 현재 전체적인 리팩토링 작업을 진행 중입니다. 처음부터 제가 다 만든 거거든요. 완전 신입 개발자일 때 만들어서 코드를 볼 때마다 좀 스트레스 받더라고요. 그래서 전체 리팩토링을 해야겠다고 생각했어요. 기존에는 Next.js 페이지 라우터로 되어 있는데, 그걸 이제 앱 라우트 14 버전으로 완전히 처음부터 만들고 있어요. 그리고 PEC 에서 FSD(Feature Sliced Design)에 대해 배웠던 걸 기능 중심으로 적용하고 있습니다. UX 관점에서도 좀 더 기능을 다시 해가지고 완전히 FSD는 아니지만 부분적으로 적용을 하고 있어요. 또한, 저희가 처음에는 생각 못했던 부분들이 많이 있어서, 예를 들면 DOCS도 필요하고 이슈 관리하는 것들도 필요해요. 이런 것들을 모노레포로 할 것인가, 멀티레포로 할 것인가 고민 중이에요. 회사가 커질 것 같아서, 완전히 커지기 전에 이런 구조를 잡으려고 합니다. Q: Product Engineer Camp(P.E.C)를 통해 어떤 변화를 경험하셨나요? A: PEC를 통해 가장 크게 바뀐 부분이 두 가지가 있어요. 개발적으로 하나랑, 태도적으로 하나요. 그 중에 하나가 사용자의 이야기를 듣는 것이 문제 해결의 출발점이라는 거였어요. 이게 정말 저에게 충격적이었거든요. 개발자다 보니까 소통을 못한다는 틀에 갇혀 있었는데, 이제는 그렇지 않다는 걸 깨달았어요. 사실 PEC 첫 1주차 수업을 들었을 때 바로 깨달은 건 아니에요. 듣고 나서 시간이 지나면서 자꾸 생각이 나더라고요. 그러다보니 캠프가 끝나고 현업에 돌아와서 앞으로 계획을 잡는 데 엄청 도움이 많이 됐습니다. Q: "무엇을 개발할지"를 계획할 때 P.E.C 가 어떻게 도움이 되었나요? A: 저희 회사에서 고객사분들께서 제품에 대한 피드백이나 개발 요구사항을 주시는 경우가 많이 있어요. 이 요구사항들을 처리할 때 기존에는 이슈로 등록하고 수정하는 것을 프로젝트 버그 수정 정도로만 생각했었어요.