위코드 기업협업 회고 (feat. 기업협업에서 배운 것)

 

위코드 기업 협업 회고

 

길다면 길고 짧다면 짧은 3개월의 위코드 수료 기간이 끝났다. 지금은 위코드 수료식을 하고 난 후 5일이 지난날이다.
흐름상 사실 <위코드 회고>가 되어야 하지만 배운 것도 많고 우당탕탕 참 행복하게 지냈던 한 달 간의 기업 협업을 회고해보려고 한다.
최근에 당근 마켓의 동근님께서 진행한 세션을 들었는데, 회고를 하는 것이 참 중요하다고 하셨다. 일단 뭔가 끝나고 나면 후련한 마음으로 그동안 미뤄두었던 단잠도 충분히 자고 휴식을 취하게 되기 때문에 회고를 쓰려고 마음먹기가 정말 힘들다. 그래도 좋은 경험을 했는데 그 귀한 경험들이 휘발되는 것이 아까워서 비교적 빠른 시일 내에 작성하게 되었다.

그럼 즐겁고 보람찼던 기업 협업에서 나는 무엇을 배웠을까?

 

 

소통의 중요성: 할 수 있는 만큼만 하자, 그렇게 해도 안 죽는다.

한 달 동안 해당 기업에서의 목표는 베타 서비스를 배포하는 것이었다. 할 건 너무 많고 그렇다고 우리가 그걸 며칠 만에 쳐낼 수 있는 경력자들은 아니니 아득했다.
Backlog를 살펴보니 수정하고 구현해야 할 것들은 한가득이었다. 다들 너무 부담 가지지 말라고 했지만 처음엔 '그래도 하라고 했는데 어떻게든 다 해야 하는 거 아냐?'라고 생각했다. 뭐 어느 정도 맞는 말이긴 하다. 최대한 그 기간에 맞춰서 작업을 진행하다 보면 어떻게든 맞춰지기도 하고 비슷한 기간 내에 완성될 확률이 높기 때문이다. 그런데 여기서 중요한 건 그렇게 부담을 가질 필요가 없다.

 

쫓기듯 얼레벌레 하고 있는 나 자신을 발견했다

 

안 하고 놀아도 된다는 그런 가벼운 얘기가 아니다. 할 수 있는 만큼만 하자는 거다. 기업 협업 초반에 '할 수 있는 만큼'을 하지 않고 스스로를 독촉하고 계속해서 떠밀고 쫓기듯이 작업을 하려고 했다. 그렇다고 해서 일을 많이 한 것도 아니다. '할 수 있는 만큼' 하기 시작했을 때와 비교하면 천지차이다. 오히려 즐기면서 '할 수 있는 만큼' 할 때부터 많은 일을 해낼 수 있었다.
할 수 있는 만큼은 대체 얼마큼일까? 내가 할 수 있는 만큼.

 

 

비유를 하자면 핸드폰을 사용할 때 아예 방전될 때까지 써버리면 핸드폰이 충전되어 사용할 수 있을 때가 될 때까지 많은 시간이 걸린다. 또한 방전될 정도로 휴대폰을 사용하면 그만큼 휴대폰에도 큰 부담이 되어 배터리 성능이 좋지 않다고 한다. 그러면 충전될 때까지 오래 기다려야 하고 휴대폰 배터리 성능이 낮아졌으니까 앞으로 전보다 더 오래 못쓰게 될 거다. 유튜브에서 다양한 해외 멘토들이 이야기하는 하루에 할 일을 7~80%만 달성하라는 이야기와 동일하기도 하다.
눈치챘겠지만 이를 사람한테 대입하면 어떻게 될까? 예상이 될 것이다. 번아웃이 오고 지쳐서 더 이상 태스크를 진행할 수 없고 업무는 짜증만 나고 그만큼 해두지 못해 스트레스와 압박감이 느껴진다. 그래서 내가 할 수 있는 만큼만 해야 한다.

나는 내가 할 수 있는 만큼을 내 업무를 모두 처리하고도 팀원들을 도울 수 있는 힘이 남아있는 정도로 정했다.

근데 여기서 의문이 들 것이다. 내가 할 수 있는 만큼만 해도 돼요? 일단 기업 협업만 경험해본 내가 이야기하자면, '그렇다'이다. 각 회사의 모든 분들도 이렇게 생각하지 않을까 싶다. 어차피 주니어들에게는 그렇게 큰 기대감이 없다. 애초에 많은 양의 업무를 몰아주지도 않을 것이다. 그래도 주니어들에게는 너무나 버겁지만 (ㅠㅠ) 그럼에도 불구하고 해내는 방법은 내가 할 수 있는 만큼 하는 것이다.
할 수 있는 만큼 하는 법은 알겠는데, 그럼 할 수 있는 만큼만 하겠다고 이야기해야 하지 않나? 싶을 거다. 이게 소통이 꼭 필요한 지점이다.

 

이거 우리가 다 할 수 있을까..? 어떡하지?

업무 태스크가 너무 많아서 압도된 나머지 팀원인 해수님과 함께 준식님께 따로 면담을 부탁드렸다. 무리해서라도 야근을 하고 어떻게든 해내야 하는지(사실 그렇게 해서도 해결이 될 문제는 아니었다), 할 수 있는 만큼만 해야 하는지 여쭤보니 준식님께선 개발자에게 항상 소통이 중요하다고 말씀드렸던 부분이 이런 부분이에요 하고 웃으며 말씀해주셨다. 그때 '아하' 싶었고 기간 내에 업무를 모두 처리하기에는 무리가 있으니 중요도에 따라 업무를 처리하겠다고 말씀드리고 회사 직원분들과 함께 소통해보라고 추천해주셨다.
사실 기업 협업 간 회사에서 대표님이 그렇게 딱딱하거나 무작정 밀어붙이시는 분도 아니었는데 왜 그때는 해야 할 일들에 압도되어 이야기해볼 시도조차 못했을까? 다음 날 출근해서 프론트엔드 팀원분들과 함께 해당 이야기를 나눈 뒤 팀원분들과 함께 대표님께 이렇게 말씀드렸다.

"저희도 욕심이 있어서 이 모든 것을 다 끝내고 나가고 싶지만 아시다시피 저희가 이 모든 것을 쳐내기에는 무리가 있다, 괜찮으시다면 여기서 중요도에 따라 나눠 주신다면 중요한 것부터 해결해나가겠다" 고 말씀드리니 흔쾌히 그렇게 하자고 하셨다.
그래서 직원분과 함께 Backlog에서 서비스에서 가장 중요한 부분을 작성해둔 텍스트를 파란색으로 지정하고 각자 맡아서 업무를 진행했다.
업무를 진행하다가 blocker가 생겨도 팀원들과 함께 고민하고 의논하는 시간들이 정말 값졌다. 다양한 의견들이 오가고 그중에 해결책이 나와 해결하는 일도 수십 번이었다. 할 수 있는 만큼 하고 내가 못하겠는 것은 확실하게 팀원들에게 공유했다. 계속해서 나의 업무 진행상황을 매일 아침 스탠드 미팅 때마다 이해가 쉽도록 설명하는 등의 모든 일들은 나를 더 좋은 개발자로 더 성장시키는 데 큰 역할을 했다.

이렇게 하니 스스로의 부담도 줄어들고 팀원들과 더 좋은 팀워크를 갖게 되고, 할 수 있는 만큼만 진행하니 팀원들의 blocker도 해결해줄 수 있었다. 다음 날이 기대되고 업무를 해결하고 진행해나갈 때마다 즐거웠다. 할 수 있는 만큼만 한다는 것, 그리고 용기 내어서 공유하고 소통한다는 것은 개발자에게 가장 중요한 스킬이라고 생각되었다.

 

 

소통의 중요성 번외 편: 백엔드와 소통하기

백엔드분들과 프론트의 Mock Data를 맞추는 것이 유독 쉽지 않았다. 서로 바쁘기도 했고 백엔드 작업을 하시는 회사 직원분은 자주 회사에 못 나오시고 재택으로 업무를 진행하시는 상황이라 준식님의 피드백으로 노션에 하나의 페이지를 생성하여 데이터 구조를 공유하는 방식을 택했다. 노션 페이지를 프론트엔드 수연님께서 만들어주셨고 해당 Mock Data를 공유하고 이해가 쉽도록 캡쳐 화면과 데이터 구조 및 설명을 덧붙였다.

 

Assign에서 내 이름 하나만 예시로 보여주기 위해 가리지 않았고, 회사와 관련된 내용은 모두 모자이크 했다.

 

슬랙으로 내용 공유하기

 

구조가 복잡해서 다양한 API가 쓰였는데 헷갈리는 부분도 많았어서 프론트엔드 팀원분들 또한 함께 내용을 채워가 주셨고 백엔드 팀원분들도 확인해가며 내용을 채워 넣고 데이터를 수정해주셨다. 함께 차곡차곡 쌓아갈 수 있었어서 감사했다. 빛나는 협업의 과정이었다 ✨

 

 

문제 해결 방법: 단계별로 쪼개서 생각하자.

기업 협업을 진행하면서 스스로 느낄 정도로 정말 많이 성장했다. 생각도 더 넓어졌고 기술면으로도 전보다 성장했다고 자부한다.
기업 협업이 종료된 후 곰곰이 생각을 해보았다. '나 그래도 해야 할 일들에 blocker가 생겨도 묵묵히 직접 해결해냈었어, 팀원들의 blocker도 함께 고민하며 아이디어를 줄 수 있었고 좋은 코드를 작성하기 위해 고민한 시간들이 많았어.'라고 말이다.
사실 2차 프로젝트 때도 그러했지만, 정말 모든 것을 내 힘으로 해내고 싶었다. (그때의 내 심정, 아니 2차 플젝 후기 보러 가기)
그런데 그때 나는 다양한 분들의 도움을 받아 구현해낸 것이 많았다. 그 박탈감(?)이 참 컸다. 나도 누군가에게 도움을 주고 싶은데 왜 도움을 받았을까? 나 홀로 바로 서기를 하고 싶다. 더 강해지고 싶어(이글이글)이라고 생각했는데 기업 협업 때 그 목표를 일정 부분 이룬 것 같아 기분이 좋다.

 

생산성과 관련한 좋은 내용이라고 생각한다.

 

어떻게 해냈지?라고 생각해보니 앞서 언급했던 '할 수 있는 만큼' 하기, 그리고 '단계별로 쪼개서 생각하기'이다.
기업 협업 도중 도무지 해결이 되지 않는 문제가 있었고 다른 곳에 기업협업 가 계신 동기분께도 저녁에 질문을 드렸던 기억이 난다.
2차 프로젝트 때 문제와 한정적인 시간에 압도되어 조급해하고 힘들어했던 내가 떠올랐다. 별 거 아닌 문제에 조급해해 종택님께 "많이.. 마음이 조급하세요? 괜찮아요."라는 말도 듣곤 했다.

결국 모든 문제는 다 해결하라고 존재하는 것이고, 언제나 내 안에 해결책이 있다.
언제나 그러했듯 잘하는 사람들을 많이 관찰하고 그들의 문제 해결 루트를 보면 해답이 있을 것 같았다.
나는 항상 처음 코드를 짤 때 가장 좋은 코드를 써내고 싶었다. 그런데 그건 거의 불가능하다. 클린 하게, 가장 최선의 방법으로 작성하고 싶다는 욕심에 방황이 조금 찾아왔을 때 처음 위코드에서 참여했던 자바스크립트 QnA 세션 녹화 영상을 다시 찾아보았다. 1시간 반이 넘는 시간의 세션은 그 당시 전혀 지루하지 않을 만큼 값졌었기 때문이다. 그리고 문제 해결 능력에 대해 종택님이 예시와 함께 언급해주셨던 영상이다.

 

나는 거기서 해답을 다시 찾았던 것 같다.

동기분들의 질문을 받아서 문제를 해결해나가는 과정을 설명해주셨고 그 안에서 수 없이 강조하신 내용은 이거다. '단계별로 쪼개서 생각하기'. 그래야만 내가 어느 지점에서 막혔는지 스스로 인지하게 된다. 어느 지점에서 어떤 부분에 대해 막혔는지 알게 된다면 이제 그때부터는 그 부분을 구글링 하거나 해결 방법을 고민해보면 되기 때문에 해결 방법에 도달한 거나 마찬가지다.
결국 뭔가 막혀서 해결을 하지 못하는 건 내가 어디서 어떤 게 문제인지 몰라서라는 생각이 들었다. 어떤 문제가 있는지, 어느 지점에서 막혔고 왜 안되는지 치열하게 고민해보아야 한다. 이를 통해 문제를 해결해나가면서 다양한 에러 메시지들이 왠지 즐거운 숙제처럼 느껴졌고 내가 해결하는 부분에 있어서는 어느 정도의 문제 해결 방식의 패턴이 보였다. 그렇게 하니 더 재밌어졌다.
팀원분들이 막힌 부분을 함께 고민하고 해결해나가는 과정이 즐거웠고 자신감도 생겼다.

무언가 막힌다면, 내가 구현하려는 것을 순서대로 노트에 작성하기.

예)
1. 사용자가 홈페이지를 들어온다.
2. 모달이 띄워진다.
...

이런 식으로 작성하고 할 수 있는 부분까지 해낸 뒤 나머지는 구글링을 통해 해결해나간다.
이렇게해도 막연하다면 내가 구현하려는 것을 그림으로 그려보고 머릿속으로 구상을 한다. 모든 내용을 '컴포넌트'로 생각하면 더 쉽다.

에러가 발생해도 동일하다. console.log를 통해 단계적으로 접근해본다. 데이터가 들어오지 않는다면 타입이 잘못된 건지, 객체에 잘못 접근해서 부른 건지 추론해보아야 한다. 대부분 에러 메시지에 힌트가 있다.

 

 

개발이 아닌 서비스 전체를 바라보기: 나는 개발을 하는 사람이 아니라, 문제 해결을 하기 위해 이 일을 하는 사람이다.

 

 

많이 들어보았을 흔한 이야기이지만, 사내 엘리베이터가 내려오는 속도가 느려서 직원들의 불만이 커지자 이를 해결하기 위해 개발자들이 머리를 싸맸다. 몇몇 사람들은 기술적으로 접근해 좀 더 엘리베이터의 속도를 빠르게 하자고 의견을 냈고 어떤 사람은 엘리베이터 외벽에 거울을 붙이자고 의견을 냈다. 후자의 방법을 택했을 때 오히려 엘리베이터를 이용하는 직원들이 엘리베이터의 속도가 더 빨라졌다고 느꼈다고 한다.
그렇다면 여기서 엘리베이터의 속도를 빠르게 하기 위해 사용될 인력과 기술을 택하는 대신 거울 하나 붙여서 문제를 해결했다면, 모두가 행복할 수 있는 방법이 아닐까? CEO는 문제가 해결되었을 뿐만 아니라 금전적으로 낭비되지 않았으니 좋고 개발자들은 엘리베이터 속도를 빠르게 하기 위해 머리 쥐어뜯으며 고민하고 개발할 일이 없어지니 좋다. 엘리베이터를 이용하는 직원들은 엘리베이터를 기다리면서 거울을 볼 수 있고 그와 동시에 엘리베이터가 느리다는 느낌을 받지 않을 수 있으니 사용자 측면에서도 좋은 성과다.

개발을 막 처음 입문하기 시작했을 때 이 내용을 보고 '맞는 말인 것 같지만 왠지 멋이 없군(?)'이라고 생각했다. ㅋㅋㅋㅋㅋㅋㅋ
그런데 기업 협업을 모두 끝낸 후 이 이야기가 생각났다. '그래서 그런 이야기가 있었구나.'

 

5번 주목

 

개발자가 개발만 잘하면 안 된다. "아, 그럼 뭐 기획도 하고 디자인도 하고 다 합니까 진짜"라는 말이 목구멍까지 차오르겠지만 막무가내로 일을 다 하라는 의미는 아니다. (아니겠지?)

적어도 하나의 서비스를 만들기 위한 개발자로서 업무를 진행하고 있다면 서비스 전체를 생각할 수 있어야 한다는 것을 느꼈다.
전에는 그런 비즈니스적인 부분까지 내가 생각해야 하나 싶어서 이런 말들이 와닿지 않았는데 기업 협업을 경험하면서 다양한 부분을 함께 신경 쓸수록 더 좋은 서비스가 나온다는 걸 알았다.

왜 자꾸 기획 부분을 문서화하지 않는 건지, 정해놓고 왜 자꾸 바뀌는데 이 것도 왜 정리가 안되지? 하는 부분들도 대표님과 마지막에 이런 부분에 대해 이야기 나눠보면서 깨달았다. "기획자 한 명이 혼자 정한 내용은 구려요." (정말 구려요라고 하셨다)
문서화를 좋아하지 않는 이유가 서비스의 퀄리티가 좋지 않아 지기 때문이라고 하셨다. 문서화해서 정해 놓다 보면 '이건 이렇게 하는 게 어떨까요?'하고 계속해서 아이디어를 낼 판이 만들어지지 않는다고, 개발자의 시각으로 보는 서비스 또는 디자이너의 시각으로 보는 서비스가 있기 때문에 다양한 의견을 서로 나누고 그중에서 가장 좋은 아이디어로 수정 반영하는 게 좋은 서비스로 가는 길이라고 말이다.
문서화가 아예 나쁘다고 하신 건 아니었다, 또한 회사 내에서도 문서화가 아예 안된 것도 아니었으나 더 상세한 부분을 건의드렸던 건데 이러한 답변을 주셨고 많은 생각을 하게 되었다.
그리고 이 부분은 내가 한 달 동안 기업 협업을 진행하면서도 많이 느꼈다. 나도 개발을 하면서 다양한 방면으로 생각하게 된 것이다.
그저 그냥 그렇게 찍어내려고 하는 게 아니라 서비스를 전체적으로 생각하며 작업을 진행하니까 개발을 대할 때 부담도 덜 했고 더 좋은 서비스를 만들려고 생각을 넓히는 스스로를 발견했다.

개발자는 서비스를 바라볼 때도 기술적인 부분만 보는 게 아니라 디자인적인 요소, 사용자가 흐름상 불편한 부분이 없었는지에 대해 생각해보아야 한다.

 

나무를 보지 말고 숲을 보자

 

기획자도, 개발자도, 디자이너도 가장 최고의 서비스를 사용자에게 제공하기 위해 힘쓴다. 코앞의 당장 닥친 태스크를 처리하기 위해 아등바등할 게 아니라 더 넓게 보기 위해 시야를 확장시켜야 한다. 쉽지는 않겠지만 나무 하나하나를 디테일하게 살펴보면서도 숲 전체가 이러한 디테일로 인해 조화롭고 서비스의 의미와 상충되는지 항상 생각해보아야 할 것이다.
나뭇잎을 디테일하게 그리다가도 서비스를 한번 더 살펴보며 구현해나가는 그런 개발자가 되고 싶다.

 

 

마무리도 알차게

 

 

마지막으로 프론트엔드 수연님께서 따로 연락하는 일을 미연에 방지하기 위해 인수인계 카드를 작성해달라고 하셨다.
최대한 다음 기수분들과 수연님이 내가 진행했던 업무들을 도맡아 하실 때 이해하는 것이 쉽도록 최선을 다해 작성했다. 다행히도 도움이 되었다고 말씀해 주셔서 감사했다.

 

 

진짜 글 마무리

이런 다양한 경험을 기업 협업을 통해 약 한 달 동안 진행해볼 수 있었음에 진심으로 감사하다.
프로젝트만 진행했다면 겪어보지 못했을 일들이다. 수많은 경험을 할수록 시야가 넓어지고 내가 할 수 있는 것들도 많아진다.
두려워하지 않고 많이 부딪혀보고 코드 앞에서 좌절도 많이 해보고, 다양하게 시도해보면 앞으로도 더 성장하리라 믿는다.
컴퓨터는 항상 거짓말을 하지 않으니까 문제에 있어서 압도되지 말고 편안한 마음을 가지고 차분하게 해결해나가자~!