2024년 7월 15일부터 10월 14일까지 팀스파르타에서 웹 퍼블리셔로서의 인턴 생활이 마무리 되었다. 3개월 간 무엇을 했는지, 무엇을 배웠는지, 무엇이 부족했는지를 돌아보고 이를 바탕으로 앞으로의 방향성을 생각해보자.
3개월 간 무엇을 했는가
내일배움캠프(이하 내배캠)팀에 합류하여 크게 두 가지의 업무를 진행했다. BAU와 Non-BAU로 나눌 수 있겠다.
BAU: 내배캠 랜딩 페이지 디벨롭
* 프론트, 백, 데이터, AI, UXUI 등 내배캠 트랙 각각의 랜딩 페이지의 부분 부분을 상황에 맞게 수정하고 디벨롭했다.
* 할당 받은 태스크의 기획 문서를 보고 어떤 문제를 해결하기 위해, 혹은 무엇을 그로스하기 위해 랜딩 페이지의 디자인이 변경 되었는지 확인 후, 해당 작업을 디자이너 분께서 완료해주시면 피그마 시안을 받아 UI 요소를 코드로 구현했다.
* 구현이 완료되면 디자이너와 PM 번께 QA를 요청 드리고 피드백이 있다면 수정하는 과정을 거친다. 해당 디벨롭 사항이 배포되기 전 코드리뷰를 받은 후 수정이 완료 되면 실배포
Non-BAU: 내배캠 랜딩 시스템 패키지
* 내배캠 팀에서 사용하는 랜딩 시스템 패키지를 구축했다. 내배캠 팀에서 위의 BAU 작업이 굉장히 많은데 여기에서 드는 리소스를 절약하고 효율을 높이고자 시작된 프로젝트이다.
받은 피드백
인턴십을 통해 배운 점
스타트업 문화에서의 실무 경험
실무 경험을 해보았다는 것 자체가 큰 경험 자산이 되었다. 실제 비즈니스 환경에서 일을 하면서 스스로 공부를 하면서는 배울 수 없는 것들을 많이 배웠다.
우선 굉장히 빠르게 성장 중인 스타트업인 팀스파르타에서 실무를 경험해볼 수 있어서 좋았는데, 빠르게 성장하는 기업인 만큼 그 안에서의 태스크 처리도 빠르게 진행되고 있었다. ‘빠르게’는 팀스파르타가 일하는 방식 중 첫 번째로 내세우는 만큼, 빠르게 만들어보고 빠르게 피드백 받아 빠르게 수정하여 디벨롭 해나가는 방식을 추구한다. 팀스파르타에 속해 있는 3개월만큼은 나도 그러한 기업 문화에 맞추어 일할 때의 속도를 생각하면서 3개월을 보냈다.
‘빠르게’ 일하면서 겪은 시행착오는 아래 ‘ETA 지키기’에서 이어서 기록하겠다.
실무을 경험하면서 배운 다른 한 가지는 일상에서의 커뮤니케이션과 일터에서의 커뮤니케이션은 다르다는 것이다. 물론 커뮤니케이션이라는 부분에서 공통적인 부분이 더 많겠지만 일터에서의 소통을 잘 하려면 일을 할 때의 맥락을 잘 파악하는 것이 중요하고, 그 문화와 팀에서 자주 쓰는 표현을 적절히 사용할 줄 알면 훨씬 원활한 소통이 가능하다는 것을 배웠다.
우선 소통에서의 맥락을 잘 파악하려면 일을 할 때에 ‘왜’ 이 일을 해야 하는지에 대한 이해가 있어야 할 것이다. 이 부분에서는 결국 수동적인 스탠스로 일하는 것이 아닌 능동적으로 일하는 태도가 필요하겠다.
팀스파르타에서는 슬랙으로 소통을 했는데, 처음에는 슬랙 메시지 하나 쓰는 것도 너무 어려웠다. 어떤 단어를 써야 할지, 어떤 말투를 써야 할지 사소한 것 하나도 메시지를 보내기 전 몇 번씩 생각을 하고 보냈다. 예를 들어, 피그마 시안을 보고 작업을 하는데 사용해야 하는 이미지의 레이어가 애매하게 나누어져 있어 작업하기 어려운 상황이다. 이 문제에 대해 디자이너 분과 소통을 하려 하는데 개발자가 레이어에 대한 개념이 없으면 디자이너 분께 요청을 드릴 때의 소통이 깔끔해지지 않는 것이다. 이런 부분에서 다른 팀의 언어도 이해하는 게 중요하다고 생각했다.
ETA 지키기
ETA(마감 기한)를 잘 지키는 것부터가 신뢰의 기반이 되기 때문에 나의 신뢰를 지키기 위해서라도 ETA는 반드시 지키려고 했다.
더구나 일이 빠르게 진행되는 팀스파르타라는 조직 안에서도 태스크가 많아 더욱 속도감 있는 작업이 필요한 팀에 소속되어 있었기에 일에서의 속도를 내고 ETA를 지키는 일은 더 중요했다.
하지만 첫 2주 간은 태스크의 ETA를 지키는 것이 너무나 어려웠다. 어느 태스크는 작업 시간이 내가 예상했던 것보다 길어져서 ETA를 넘기게 되었고 PM님께 양해를 부탁드리기를 2-3번 반복한 후에 겨우 마무리되어 배포가 늦어진 건도 있었다.
이 날은 PM님께도 죄송하기도 하고, 약속을 지키지 못한 스스로에게 너무 화가 나기도 했는데 그 태스크를 회고하면서 문제가 무엇이었는지 파악하고 개선점을 찾아나가면서 스스로 크게 발전할 수 있는 계기가 되었다.
그 후로는 매일 work log를 작성하면서 매일 해야 할 일을 작은 단위로 쪼갠 후 각각 태스크의 예상 시간과 실제 걸린 시간을 비교하며 어떠한 일을 할 때에 내가 걸리는 시간을 파악해 나갔다. 그렇게 하니 먼저 ETA를 제시할 때에도 더 정확하게 말씀 드릴 수 있게 되고 후로는 ETA를 지키지 못하는 일은 없게 되었다.
기록과 회고
아쉬운 점
* 인턴 초반에 가장 어려웠던 부분은 각 태스크의 ETA를 지키는 일이었다.
앞으로 이렇게!
'회고' 카테고리의 다른 글
Keepy-Uppy 프로젝트 회고 (0) | 2024.12.02 |
---|---|
The-Julge 프로젝트 회고 (1) | 2024.12.02 |
Rolling 프로젝트 회고 (1) | 2024.11.27 |