주니어 개발자가 느낀 '나에게 있어 부족한, 그래서 갖춰야 할' 현업능력

🐔글 머리

---

👩🏻‍💻들어가기 전에...

이 글은 제가 우아한 테크캠프 3기를 진행하면서 생각한 '나(주니어 개발자)에게 부족한 부분은 무엇인가?'에 대한 회고입니다. 상당히 추상적인 주제인데다, 이미 많은 분들이 다룬 주제이기에 뻔하고 지루할 수 있습니다.

저와 같은 개발자 취준생 분들이든 현역 선배분들이든 '이런 생각도 있구나' 정도로만 봐주시고 댓글로 자신의 의견을 알려주시면 정말 감사할 것 같습니다ㅎㅎ.

👦왜 이런 글을?

우선 저라는 주니어 개발자에 대해 간략히 소개해 드리겠습니다. 저는 지방 4년제 컴공과를 다니다 마지막 학기에 쎄트렉아이라는 인공위성 제조사에서 15주간 인턴을 하며 프론트엔드를 배웠습니다. 졸업을 한 후에는 삼성전자에서 주관하는 SSAFY교육을 1년간 수료하고 바로 우아한테크캠프에 참가하여 지금 교육을 받고 있습니다.

주저리 써놓긴 했지만 결국 제대로 된 현업을 경험한 적 없는 주니어 개발자입니다. 사실 제대로 돈을 받고 회사에서 프로젝트를 해본 적이 없다는 점에서는 주니어 개발자보다 학생에 가깝습니다. 그래서 주구장창 교육만 받아왔기에 현업에 필요한 역량을 피부로 느끼지 못했다는 한계점이 있었습니다.

그러다 이번 우아한 테크캠프를 하며 이 부분에 대한 생각이 더욱 깊어지게 되었습니다. 우아한 테크캠프는 제가 지금껏 받아본 교육 중 기술적으로 가장 현업을 고려한 교육이었고, 끊임없이 고민하게 만들고 그것을 장려하며 공유하게 만들었습니다. 덕분에, 추상적이었던 생각을 정리하여 블로그로 남길 기회를 가지게 되었습니다.

글재주가 없어서 서론이 너무 길었네요. 이제 제가 생각한 나에게 있어 부족한, 그래서 갖춰야 할 능력이 무엇인지 나열해보겠습니다.

🐕글 몸통

---

이제 크게 3가지로 내가 현업에서 갖춰야 할 능력 이 뭔지 적어보겠습니다.

1. 생산성과 코드품질의 중요도 비율 정하기

프로젝트를 하면서 다음과 같은 고민을 팀원과 토론했었습니다.

2개 이상의 테이블에 접근해야하는 동작이 있을때, 어떤 방식으로 코드를 짜야하나?
1. Restful한 도메인구조와 백엔드 디렉토리 구조를 위해 프론트에서 fetch를 여러번 해야한다.
2. 클라이언트의 성능부담을 줄이기 위해 한번의 fetch 요청에 백엔드가 여러 처리를 해야한다.

이 토론을 할 당시 저는 깔끔한 구조와 클린코드를 위해 1번이 더 적절하다 생각했었습니다. 주변의 몇몇 다른 팀들도 제각각 다른 생각을 가지고 있었고, 교육을 담당해 주시던 코드스쿼드의 honux님께 여쭤봤을때 돌아온 대답은 '정답이 없다'였습니다.

전 이 대답을 듣고 제가 깔끔한 코드와 구조에 집착해 시야가 편협해졌다는 것을 느꼈습니다. 생산성과 성능 모두 결국 최종목적은 저렴한 금액으로 안정적인 서비스를 제공하는 것입니다. 소수의 특정 사용자층이 대상이지만 빠르게 런칭해야 한다면? 회사의 메인 서비스라서 사용자수가 많고 장기적으로 유지보수를 해야 한다면? 혹은 서비스에서 해당 기능이 굉장히 자주 쓰는 기능이라면?

상황이 그때그때 다르기 때문에 클린코드로 얻는 협업에서의 생산성, 단기간에 빠르게 코드를 짜서 얻는 생산성, 추구했던 개발방법론을 부수면서 얻는 성능 모두 중요도가 달라집니다.

사실 정말 당연한 건데 '좋은 코드는 ~~한 코드다'와 같은 원론적인 이야기를 들으며 교육만 받아온 저는 프로젝트를 해오면서 '성능을 손해보고 시간이 오래 걸리더라도 예쁜 코드가 좋은 코드야', '예쁘게 짜야 되는데 시간이 없네? 나중에 회사가면 예쁘게 짜야지'와 같은 생각이 있었던 것 같습니다. 회사에서는 더 엄격한 프로젝트 마감일과 성능요구사항이 있을텐데 말이죠 ㅎㅎㅎ.

그래서 제가 첫째로 생각한 내가 갖춰야 할 능력은 해당 프로젝트에서 생산성과 성능의 중요도 비율을 정하는 능력이라고 느꼈습니다. 근데 이걸 잘하는 분들은 정말 경험이 많은 시니어 개발자분들이겠죠. 하지만 주니어도 이 사실을 인지하고 그 감각을 익히려는 노력은 필요하다고 생각합니다.

2. 팀원과의 중요도 비율 조율

본인이 아무리 프로젝트에 적절한 중요도 비율을 정해도 프로젝트는 혼자 하는게 아니죠. 다행히 저는 2인 1조였던 이번 프로젝트의 파트너분이 의견을 잘 수용해 주시면서도 양질의 코드를 짜려고 노력하시는 분이었습니다. 하지만 항상 이렇게 운이 좋을순 없는 거고 저의 짧은 프로젝트 경험에서도 소통이 잘 안되는 분들이 계셨습니다.

스스로가 정한 중요도 비율이 어떻고 왜 그렇게 생각하는지를 팀원에게 적절히 설명하는 커뮤니케이션 스킬이 제가 생각하는 두번째 내가 갖춰야 할 능력입니다. 팀원 각자가 자신의 생각대로 비율을 맞추려 하면 프로젝트의 전체 중요도 비율이 엉망이 될테니까요.

이것도 뻔한 이야기입니다만, 지금까지는 학교팀플이나 싸피교육을 받으며 '의지가 별로 없는 사람', '팀원한테 불친절한 사람'이 내가 소통에 더 유의해야 할 사람이었습니다. 하지만 이번엔 '나와 개발 철학이 다른 사람'이 대상이고 이 경우가 대부분일 거라는 생각이 들었습니다. 막연하던 기존과는 다른 커뮤니케이션 스킬이 필요한 좀 더 구체적인 상황을 알게 된거죠.

그리고 주니어 개발자가 입사하면 소통하는 분들은 대부분이 저보다 더 경험이 많고 뛰어난 분들입니다. 따라서 주체를 가지되 상대방의 의견을 수용하는 마음가짐이 저한테 가장 필요할 것 같습니다.

3. 적극적으로 성장 실천?하기

우아한 테크캠프를 하면서 우하한 형제들의 시니어 개발자분들의 말씀을 들을 기회가 있었습니다. 우아한 형제들은 자유로운 편이라고 하나 그럼에도 프로젝트에 자신이 생각한 기술을 도입하기 위해선 동료 팀원 및 회사에게 이유를 설명하기 위해 상당한 노력을 들여야 한다고 합니다. 당연한 이야기죠.

아무튼 앞서 말한 프로젝트에서 고려할 중요도 비율은 오로지 회사와 프로젝트만을 위한 비율입니다. 만약 거기에 '처음 쓰는 이 기술을 적용하면 생산성이나 성능이 떨어질지도 모르지만 내가 성장하기 위해서 써볼거야!'와 같은 마음을 가지면 안된다는 거죠.

하지만 역설적이게도 회사와 개인을 발전을 위해서 새로운 기술에 대한 도전이 필요하다고 생각합니다.
이 3번 항목은 아직 제대로 머릿속에 정리도 되지 않았는데 '회사에서 새 기술써보는게 조심스럽다지만 그래도 개발자라면 새 기술에 대한 욕심이 있어야 하지 않을까?' 라는 막연한 생각에 추가하게 되었습니다ㅠㅠ. 첫 글이라 참 정신이 없군요.

올바른 마음가짐

올바르지 않은 마음가짐

정리하자면 회사에 피해가 가지 않는 선에서 새 기술에 대한 욕심 가지기가 제가 생각하는 세 번째 내가 갖춰야 할 능력입니다.

🐍글 꼬리

---

🙆첫 글을 마치며

본론에서 말한 내용들은 아마 현업 개발자 분들이 느끼기에 너무나 당연하거나 혹은, 너무 뜬구름 잡는 소리일수도 있습니다. 하지만 이제 막 개발자의 길을 디딘 저에겐 제가 보이는 시야 안에서 열심히 보고, 고민하여 저만의 개똥철학을 만들어가는 첫 단계였습니다. 현실에선 끊임없이 타협하게 되는게 개똥철학이라지만, 타협하기 위해서 개똥철학은 필요한 것 같습니다. 타협할 상대가 없으면 밑도 끝도 없을것 같거든요ㅎㅎ. 부족하고 긴 글 읽어 주셔서 너무나 감사하고 다들 매 순간 행복하시길 바랍니다!