Product Engineer Camp 1주차 세션 회고

woohyuk·2024년 4월 21일
0
post-custom-banner

Product Engineer Camp 참여 계기

회사에서 주어진 요구사항을 구현하다보니 드는 생각이 있다.
"기능을 구현하는데 있어서는 어려움이 없는데 나는 주니어 개발자로서 잘하고 있는걸까?" 라는 것이었고
비교적 최근 이러한 생각이 잘못 되었다는 것을 깨닫게 되었다.

나는 규모가 작은 스타트업에서 일을 하고 있고. 스타트업 특성상 빠른 성장과 확장을 목표로 하기에 프로젝트 단위에 일정이 촉박할수 밖에 없다. 물론 어떤 기업에 속한 개발자든 시간에 쫒긴다는 것은 숙명과도 같은 문제라고 생각하고 있고, 일정에 대한 조율이 필요한 부분도 있다고 생각한다.

아무튼 나는 데드라인에 맞춰 일을 끝내야 하기에 철저히 기능구현에 초점을두고 업무를 해왔었다.
그리고 최근들어 서비스의 규모가 점차 비대해지면서 아래와같은 문제점들을 발견할 수 있게되었다.

확장에 유연하지 못한 컴포넌트

컴포넌트를 확장성있게 만드는것은 추후 비슷한 기능을 가진 컴포넌트를 구현할 일이 생겼을 때 미리 만들어 놓은 컴포넌트를 확장해서 사용하면 되므로 작업시간을 단축시킬 수 있고, 코어기능을 수정해야 할 일이 생겼을때 하나의 컴포넌트만 살펴보면 되기에 유지보수하기에 편리한 점도 있다.

하지만 이러한 상황을 염두하지않고 컴포넌트를 만들어 가다보니 지금은 동일한 기능을 가지고있는 컴포넌트들이 몇몇 생겨나있는 상태이고, 이는 유지보수를 매우 힘들게 만들고 있다.

재사용하기 힘든 유틸 함수

함수를 작성할때 단일 책임의 원칙을 지키지 않아서 생긴 문제라고 생각한다.
기능구현을 위해 함수를 작성 할때 "이 함수는 이 기능에서만 사용되겠지"라는 어리석은 판단을 하였고 충분히 재사용이 가능한 로직에 만들고자하는 기능에 대한 로직을 결합시켜버렸다.

그렇기 때문에 이후에 동일한 로직이 필요한 기능에서 재사용을 할 수 없는 상황이 생겨버렸고, 동일한 로직이 여러 함수에 분포되어 있는 끔찍한 현상들이 몇몇 생겨났다.

폴더 구조 컨밴션의 부재

하나의 통일된 폴더구조는 프르젝트 코드의 흐름을 한눈에 파악하기가 쉽고, 수정해야할 파일을 찾는데 드는 시간을 절약할 수 있으므로 생산성이 증가한다.
서비스의 규모가 작을때는 생성되는 파일의 수도 적으므로 찾고자하는 파일을 추적하는데 어려움은 없었으나, 서비스가 커진 시점에는 파일의 수도 비례하면서 커졌기 때문에 정해놓지않고 시작한 컨밴션의 부재에대한 부채가 지금와서 눈에 보이기 시작한 것이다.

위에 나열된 문제점들은 결국 초기에 진행되어야 할 "설계"에 직결되는 문제들 이었고, Product Engineer Camp에서는 이러한 내가 가지고 있는 고민에 대해서 같이 논의하고 해결해 나갈 수 있을 것 같아서 참여를 결정하게 되었다.

Product Engineer 란?

AI 가 점점 더 빠르게 발전하면서, Frontend Engineer 가 하는 일의 많은 부분을 대체할 것이고 결국은 Ai가 대체할 수 없는 영역, 즉 user와 직접적인 소통을 통해 얻은 인사이트를 기술적으로 Product에 녹여내여 대체 불가한 Frontend Engineer가 되는 것을 목표로 한다.

1주차 세션 - 문제 정의

서비스를 만들때 제일 중요한 점은 "고객중심적사고"이다. 우리가 서비스를 만드는 이유는 명확하다. 사용자의 불편함을 개선해주고 사용자가 서비스를 이용하면서 좋은 경험을 느낄수 있도록 한다. 그러기위해선 사용자의 관점으로 서비스를 바라보는 시각을 기르는 것이 중요하다. 결국 사용자의 문제를 명확히 정의하고 이는 곧 문제해결에 대한 방향성을 제시하게된다.

반구조화 인터뷰 질문지 작성

반구조화 인터뷰는 인터뷰 질문이 일부 정해져있지만 대화 흐름에 따라 추가 질문을 할 수 있도록 유연성을 가지고 있다. 그러므로 답변이 정해져있는 질문보다는 답변에 따라서 추가적인 질문을 할 수 있도록 해야 하기에 이를 고려하면서 질문지를 구성할 수 있는 능력을 기를수 있었다.

사용자 인터뷰

반구조화 인터뷰 질문지를 통해 직접 사용자 인터뷰를 진행하였다. 처음에는 굳이 대화형식에 인터뷰를 꼭 진행할 필요가있을까? 라는 생각을 했었지만 직접 해보니 확실히 다르다는 것을 느꼈다. 사용자가 질문에대한 의도를 정확히 파악하지 못했을때 부연설명을 통해 답변을 이끌어 낼수도 있었고, 서로 상호작용을 통해 깊은 이해와 풍부한 내용을 얻어낼 수 있었던 것 같다.

페르소나 작성

인터뷰를 통해 얻어낸 정보들로 문제를 정의하는 과정이다.
각각의 조원들이 얻어온 인터뷰 내용들을 취합하면서 다양한 인사이트를 도출해낼 수 있었고,
하나의 페르소나를 완성시킬 수 있게 되었다.

아쉬웠던 점

세션에 대한 진행순서나 미리 학습해오면 좋았을 부분들에 대한 공유가 필요하다고 느껴졌다.
아무래도 생소한 과정들을 진행하다보니 세션시간에 잘 이해하고 따라갈려면 학습 자료를 미리 흝어 보는것이 도움이 될거라 생각했다.

profile
기록하는 습관을 기르자
post-custom-banner

0개의 댓글