brunch

You can make anything
by writing

C.S.Lewis

by ASH May 08. 2024

피그마, 회사 소개서, 개발 환경에서 벗어나세요

실제 프로덕트를 사용하세요

1.

'실제 프로덕트를 테스트 하기' 너무나 당연한 말이고 꼭 해야 하는 일이다. 그러나 막상 실무를 하다보면 실제 프로덕트를 테스트 하지 않는 경우가 많이 발생한다. 각자의 업무가 바빠서 혹은 각자 주로 사용하는 작업 툴이 달라서 그렇겠지만, 이는 핑계가 되지 못한다. 직군과 상관 없이 반드시 실제 프로덕트를 끊임없이 써봐야 한다.



2.

실무에서 실제 프로덕트를 테스트 하지 않는 것은 대략 이런 식으로 진행된다. 디자이너는 피그마를 바탕으로 프로덕트를 파악하고, 세일즈는 회사 소개서를 바탕으로 프로덕트를 파악하고, 개발자는 로컬 혹은 개발계에서만 프로덕트를 파악하는 식이다.



3.

이렇게 각자가 담당하는 파트의 자료를 보는 것은 필수지만, 각 담당자들이 이런 식으로만 프로덕트를 파악한다면 여러 문제가 생긴다. 첫 번째로 실제 프로덕트를 쓰며 유저들이 겪는 경험과 감정을 느낄 수 없다. 이는 유저를 정확하게 이해하지 못하게 만든다. 그래서 유저의 불편함을 모르고 있다가, CS 등을 통해 늦게 알아차리게 된다. 결국 프로덕트 개선 속도가 유저들의 사용 속도를 따라가지 못하는 것이다.



4.

두 번째로 프로덕트에 대한 각 팀의 이해도가 일치하지 않게 된다. 팀간 프로덕트의 이해도가 일치하지 않는다면, 자연히 업무의 우선순위를 조정하거나 앞으로의 로드맵을 그릴 때 서로 다른 그림을 그리게 된다. 이는 프로덕트의 로드맵을 전개해 나가는 데 있어 더 많은 논쟁을 야기하고, 하나의 목표를 보는 데 더 많은 시간을 투입하게 만든다.



5.

보통 회사 소개 자료는 프로덕트의 업데이트에 맞춰서 업데이트 되지 않는다. 보통 큰 변화가 생길 경우에만 업데이트가 된다. 프로덕트는 회사 소개 자료에서 말하는 것과 다르게 작동할 때가 있다. 그래서 회사 소개 자료에만 의존해 세일즈 혹은 비즈니스를 전개하면, 나중에 가서 세일즈 팀은 프로덕트 팀에게 "왜 이게 안되는 거죠?"라는 질문을 하게 되고, 프로덕트 팀은 "이러이러한 이유가 있습니다"라는 답을 할 수 밖에 없다.



6.

프로덕트 팀은 세일즈 팀에게 프로덕트에 변화가 생길 때마다 이를 꾸준히 이야기 해야 하고, 반대로 세일즈 팀은 프로덕트의 이해도를 회사 소개 자료에만 의존하는 게 아니라, 유저들이 쓰는 프로덕트를 실제로 써보면서 드는 궁금증이나 요구 사항을 자주 말해야 한다. 그래야 유저 혹은 고객사들이 원하는 기능을 빠르게 프로덕트에 구현하고 세일즈를 더 원활히 할 수 있다.



7.

디자인의 경우를 본다면, 피그마에서 완벽한 인터랙션 혹은 디자인을 구현했더라도 실제 프로덕트에서는 그렇지 않을 수도 있다. 피그마의 프로토타입 기능을 통해서 보는 것과 달리 실제 프로덕트에서는 인터랙션이 유려하지 않을 수도 있다. 또한 피그마에서는 완벽한 패딩과 마진을 설정했지만, 실제 프로덕트에서는 그대로 적용되지 않아, 예상치 못한 곳에서 줄바꿈이 일어나 디자인이 의도한대로 나오지 않을 수도 있다.



8.

그래서 피그마 화면만 보고 실제로 이렇게 구현이 되겠지 하며 해피 케이스만 생각하면, 실제 프로덕트에서 의도한 디자인이 구현되지 않을 수도 있다. 따라서 이를 방지하기 위해서는 실제 프로덕트를 써보면서 의도와 다른 부분을 찾아내고 이를 개발 혹은 디자인을 통해서 해소해야 한다. 보통 QA 기간에 이런 것들을 다 테스트 하지만 QA 기간에 모든 부분을 찾아내지 못할 수도 있으니, 항상 실제 프로덕트를 써봐야 한다.



9.

개발의 경우도 항상 실제 프로덕트를 실제로 써봐야 한다. 보통 개발은 로컬, 개발계, 검증계를 거쳐서 실제 프로덕트인 운영계로 올라간다. 로컬, 개발계, 검증계, 운영계의 환경이 전부 일치하는 것이 아니기 때문에 똑같은 기능을 배포해도 특정 환경에서는 작동하지만, 특정 환경에서는 작동이 제대로 되지 않을 수 있다.



10.

로컬, 개발계, 검증계에서 문제가 정상작동 하던 기능이 실제 프로덕트인 운영계에서 제대로 작동하지 않을 수 있다. 간단한 예시를 들어보자면, 핫픽스로 운영계에서만 이전에 배포한 코드가 신규 기능에 영향을 미쳐 이런 경우가 발생할 수 있다. 만약 검증계까지만 정상 작동하는 것을 확인하고, 실제 프로덕트를 확인하지 않는다면 이런 이슈를 잡아낼 수 없다.



11.

유저들은 회사 소개서, 피그마, 개발 환경의 프로덕트를 보지 않는다. 유저들은 세상에 릴리즈한 실제 프로덕트만 사용하고 경험한다. 그래서 유저를 이해하고, 유저와 가까워지고, 이들의 문제를 해결하기 위해서는 반드시 실제 프로덕트를 끊임없이 써봐야 한다. 또한 조직 내부의 얼라인먼트 기준은 반드시 실제로 나와 있는 프로덕트여야 한다. 그래야 모든 팀이 하나의 목표를 바라보며 프로덕트를 발전시킬 수 있다.






브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari