스타트업 개발팀에 사수가 없다는 것은?… 🤔

사수가 있는 회사를 가야하는 것일까? 😳

1. 사수? 🤔

개발자로 일하기 이전 직장에서 처음으로 ‘사수’라는 말을 들어보았다. 그 당시 ‘사수’라는 말이 왜이렇게 나에게는 부정적이었을까? “너 사수는 어디갔니?”, “사수가 없을때는 너가 해야지” 이런 말들….. 곰곰히 생각해보았더니, 군대에서 ‘사수’, ‘부사수’라는 용어를 사용했었다! 군대에서 쓰던 용어를 사회에서도 쓰다니… 처음에는 정말 이 단어가 별로였다.
사수라는 뜻을 처음 사전에서 찾아 보았다.
굉장히 간단한 뜻이면서 무언가 굉장히 많은 것을 담고 있는 단어 같다.

사수 (師授)
스승에게서 학문이나 기술의 가르침을 받음.

개발자로 직군을 바꿔 취직을 준비하며, 신입 개발자 입장에서 “개발자 사수가 있는 회사를 가야하는가?”, “사수가 없는 곳에서 성장을 할 수 없는건가?” 이러한 말들을 많이 접하게 되었다.
내가 취직 준비 할때 유투브 영상이나, 주변인들의 말로는

• “개발팀에 “사수”가 없으면 삽질⚒️을 하게된다.”
• “30분이면 할 일을 3시간이 걸려서 할 걸?.”
  

이런 이야기들을 들은 적이 있었다.
하지만 결국 나는 사수가 없는 회사에 들어가게 되었다. 이제 약 11개월 정도 된 입장에서 ‘사수가 없다는것’ 어떤점이 좋았는지, 어떤점이 안좋았는지 적어보려고한다.

2. 사수가 없어서 장점

사실 사수가 있는 회사를 가보지 않아서 사수가 없었을 때의 장점을 적는게 이게 맞는지 모르겠다. 아니라면 댓글로 남겨주세요! ㅎㅎ

2-1 기술 선택의 자유로움 💻

회사에 프론트엔드 개발자가 나 혼자이다 보니, 프로젝트를 진행함에 있어서 기술 선택을 내가 책임지고 적용해 보고 싶은 기술을 결정할 수 있었다. 물론 과도하게 최신 기술만을 도입하지는 않았다. 나의 경우는 새로운 프로젝트를 진행할 때마다 내가 꼭 배워보고 싶은 기술들을 적용하여 개발을 진행 하였다. 예를들어 랜딩페이지 작업을 하는데 기존에 있던 프로젝트 기술이 html,css,js로만 되어있었다면, html,scss,ts,webpack 이런식으로 확장하여, 꼭 사용해 보고 싶은 기술들을 하나씩 추가해서 진행했다. 적용하고 싶은 기술을 선택하고, 왜 이 기술이 나오게됬는지 먼저 찾아본다.
예를들어 왜 css 전처리기인 scss가 출현하게 되었는지? webpack은 왜 왜나왔고 무엇을 해결해 줬는지? 등등 이런 개발 기술의 변천사도 찾아보면 재미지다. 🤣 🤣
아무튼 내가 도입해보고 싶은 기술들을 적정선 내에서 선택할 수 있는 것은 정말 좋은 경험이었다.

2-2 프론트 개발 일정은 나에게 달림

이건 회사 입장에서는 좋지 않을수도 있지만, 프론트엔드 업무는 나 혼자서 담당하고 있기때문에 일정을 정할 때 살짝 여유롭게 잡을때도 있었다. 그런 일정에는 기술 파악, 프로젝트 구조 파악 및 더 나은 코드를 작성하기 위해 설계에 대한 고민의 시간까지 포함되어 있었다.
궁극적으로는 그냥 프로덕트를 돌아가게만 만드는 것이 아닌 조금 더 나은 코드로 나중에 누가 오더라도 유지보수 하기 쉽도록 작성하기 위한 고민들을 많이 했다. (물론…. 내 수준에서 🥲) 즉 시간에 쫒기며 개발하기 보다는 코드 품질에 대해 고민할 시간을 확보 할 수 있었던 점이 좋았다. 하지만 앞으로는 정해진 시간대비 생산성도 높혀야겠다 라는 교훈도 얻을 수 있었다.

2-3 하고싶은 문화 도입 🧑🏻‍💻

이 부분은 꼭 사수가 없어서라고 말하기는 어렵지만, 어쨋든 나를 컨트롤 하는 사람이 없기때문에 개발팀에 새로운 문화들을 도입 할 수 있었다. 사수가 있었다면 살짝 follow-up하는 느낌으로 회사 일 위주로만 했을 수도 있을 것 같은데, 개발팀 문화들을 만들어 갈 수 있었다. 내가 만든 문화중 하나는 개발팀이 너무 일만 하는 것 같다는 생각이 들었고, 팀 자체에 유대감을 높혀보자는 취지에서 일주일에 한번 “스몰톡”을 할 수 있는 “커피쳇 ☕️ 타임”을 도입 하였다.
커피쳇 ☕️은 개발팀이 같이 외부에 있는 카페에가서 개발 이외에 가벼운 이야기를 하면서 1시간 반정도 서로 편안한 이야기를 나누는 시간이다.

2-4 문제해결을 통한 성장 📈

물론 회사에 백엔드개발자 분이 계셔서 해도해도 해결되지 않는 문제들(복잡한 로직)은 해결해 주셨지만, 그 분도 본인 업무가 있으시기에 기타 문제들은 나 혼자서 해결해야 했다. 어려운 문제들은 시간이 오래 걸리지만 해결을 하면서 배우는 것도 많고 더 깊게 고민할 수록 배우는 것은 더 많았다. 후회 되는 것은 초반에 문제 해결한 것들을 정리하고 기록하지 않았던것?? 문제 해결한 것은 기록하고 다시 보아야 정말 다음에 같은 문제를 직면하더라도 스무스하게 해결할 수 있지 않을까? 정말 별 것도 아닌것을 삽질 하면서 시간을 투자하는 것은 의미없지만, 핵심 로직 및 컴포넌트 설계등은 혼자 고민할 시간을 투자하면서 해결하는 것은 삽질이 아니라고 생각한다.

2-5 장점에 대한 결론 🧑🏻‍⚖️

결국에는 이 장점들이 나의 성향과 잘 맞았기 때문이라고 생각한다. 약 1년동안 다양한 기술과 경험들을 할 수 있었고, 조금 더 설계의 중요성에 대해 깨달을 수 있었다.

3. 사수가 없어서 단점

사수가 없다는 것은 어쨋든 나의 상황을 봐줄 수 있는 선배분이 없다는 것이므로 대체적으로 나의 현재 상태에 대한 고민을 해결할 수 없었다.

3-1 방향성 상실

물론 다양한 것들을 해보고 고민하는 시간을 투자하는 것은 좋지만, 마음속에는 항상 불안감이 존재했던것 같다. ‘지금 내가 이것을 하는게 맞는건가?’, ‘지금 이거 고민하는 게 맞는건가?’, ‘이게 최선인가?’, ‘나는 잘하고 있는건가?’ 라는 불안감이 항상 작게나마 딸려왔다. 사수가 없다는 것은 자유로운 건 맞지만, 내 리액트 코드를 객관적으로 판단해줄 사람이 없다는 것, 이 방향으로 개발하는 것이 맞는지 선배 프론트엔드 개발자 입장에서 방향을 어느정도 정해줄 사람이 없다는 것이 가장 컸다.

3-2 우선순위

우선순위에는 다양한 의미가 담겨져있다. 개발 프로젝트를 시작할때 우선순위를 어떻게 정하고, 개발을 진행하는지? 업무 이외에 개발 공부를 하는데 어떤 우선 순위를 두고 공부해야 효율적으로 성장 할 수 있을지? 물어보고 싶을 때가 있다.

3-3 더 나은 코드 및 관리

개발도 나름 짬을 무시할 수 없다고 생각한다. 그 동안 개발 해오면서 나름 본인 생각하는 효율적인 컴포넌트 설계 방식이 있을 것이고, 그 선배 개발자가 고민했던 부분을 어떻게 해결하였는지 듣고 싶다.

3-4 결론

단점들을 쭉 보았을때 3가지 이유가 비슷한 맥락이라고 생각한다. 나는 아무리 이것저것 해봐도 경험 있는 개발자를 따라갈수 없다. 짬에서 나오는 바이브가 있듯이 그 경험을 배우고 싶다. 그리고 이러한 방향성 상실로 혹시 내가 다른 개발자들은 하고 있는데 나는 안하고 있는 것은 아닌지, 내가 동등한 1년차 개발자들과 비교했을때 평균이 안될까봐 두려운 것도 있다.

4 정리 🧹

사수가 있을때의 장점, 단점들을 내가 생각하는 기준에서 살펴보았다. 최근에 면접관으로 들어가면서 느낀 것이지만 3~4년차 개발자들 중에서도 아쉬운 분들을 봤었고(내 기준에), 꼭 사수가 “좋은 사수”만 있는 것은 아닐 거라는 생각이 들었다.
사수 !== 좋은 사수 이렇게 정리할 수 있겠다. 그러면서도 내가 3~4년차가 되었을때 좋은 사수가 될 수 있을까? 라는 추가적인 고민도 들었다.
살짝 주제로 다시 돌아와서, 나는 사수가 있다면 좋지만, 없더라도 해볼수 있는게 많다라고 생각한다. 그리고 혼자서 야생에서 살아남음으로써 자신감도 생길 수 있다. 그래서 사수가 없다고 해서 너무 부정적으로만 생각할 필요는 없다.
하지만 현재의 나는 이제 프론트엔드 웹 최적화와 테스트, 설계에 대해 같이 고민해줄 사수분이 있었으면 좋겠다 ㅎㅎ
하지만 사수가 있건 없건 내가 맡은 일은 혼자 해결할 수 있는 능력이 있어야 되는건 변함없는 사실이라고 생각한다.

5. 결론 ✅

• 좋은 사수가 있는 회사에 가는 건 당연히 좋다.
• 사수가 있고 없고의 여부는 개인의 성향에 따라 괜찮을수도, 안 괜찮을수도 있다.
• 나는 처음에는 사수가 없어서 다양한 것들을 시도해 볼 수 있었고 좋았다.
• 사수가 있건 없건 본인이 맡은 업무는 본인이 혼자서 처리할 수 있어야한다. (1인분)
• 지금은 사수가 있었으면 좋겠다. 😂