당근알바 팀에서 인턴으로 일한지도 어느덧 7개월이 넘었다. 이제 정말 퇴사까지 한달 정도를 앞두고, 정리를 하나씩 해보고 있다.
이 기간은 정말 많은 것들을 배우고 느낄 수 있는 시간이었지만, 누군가 나에게 이 과정에서 가장 큰 수확이 무엇이냐 묻는다면
프로덕트 팀에서의 나만의 워크플로우를 확립한 것이라 대답할 것이다.
요즘은 특히 여러 이슈를 동시에 처리하는 과정에서 내가 잘 챙기지도 못하고 있는 것 같아 글로 쓰면서 다시 한번 되새기고자 한다.
프로덕트 팀의 특성과 요구되는 역량에 대해
어떤 팀이냐에 따라 다를 수 있겠지만 내가 느낀 프로덕트 팀의 특성을 정리해본다.
프로덕트 팀은 사용자에게 제품을 전달한다. 따라서 사용자가 잘 사용하고 좋아하는 제품을 만들어야 한다.
하지만 사용자가 어떤 것을 좋아할지는 사용자조차도 모른다!
어떤 것을 좋아하는지는 인터뷰를 통해 얻을 수도 있지만, 제품을 사용하는 과정에서 데이터로 드러나기도 한다.
따라서 메이커들을 데이터를 기록하고, 확인하고, 결정해야한다.
로그에 대해
이런 관점에서 프론트엔드 개발자는 꽤 중요한 역할을 한다.
기능을 봤을 때 어떤 것을 기록해야 더 발전시킬 수 있을 것인가는 논의를 통해 결정하기도하지만,
특수한 경우를 제외하고는 프론트엔드 개발자가 설계하거나 결정해야하는 경우가 많다.
개발에 대해
이렇게 데이터를 모으고, 변경하고 제품을 발전시키기위해서는 개발의 속도가 빨라야한다.
하지만 그것이 작업물의 퀄리티를 낮춘다는 것도, 코드의 퀄리티를 낮춘다는 것을 의미하지는 않는다.
복잡하거나 대규모 기능의 경우 QA를 진행하고 배포하게되지만, 대부분 작업의 퀄리티는 개발자가 보증할 수 있어야 한다.
대부분은 QA 맥락 공유 자체가 리소스가 되기에 이런 경우가 많다.
코드 퀄리티도 잘 챙겨야한다. 여기서 퀄리티란 어떤 복잡한 설계라기보단 읽기 쉬움에 가까운 것 같다.
자주 변경되므로, 더 읽기 쉬운 코드를 작성해야 한다. (Easy To Change!)
코드만으로 맥락을 담지 못한다면 그것은 이후에 반드시 나나 다른 사람의 실수로 이어진다.
사람은 실수를 한다.
빠르고, 정확하게, 그리고 데이터를 적절히 수집하도록.
그것이 프로덕트 팀의 기능을 구현하는 개발자에게 요구되는 역량이라 생각한다.
내가 일하는 방법
짝 프로그래밍이 효과적인 이유 중 하나는 한명은 큰 관점에서 문제를 바라보고, 한 명은 작은 코드 관점에서 문제를 바라보기 때문이다.
하지만, 시간과 자원의 문제로 일을 나눠서 하는 것은 힘들다.
나의 워크플로우는 개발하기전의 나와 개발하는 나와 이후 확인하는 내가 일종의 짝 프로그래밍을 하는 형태로 수행하는 방식이다.
개발하기 전에
1. 스펙에 대한 올바른 이해
이 스펙이 왜 필요한 것인지, 어떤 것들이 추가되는 것인지 명확하게 이해한다.
이 과정에서 유저에게 더 좋은 경험을 줄 수 있는 부분이 있다면 의견을 제시하고, 개선한다.
2. 파악하면서 누락된 것은 없는지
피그마를 읽으면서 어떤 것이 변경되는지 추가되는 것인지를 문서로 작성하고
완료되면 피그마와 비교하면서 한 번 더 확인한다.
3. 더 필요한 것들에 대해
자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다. 프로그래머는, 즉 우리의 일은 사람들이 자신이 원하는 바를 깨닫도록 돕는다. 이게 우리의 가치가 가장 빛나는 부분이다.
- 실용주의 프로그래머
피그마와 지라 이슈를 보면서 빠진 엣지케이스나 조건, 상황에 대해 생각해보고 팀원과 소통해서 스펙에 필요한 것들을 챙긴다.
4. 데이터 기록을 위한 고민
이 기능이 배포되고 사용자의 데이터를 수집한다고 했을때
얻을 수 있는 인사이트는 어떤게 있을지 고민하고, 적절하게 로그를 설계한다.
5. 개발을 위한 이정표 작성하기
이 시점의 나는 짝 프로그래밍의 네비게이터로써 미래의 드라이버인 내가 코드 작성에만 집중할 수 있도록 돕는다.
공통 기능을 만든다면 과도하게 열린 인터페이스보다는 추상화된 간소한 인터페이스를 지향한다.
코드를 들여다보며, 설계와 방향성에 대해 고민하고 이에 대한 것들을 문서로 작성한다.
6. 태스크 체크리스트 작성하기
스펙에 대한 문서를 작성완료했다면, 기능이 올바르게 동작하기위한 체크리스트들을 작성한다.
최대한 많은 케이스에 대해 대응할 수 있도록 작성한다.
자세하게 작성하면 작성할수록 체크리스트 확인이 끝났을때 자신감을 갖고 배포할 수 있게된다.
개발할 때
개발하기전에 설계나 구성에 대한 고민은 이미 완료했으므로
개발할 때는 드라이버로서 작은 관점의 문제들을 주로 해결한다.
1. 엣지케이스
단순히 타입상의 엣지케이스를 넘어 스키마나 api상 데이터에서 문제가 발생할 수 있는 경우를 생각하고 처리한다.
2. 코드의 일관성
코드의 일관성을 지킨다는 것은 단순히 팀 컨벤션을 지키는 것을 넘어, 컨벤션이 정해지지 않은 부분에 대해 자신만의 일관성을 지키는 것이다.
더불어 코드를 수정하는 경우에는 수정 파일에 대한 지역적인 일관성을 맞춰서 개발한다.
변수 이름을 넘어 한 줄의 띄어쓰기에 대해서도 코드를 작성하는 일관성을 지키기위해 노력한다.
개발을 마치고
코드 작성이 끝났고, 올바르게 동작하는 것 같다면 이제 50% 완료된 것이다.
1. 테스트와 검수
이정표를 작성할때 작성한 체크리스트를 하나씩 체크해가며 추가된 모든 기능에 대해 테스트한다.
기능에 대한 테스트를 개발자가 하지 않으면, 테스트는 유저가 하게된다.
UI에 대해서는 pixel pro와 같은 브라우저 확장 프로그램으로 figma에서 export한 이미지를 overlay해서 검수한다.
이렇게 하면 패딩, 마진 등 육안으로 체크하기 어려운 부분들을 직관적으로 확인할 수 있다.
2. 셀프리뷰
스스로 작성한 코드를 PR을 살펴보며 어떤 것들을 내가 변경했는지 확인하며
일관성이 잘 챙겨졌는지, 더 개선할 수 있는 부분들은 없는지 확인한다.
Github pull requests extension을 사용하면 IDE에서도 보기 쉽게 확인할 수 있다.
그냥 속으로 살펴보기보다는 코드에 대해 직접 말로 설명하면서 확인하면 더 놓치는 것 없이 체크할 수 있다.
또한 이 과정을 녹화를 한다면 셀프피드백과 AI피드백이 가능하게된다.
기능 개발이 끝나고
1. 회고
이상까지의 과정을 되돌아보고 더 개선할 수 있는 점이 없는지 확인한다.
셀프 피드백을 통해 워크플로우를 개선하며 성장한다.
2. 자동화
개발하면서 불편했던 것들을 자동화 할 수 있다면, 이슈로 만들고 다양한 방식으로 자동화한다.
단순한 스크립트부터 어드민 DevTool, eslint custom rule, webpack plugin등 방법에 종속되지 않고 다양한 시도를 해본다.
발전 방향에 대해
요즘은 AI가 도입되면서 개발할때의 과정, 자동화과정을 더 잘 챙겨줄 수 있게 된 것 같아서,
우선은 AI 도구를 사용해보면서 개발할때의 과정을 대체해보는 과정을 수행해보고 있다.
아직 시행 착오가 많지만, 이 부분에 대해서도 학습을 통해 발전시켜볼 것이다.
