1년차 개발자의 훈수 두기

안녕하세요. 스포카 제품팀의 백엔드 프로그래머 이지민입니다.

어느덧 스포카에 입사한 지, 개발자가 된 지 1년이 되었습니다!

개발자 1년, 참 고생도 많이 하고 다사다난했던 것 같습니다. 그만큼 배운 점도 많기에 이 글에서는 1년 동안 스포카를 다니면서 신입 개발자로서 느낀 것들과 배운 점들, 그리고 질문받았던 내용들을 담아보려고 합니다.

1년 차 개발자가 번데기 앞에서 주름잡는다고 생각하시고, 동시에 개인차를 인지하시면서 재밌게 읽어주시면 좋겠습니다.

회사는 학교와 다릅니다

입사 후 정말 많이 들었던 질문이 학교와 회사의 가장 큰 차이점이 무엇인가에 대한 질문이었습니다.

저는 고등학교 재학 중 스포카에 취업했습니다. 취업하고 회사에 다니면서 많이 들었던 생각은 ‘정말 학교와 회사는 다르구나’ 였습니다. 학교가 동물원이었다면 회사는 야생 그 자체였습니다. 가장 크게 느꼈던 차이점 몇 가지를 소개해보겠습니다.

학교와 회사의 목적과 목표

학교의 목표는 학생들을 가르치고 보호한다 에 있기 때문에 안전한 울타리가 저를 감싸고 보호해준다는 느낌이 들었습니다. 하지만, 회사의 목표는 고객을 만족시키고 이익을 얻는다 에 있기 때문에 보호보다는 일을 잘할 수 있는 환경을 만들어주는 것이 회사의 역할이라고 생각합니다.

이런 목표와 역할 차이 때문에 처음에는 매우 불안했던 것 같습니다. 회사에서는 이 신입이 회사에 이익을 가져다줄 수 있는지 평가하고 저는 그 평가 속에서 기대에 부응해야 했기 때문에 솔직하게 부담이 많이 되었습니다.

그렇기 때문에 무리하게 일하기도 했고 많이 속상하기도 했습니다. 하지만 점차 어떻게 일하는지에 대해 배우고 학교와 회사의 목표 차이를 인지하며 많이 익숙해지니 학교처럼 회사도 점차 편안해졌습니다. 회사에 입사하기 전, 학교와 회사는 목표 자체가 다르다는 것을 인지하시고 그 차이에 너무 놀라지 않으셨으면 좋겠습니다.

하지만 목적과 목표가 다름에도 불구하고 학교와 회사의 공통점이 있다면 바로 개인의 성장과 배움을 적극적으로 지원한다는 것입니다. 여전히 회사에서도 배워야 할 것들은 많으며 스포카에서는 이를 학습 할 수 있도록 적극적으로 지원해주고 있습니다. 덕분에 개인의 성장에도 큰 도움이 되는 것 같습니다.

부담감과 책임감

앞 이야기와 이어지는 내용일 것 같은데요. 회사는 이익이라는 목표를 가지고 움직이는 조직이기 때문에 각자가 가진 책임은 더욱 커집니다. 학교에서는 제가 잘 해내지 못한 것의 책임은 저에게 있지만, 회사에서는 제가 잘 해내지 못한 것에 대한 책임은 회사와 고객들이 가져가기 때문에 시간을 잘 지키는 것, 퀄리티 좋은 코드를 짜는 것에 대한 책임은 더욱 커졌고 잘해야 한다는 부담감도 더욱 커진 것 같습니다.

코드 퀄리티에 대해서 조금더 이야기하자면, 학교에서는 코드 퀄리티의 중요성에 대해서 많이 강조 하지 않았습니다. 언어의 문법에 대해서 공부하고 기능이 동작하도록 코드를 작성했습니다. 이는 학교에서의 프로젝트는 일회성이기 때문에 더욱 그렇다고 생각하는데요. 일회성이기 때문에 유지보수를 생각 하지 않고 기능이 동작하도록만 코드를 작성하게 되었습니다.

하지만 회사에서는 서비스를 계속해서 확장해나가고 버그를 수정하고 유지 가능하도록 코드를 작성해야 합니다. 가장 중요한 이유는 혼자 하는 프로젝트가 아닌 다른 동료와 함께 일한다는 것입니다. 제가 코드를 복잡하게 짠다면 다른 동료가 같은 작업부분을 건드려야 할 때 다른 동료는 시간을 더 많이 사용하게 됩니다. 그렇게 된다면 제 작업 효율뿐만 아니라 함께 일하는 다른 동료의 작업 효율까지도 낮출 수 있는 일이 됩니다. 그렇기 때문에 더욱 책임감을 가지고 코드를 깔끔하게 유지하고 인터페이스를 잘 마련해주어야 한다고 생각합니다.

이런 큰 책임감과 부담감 때문에 심리적으로는 힘들었지만 저를 부지런히 공부하게 만들었고 코드에 대한 고민도 많이 하게 만들어 주는 원동력으로 작용한 것 같습니다. 덕분에 처음의 저와 비교했을 때 많은 성장을 이뤄낸 것 같습니다.

친구들이 옆에 없는 것

당연한 말일 수 있지만 사실 가장 크게 달라졌다고 느껴지는 것 중 하나입니다. 첫 한 달은 매일 같이 있던 친구들이 아닌 일로 인해 뭉쳐진 사람들끼리 함께 있다는 것, 그게 크게 와 닿았고 힘들었던 것이 사실입니다.

의지하며 실수도 함께하는 친구들이 바로 옆에 없다는 것은 혼자 짐을 들고 가는 것처럼 외롭기도 하고 친구들이 많이 보고 싶기도 했습니다. 하지만 회사에 다니다보니 친구만큼이나 많은 시간을 보내고, 같은 공감대를 형성할 수 있는 관계가 회사 동료라는 것을 느꼈습니다.

위에서 설명한 회사와 학교의 차이점들 때문에 입사 후 첫 석 달 간은 매우 힘들었던 것 같습니다. 물론 개인차가 크겠지만 저는 소심하고 생각이 많은 INFP이기 때문에(?) 더욱 그랬던 것 같네요.

마치 이상한 변호사 우영우에 나왔던 우영우 변호사가 다른 공간에 들어서기 전, 하나 둘 셋을 세 듯 신입 개발자인 저도 하나 둘 셋의 시간을 견디며 회사라는 다른 공간에 적응해 나갔습니다. 물론 개인의 3초가 다르듯 더 빠를 수도 있고 느릴 수 있겠지만 혹은 다른 공간 안에 또 다른 공간이 있을 수 있겠지만 신입 개발자분들이 조급함 없이 자신에 맞게 셋을 센다면 학교와 회사의 차이에도 어렵지 않게 적응할 수 있을 겁니다.

신입 개발자의 재택근무

첫 입사 당시, 스포카에서는 코로나로 인해 전원 재택근무를 하고 있었습니다. 입사 전에는 재택근무는 긍정의 이미지가 강했습니다. 출퇴근이 없다는 것, 집에서 근무를 할 수 있다는 것에 큰 기대를 했었습니다.

하지만, 실제로 재택근무가 신입 개발자가 일하기 좋은 환경인가에 대해서는 어느 정도 단점이 존재함을 느꼈습니다.

예민한 사항을 다루는 부분이라 조심스럽긴 하지만 재택근무를 하면서 느낀 장단점을 정리해보려고 합니다. 분명히 말씀드리지만, 개인차가 존재할 수 있으며 시니어 개발자 기준이 아닌 신입 개발자의 기준에서 정리한 것임을 한 번 더 인지해주시기를 바랍니다!

제가 재택근무를 하면서 느낀 재택근무의 장단점입니다.

사실 장점은 많이들 파악하고 계실 거로 생각합니다. 신입 개발자도 장점을 그대로 가져가긴 하지만 제 개인적인 생각으로는 단점이 장점보다 더 크게 작용할 것입니다. 따라서 아래에서는 어떻게 보면 재택근무를 비판한다고 보일 수 있겠지만 시니어 개발자의 경우 재택근무가 효율을 크게 높여준다는 것에 매우 동의합니다.

장점보다는 단점에 조금 더 치우쳐서 소개해드리겠습니다.

어려운 성과 측정

첫 번째로 성과 측정이 어렵다는 것입니다.

이 성과 측정이 어렵다는 것은 성과 측정자를 기준으로 하는 말인데요. 신입 개발자가 어떻게 일했는지 파악하기 어렵다는 것입니다. 성과 측정자는 신입 개발자의 성과를 결과만을, 즉 코드와 작업량, 시간을 보고 성과를 측정하게 됩니다.

물론 결과만을 놓고 보는 것에 대해서 크게 잘못됨을 느끼지 않는 분들이 많겠지만 신입 개발자가 보여줄 수 있는 성실과 열정을 놓치게 됩니다. 결과만을 놓고 보았을 때 신입 개발자가 얼마나 큰 노력과 시간을 들였는지 파악하지 못한 채 성과를 측정하며, 성과만을 놓고 성실에 대한 여부를 판단할 수 있습니다.

재택근무를 하지 않는다면 신입 개발자는 자신의 시행착오들을 모두 보여줄 수 있습니다. 이런 시행착오를 했으며, 얼마나 많은 시간을 쏟았는지 의자에서 고민하는 모습들을 성과 측정자의 눈에 보여주며 성실을 표현할 수 있습니다.

어색한 팀원들

두 번째는 팀원들과 친해지기 어렵다는 것입니다. 재택근무를 하다보니 슬랙을 이용하는 경우가 많고 직접 만나 의사소통하는 경우가 줄어들다 보니 모든 팀원과 친해지기 어려운 것이 사실이었습니다. 얼굴도 모르고 소통하다 보니 요청하는 것에 대한 망설임이 있었고 더 조심스러웠습니다.

코로나 시기가 좀 잠잠해진 입사 후 몇 주가 지나서야 처음으로 일부 팀원들을 만나 소통할 수 있었고 팀장님께서 신입인 저와 팀원들이 친해질 기회들을 많이 제공해주셨습니다. 그때서나 팀원들과 많이 가까워진 느낌이 들었습니다.

질문하기 어려운 환경

세 번째는 많은 질문을 할 수 있는 환경이 아니었다는 것입니다. 개발을 하다 보면 여러 고민거리가 생깁니다. 회사에서는 툭 튀어나온 간단한 고민들을 산발적으로 시니어 개발자에게 공유하며 빠르게 결정하고 알아갈 수 있습니다.

하지만 재택근무를 하게 되면 간단한 질문들을 혼자 고민하게 되고 비교적 시간을 더 사용하게 됩니다. 왜냐하면 재택근무 시에는 텍스트 형식으로 질문들을 많이 하게 되는데 텍스트로 질문할 때 더 많은 설명들이 필요하고 더 신중해지기 때문에 질문을 하는 데도 많은 정리가 필요합니다. 즉, 더 많이 신경을 써서 질문을 해야 한다고 느꼈습니다. 그 때문에 산발적인 질문이 크게 오가지 않는 것 같습니다.

어려운 업무와 일상의 분리

재택근무를 하다 보니 일상생활과 업무의 분리가 잘되지 않았습니다. 공간의 분리뿐만 아니라 특히 시간의 분리가 되지 않았습니다. 업무를 퇴근 전까지 끝내지 못하면 퇴근이 없는 것 같은 느낌을 받았습니다. 또한 회사생활에서 받은 업무와 스트레스를 퇴근해도 분리해내지 못하는 것이 가장 큰 문제점이었습니다.

신입 개발자의 재택근무에는 장점도 많겠지만 분명 단점도 존재합니다. 이런 단점들을 어떻게 극복하느냐는 개인의 영역이기 때문에 단점들을 인지하시고 개인의 방법에 맞게 장점들을 더 극대화하고 단점의 영향을 최대한 줄일 수 있으면 좋겠습니다.

문서화는 중요합니다

입사 전, 문서화와 기록의 중요성을 잘 모르고 있었습니다. 개발자와 문서화, 어떻게 보면 어울리지 않는 조합이라고 느껴지지만 입사 후 문서화는 매우 중요하다는 것을 깨닫게 되었습니다. 문서화를 많이 해보지 않았고 중요성 또한 몰랐던 저는 개발자가 문서화를 중요하게 생각한다는 것에 대해 조금은 당황스러웠지만 많은 장점을 느꼈습니다.

그렇다면, 어떨 때 문서화를 하면 좋은지와 문서화를 했을 때의 장점들을 나열해보겠습니다.

매일 하는 업무 기록

말 그대로 오늘 한 업무 내용들을 기록하는 것입니다. 어떤 작업을 했는가뿐만 아니라 어떤 어려움을 겪었으며, 어떻게 해결해나갔는지에 대한 자세한 내용들을 기록하는 습관을 들이는 것은 많은 도움이 된다고 생각합니다. 기록은 이후에 비슷한 작업을 할 때 참고하거나, 비슷한 어려움을 더욱 쉽게 해결할 수 있는 수단이 됩니다.

또한 하루의 업무를 하면서 배운 것들을 기록하고 배운 것들을 토대로 공부할 수 있는 내용을 확장해나가면 더욱 좋을 것 같습니다.

매일 기록하는 것이 귀찮은 일일 수도 있지만 쌓여가는 기록을 보면 회사의 기여 정도나 자신의 성장 정도를 체크해볼 수도 있어서 동기부여에도 좋은 역할을 합니다.

회의를 더욱 의미 있도록 만들어주는 문서화

회의를 문서 없이 진행하게 되면 어떻게 될까요? 회의의 논점, 주제와 결론이 흐려지고 심지어는 결론이 나왔는데도 휘발되어 다시 기억해내거나 여쭤봐야 하는 일이 생깁니다. 또한 말하려고 했던 내용을 빼먹거나 문제를 발견한 당시에는 파악하고 있었으나 회의 때 갑자기 받은 질문에 기억이 나지 않아 답변할 수 없을 수 있습니다.

회의 전 문서를 준비하게 되면 회의 주제와 순서, 결정하고자 하는 것이 명확하기 때문에 논점을 흐려지지 않아 더 빠른 시간 내에 결론에 도달할 수 있습니다. 그리고 회의 전 문서를 작성해서 먼저 회의 참가자에게 공유하게 되면 다른 참가자들이 회의 전에 내용을 더 잘 파악할 수 있어 더 질 좋은 회의를 기대할 수 있습니다. 또한 문서를 준비하지 않는 것보다 문서를 준비하는 정성을 들였기 때문에 회의 참가자들에게 훨씬 더 소중한 회의 시간이라고 느끼게 할 수 있을 것입니다.

그리고 회의 진행 시 결론과 대화를 기록하며 회의 내용이 휘발되지 않도록 하는 것 또한 문서화를 함께하는 회의에서 중요한 요소인 것 같습니다.

문서로 히스토리 남기기

문서화의 또 다른 장점은 히스토리를 파악하는 것에 유용하다는 것입니다. 새로운 입사자가 회사에 입사하게 되었을 때 가장 먼저 하는 일이 회사에 문서를 읽는 것인 것 같은데요. 새로운 입사자가 기존의 회사 문서를 읽고 어떤 방향으로 서비스가 개발되었고 지금의 서비스가 나오게 되었는지 파악하는 데 중요한 역할을 하는 게 문서입니다.

예를 들어 프로젝트에 도입하고 싶은 기술이 있다면 무작정 도입하고 싶다고 주장하는 것이 아닌 문서로 기술의 장단점, 비용, 도입 이유 등을 정리하여 문서화 해 놓는다면 이후 어떤 내용으로 기술을 적용하였는지 파악하는 데도 유용할 것입니다.

히스토리를 더 잘 파악하기 위해서는 많은 문서가 필요하고 카테고라이징이 잘 되어 있으며, 심지어는 읽어야 하는 문서가 명확하다면 문서들의 효과를 더욱 많이 볼 수 있을 것 같습니다.

질문 답변 기록

매우 쉬운 질문을 하는 것보다 어려운 질문이라도 같은 질문을 여러 번 반복하는 것이 오히려 더 부담되는 상황이라고 생각합니다. 또한 한번 알려주고 다시 그 내용을 물어봤을 때 그 내용을 더 잘 파악하고 있다면 알려주는 입장에서도 더 잘 알려주고 싶겠죠.

그러므로 질문을 하고 답변이 휘발되지 않도록 기록하는 것 또한 중요한 일 입니다. 어떤 질문들을 했고 어떤 답변을 주셨는지 꼼꼼하게 기록하는 습관도 중요합니다.

실수를 두려워하지 마세요

정말 도덕책에 나올 것 같은 말일 수도 있을 것 같은데요. 신입 개발자는 한번 실수하면 자신이 한 실수가 회사에 정말 큰 영향을 끼친다고 생각합니다. 시니어 개발자가 보기에 심각하지 않은 실수임에도 신입 개발자는 자신을 질책하고 일주일 내내 슬퍼할 수도 있습니다.

하지만 신입 개발자가 하는 실수는 대체로 큰 실수가 아닐 것입니다. 큰 실수가 일어날 수 있는 매우 중요한 작업은 시니어 개발자와 함께하는 것이 맞고 모두의 충분한 검토와 공유가 필요하다고 생각합니다. 또한 정말 심각한 실수를 막기 위해서는 시스템의 방어도 필요하다고 생각합니다.

만약 신입 개발자가 정말로 큰 실수를 하게 된다면 그것은 관리와 시스템의 잘못이지 과연 신입 개발자의 잘못인지 모르겠습니다.

이 글을 보고 계신 시니어 개발자분들도 이를 인지하시고 신입 개발자가 실수하게 된다면 이미 속으로 많은 자책을 하고 있을 테니 많은 위로를 부탁드립니다.

신입은 이런 시니어 개발자를 원해요

저는 시니어 개발자가 신입 개발자를 어떻게 키워야 할지에 대한 부담을 조금은 알고 있습니다. 그래서 조금이라도 도움이 되고자 신입 개발자로서 제 성장에 도움이 되었던 스포카 시니어 개발자의 행동에 관해서 이야기 해보려고 합니다.

잦은 질문

스포카의 시니어 개발자는 불쑥 저에게 어려운 질문들을 많이 해주셨습니다. “이거 알아요? 저거 알아요?” 이런 질문들이 저를 많이 배울 수 있게 해준 것 같습니다. 제가 모르는 개념들은 너무나도 많았고 모르는 개념에 대한 질문을 받으면 답변하기 위해 공부했던 것들이 많은 도움이 되었습니다.

물론 질문들을 받으면 공부해야 한다는 생각에 마냥 좋지만은 않았지만, 새로 알게 되는 개념들이 많았기 때문에 저는 흥미롭고 많은 도움이 되었습니다.

시니어 개발자가 해주는 간단한 질문들은 신입 개발자에게는 큰 공부가 될 것 같습니다

페어 프로그래밍

페어 프로그래밍은 특히 코드 convention에 대해서 잘 모를 때 convention에 대한 이해가 깊은 개발자와 하면 큰 도움이 됩니다. 하지만 페어 프로그래밍은 한 작업을 두 작업자가 함께하므로 효율이 더 높지 않다는 점과 시니어 개발자와 신입 개발자가 함께 페어 프로그래밍을 하면 상대적으로 신입 개발자가 얻는 지식은 많지만 시니어 개발자가 얻는 지식은 많지 않다는 단점이 있습니다. 그럼에도 불구하고 한 신입 개발자의 코드 적응에는 큰 도움이 됨을 확신하고 큰 변화를 가져다줄 수 있다고 생각합니다. 팀의 지금 당장의 효율보다는 이후에 효율을 생각했을 때 페어 프로그래밍은 분명 큰 도움이 될 것입니다.

저는 TDD를 페어 프로그래밍으로 했는데 테스트 코드를 짜는 방법과 코드 convention 등 여러 개발 지식을 많이 얻었습니다. 페어 프로그래밍에 참여하는 모두가 힘들어하긴 했지만 좋은 경험이었고 지금도 가끔 페어 프로그래밍을 요청하기도 합니다.

꼼꼼한 PR 리뷰

제가 첫 입사 때를 생각해보면 저는 좋은 코드가 무엇인지 나쁜 코드가 무엇인지에 대한 인지가 깊지 않았습니다. 그렇기 때문에 이를 알아갈 방법이 필요했고 그것이 PR 리뷰였습니다.

위 PR 리뷰처럼 어떤 의존성을 가지고 코드를 작성해야 하는 지와 코드의 가독성을 높이는 방법, 테스트코드를 더 명확하게 짜는 방법, SRP 등의 개발 원칙 등 꼼꼼히 리뷰해주시고 설명해주심과 동시에 코드의 질은 높아졌습니다.

또한 PR 리뷰의 중요성과 PR 리뷰를 더 의미 있게 보는 방법에 대해서도 신입 개발자가 인지할 수 있도록 한다면 신입 개발자가 PR 리뷰를 받는 입장뿐만 아니라 PR 리뷰를 하는 입장에서도 더욱 책임감 있게 리뷰를 할 수 있게 될 것입니다.

자신감을 올려주는 행위

마지막으로 자신감을 높여주는 행위입니다. 무슨 말인가 싶을지 모르겠지만 저는 제법 중요하다고 생각합니다. 신입 개발자는 사실 자신이 개발을 잘하지 못한다고 생각할 때가 많습니다. 또한 회사에 내가 필요한 사람인가를 항상 고민할 수 있습니다. 하지만 회사에 필요한 사람이 되는 순간 뿌듯함을 느끼고 더 열심히 일해야지 하는 의지를 얻는 것 같습니다.

위 사진은 저희 회사의 연말 맞이 이벤트에서 제가 받은 선물에 쓰인 편지인데요. 저에게는 큰 위로와 감동을 주었습니다. 이것 말고도 요즘 더 성장한 것 같다는 말을 종종 들을 때 정말 큰 힘을 받았던 것 같아요.

신입 개발자는 이런 소소한 표현들에 많은 감동을 받는 것 같습니다. 물론 제가 많이 감성적이라 그런 걸지도 모르지만 분명 많은 도움이 되고 포기하지 않도록 만들어주는 힘을 주는 것 같습니다.

시니어 개발자분들이 신입 개발자에게 잘하고 있다고 종종 말해준다면 그 신입 개발자의 퍼포먼스는 더 좋아질 것임을 확신합니다.

시니어 개발자는 이런 신입을 원해요

방향을 아예 전환해서 시니어 개발자가 원하는 것 같은 신입 개발자에 대해서 이야기해보려고 합니다. 또 그것을 잘 해내기 위해 어떻게 하면 좋을지에 대해서도 풀어보겠습니다.

물론 제 추측이지만 제 시니어 개발자가 저에게 요구했던 것들을 토대로, 또 같은 상황을 겪고 있는 제 친구들의 의견 수렴으로 작성하는 것이니 참고 바랍니다.

오랜 고민보다는 질문

저는 어떤 문제에 맞닥뜨렸을 때 혼자 뭐가 더 나은 방안인지 오랜 고민을 했었습니다. 그렇다 보니 많은 시간을 쏟아야 했고 한 작업 당 시간이 매우 오래 걸렸습니다. 저도 답답했고 지켜보는 사람 또한 답답하게 했었던 것 같습니다. 그러다 한 시니어 개발자분이 시간을 정해놓고 고민하고 시간이 지나면 질문을 하라는 방안을 제시해주셨습니다.

저는 실제로 그러기 시작했고 제가 오랜 고민 후에 답을 내릴 수 있던 문제들에 대해서 더 빠르게 답을 낼 수 있도록 도움을 주셨습니다. 오랜 고민보다 함께 고민을 공유하고 해결책을 찾아나갈 때의 이점들은 아래와 같습니다.

먼저, 혼자 고민한 것보다 질문을 했을 때 결론에 대한 퀄리티가 더 좋습니다. 시니어 개발자의 여부를 떠나서 혼자 고민하게 되면 한 가지 생각과 방안에 얽매이게 되고 결국엔 퀄리티의 한계가 있을 수 있습니다. 하지만 함께 고민하게 되면 더 넓은 시야로 해결 방안에 대해서 생각해볼 수 있었습니다. 또한 고민하던 것 외의 것들을 더 많이 배울 수 있습니다. 시니어 개발자의 문제해결 방법을 보며 해결 방법에 대해서 배우게 되고 문제를 해결하는 과정에서 새로운 개념에 대해서 알아야 할 때 그것들을 학습할 기회가 생기는 것도 큰 장점입니다.

그리고 고민하는 시간을 줄이면 한 작업 당 효율이 높아지고, 질문을 함으로써 더욱 작업에 대한 적극성을 표현할 수 있습니다. 즉, 질문하면 오히려 작업을 더 잘하고 있다는 인식을 심어줄 수 있는 것 같습니다.

그렇다면 질문을 할 때는 어떻게 해야 할까요? 먼저 문제 상황을 정확히 인지하는 과정이 필요합니다. 시니어 개발자도 현재 문제 상황을 정확히 인지하는 것이 아닐 것이기 때문에 문제 상황을 충분히 설명할 수 있도록 문제 상황에 대한 이해가 필요합니다. 두 번째로 질문을 정리하는 것입니다. 질문을 하기 전 머릿속에 있는 질문을 리스트업해서 효율적으로 질문하는 것이 필요합니다. 세 번째로 여쭤보기 전 질문에 대해서 먼저 생각해보는 것입니다. 그렇다면 질문의 질은 더 올라가고 고민한 티가 나는 질문을 하게 됩니다.

진행 상황 공유

시니어 개발자에게 신입 개발자는 관리해야 하는 관리 포인트일 수 있습니다. 특히 재택근무를 하는 상황이라면 더욱 관리가 힘들어질 수 있습니다. 이 관리를 해야 하는 상황에서 시니어 개발자를 조금이라도 배려하기 위해서 신입 개발자는 현재 작업 진행 상황을 수시로 알려야 합니다.

진행 상황을 많이 공유하게 되면 시니어 개발자뿐만 아니라 신입 개발자에게도 아래와 같은 이점이 있습니다.

먼저, 결과물에 대한 기대를 어느정도 맞출 수 있습니다. 중간에 공유 없이 결과물만 바로 공유한다면 공유받는 이의 결과물에 대한 기대의 차이 때문에 더 큰 실망을 줄 수 있습니다. 그러므로 중간에 진행 사항을 공유해서 결과물이 어느 정도로 나오겠구나하고 예상이 되게끔 하여 결과물에 대한 기대감을 실제 결과물과 맞추는 것도 중요합니다. 또한 중간에 공유해서 피드백까지 받는다면 결과물의 퀄리티는 더 높아지겠죠.

그리고 진행 상황을 공유하며 문제도 함께 공유한다면 더 빠르게 문제가 해결될 수 있고 작업 진행도에 대한 이유를 제시할 수 있습니다. 예를 들어 어떤 문제를 제시하며 이 문제 때문에 작업 진행도가 이 정도 되었음을 공유하면 함께 해결책을 찾아 더 빠르게 문제를 해결하거나 작업 진행도에 대해 납득을 시키는 데 도움이 될 것입니다.

코드를 짜는 것에 대한 이유를 분명히 하라

신입 개발자는 왜 이런 코드를 짜는지, 왜 이런 설계가 되어야 하는지, 테스트코드가 왜 필요한지, 코드에서 사용하고 있는 패턴이 어떤 역할로 존재하는지 모르고 코드를 짜는 경우가 있을 수 있습니다. 기존의 코드를 보고 똑같이 따라 하려고 할 때 이런 경우가 많이 생기는데요. 시니어 개발자는 왜 이런 코드를 짜는지 이해하고 짜기를 바라고 있을 것입니다. 코드 한 줄에도 이유가 있어야 하고, 설계가 있다면 효율을 따져보아야 합니다.

코드를 짤 때 한줄 한줄에 개선점을 찾고 이유를 찾다 보면 더 효율적인 코드가 보일 것입니다. 시니어 개발자는 코드 한 줄도 정성들여 짜는 것을 원합니다.

마치며

스포카에서 1년이라는 시간은 개발자로서 첫 단추를 끼우는 저에게 무척 소중한 시간이었습니다. 제가 잘 적응할 수 있도록 도와주신 저희 팀 여러분들, 특히 백엔드 챕터 여러분들께 감사드립니다.

저는 팀에서 더 중요한 역할이 되기 위해서 더 많이 배우고 성장하며, 앞으로 스포카가 식자재를 주문하시는 점주분들께 더 좋은 서비스를 제공하기 위해서 노력하겠습니다.

이 글이 어려움을 겪고 있는 신입 개발자에게는 큰 위로가, 신입 개발자를 잘 대응하고 싶은 시니어 개발자에게는 작은 가이드가 되었기를 바라는 마음으로 이만 글을 줄이겠습니다.

긴 글 읽어주셔서 감사합니다.