조회 3,348
익명
2022년 11월 14일
안녕하세요 저는 이제 1년차가 다되어가는 백엔드 주니어 개발자입니다. 현재 첫회사에서 퇴사하고 작은 스타트업에 이직하여 3주차가 되어가는 상태입니다. 제가 회사업무 처리를 해나가는 과정은 일정과 task는 사수 시니어 개발자분이 정해 저한테 할당해주시고 저는 할당된 task를 일정안에 처리해야됩니다. 하지만 저한테는 일정안에 저에게 할당된 task를 처리해나가기가 매우 힘들어 회사업무를 끝나고 이일을 계속 붙들고 있어도 잘 처리가 되지 않고, 주말에도 계속 신경쓰여 해당 업무를 들여다보게 되면서 조금씩 지치게되는 것 같습니다. 그래서 어떻게 이 상황에서 현명한 방법으로 현재 이직한 스타트업에서 살아남을 수 있을지 고민이듭니다. 현재다니는 회사가 작은 스타트업이고 퍼포먼스를 빨리빨리 내야된다라는 분위기라 어떻게 제가 처신하고 노력해야될지 잘모르겠습니다. 그래서 여러 선배개발자 분들께 이렇게나마 한번 여쭤보고 의견을 구하고자합니다. 조금이라도 말씀을 해주시면 감사한 마음으로 듣겠습니다.
질문을 평가해 주세요!
구체적이고 정성스러운 질문에 ↑Up 투표를 눌러주세요.
설명이 부족한 질문에 ↓Down 투표를 눌러주세요. 커리어리가 질문자에게 수정을 요청할게요.
답변 4
BEST 답변
이직한지 3주 차라면 코드베이스 등 큰 그림에 대한 이해도가 아직 부족할 수밖에 없는 단계겠어요. 새로운 시스템에 적응하는 램프업 기간은 모두가 거쳐가는 과정이에요. 그러니 헤매는 상황에 대해 너무 스트레스를 받지 않으면 좋겠어요. "이 일을 계속 붙들고 있어도 잘 처리가 되지 않고"의 부분에서 제가 나눠볼 만한 부분이 있는 것 같아요. 저도 주어진 일이 잘되지 않아 오래 붙들고 있었던 경험이 있는데요, 저 같은 경우에는 주로 문제의 본질을 파악하지 못하고 (주로 생각 없이) 이것저것 닥치는 대로 시도해 볼 때 진전 없이 오래 붙들게 되더라고요. 저의 경험에서 효율적으로 task를 해결하는 데 유용했던 방법을 나눠볼게요. 1. 객관적인 시선으로 상황을 파악하기 문제가 주어졌을 때 제일 먼저 이 문제에 대한 자신의 이해도를 파악하는 것이 중요해요. 저는 주로 이런 순서로 파악해요: 문제 자체에 대한 이해 -> 문제를 풀기 위해 필요한 요소 -> 그 요소들 중 내가 이해하고 있는 부분 (known) -> 잘 모르는 부분 (unknown) -> 필요하다고 생각한 요소 말고 혹시 내가 놓치고 있는 부분이 있는지 파악. 이렇게 써 내려간 후 한 개씩 태클하다 보면 실마리가 보이기 시작해요. 디버깅을 할 때도 비슷한 방식으로 접근해요. 2. 효율적으로 질문하기 아는 것과 모르는 것을 파악하고 나면 이제 unknown을 알아가야 하는데요, 스스로 하다가도 결국 막히게 되는 경우가 있어요. 이때 사수나 동료의 도움을 요청해 볼 수 있어요. 1번의 과정을 거쳤기 때문에 밑도 끝도 없이 "이건 왜 안될까요? 이건 어떻게 하면 되나요?"라는 식의 정답을 물어보는 질문 대신 지금까지 조사한 부분에 대한 컨텍스트와 함께 도움이 필요한 부분을 콕 집어 물어볼 수 있게 됩니다. 예를 들면 이런 방식으로 물어볼 수가 있어요. "문제 x를 보고 있는데요, 이게 발생하는 이유는 a, b, c라 보여서 d와 e의 방법으로 접근해 보려고 하는데 잘 안됩니다. 제가 놓치고 있는 부분이 있을까요?" 사수가 설명을 해 주었을 때 100% 이해가 가지 않는다는 생각이 들면 이렇게도 질문을 해볼 수 있습니다. "지금 설명해 주신 부분을 제가 잘 이해하고 있는지 요약해 볼 테니 틀린 부분이 있는지 봐주시겠어요? 그래서 ~~~~~ 이렇게 얘기하신 게 맞나요?" 이런 형식의 질문을 하면 질문을 받는 입장에서도 질문자의 니즈를 정확히 파악할 수 있어서 효율적으로 도움을 줄 수 있게 됩니다. 질문자도 질문하는 과정에서 생각이 정리되는 효과도 있고요. 3. 문제를 해결한 후: 큰 그림에 대한 이해도 높이기 1번의 방식으로 문제를 해결하고 나면 이 문제가 어려웠던 이유를 알게 됩니다. 만약 이게 익숙하지 않은 프레임워크나 언어 때문이었다면 후에 이 분야를 따로 시간 내어 공부해서 전반적인 이해도를 높이면 제일 좋습니다. 다음에 비슷한 문제가 발생했을 때 더 수월하게 해결할 수 있게 될 거에요. 저는 연차가 쌓이면서 시니어 개발자가 되는 과정은 결국 이런 문제해결방법을 터득해가는 과정이라는 생각이 들더라고요. 지금은 막 입사한 단계라 모든 것이 낯설겠지만 시간이 걸려도 작은 문제 하나하나를 해결해 가는 과정이 본인의 코드베이스에 대한 이해도를 넓혀가는 과정이라 생각하고 배우는 마음으로 임하시면 자신도 모르는 사이에 큰 그림을 보는 안목이 생길 거예요.
3주차라면 사실상 온보딩 기간에 해당할 것 같아요 아직 서비스 전반적인 이해가 중요한 시점이라고 판단되는데, 느끼시는 분위기들이 압박으로 다가오시는 것 같네요 ㅠㅠ 아무리 훌륭한 팀장이라도 팀원이 진행하는 일의 일정산정을 완벽하게 할 수는 없습니다. 현재 막히는 부분이 어딘지를 파악하시고 이부분이 나의 부족함 때문인지 무리한 일정 탓인지를 먼저 구분하실 필요가 있습니다 무조건적으로 내가 이 기간안에 끝내야 돼라는 마인드도 좋지만, 때로는 한계에 부딪혔을때 적절한 학습과 생각의 시간을 가지고 개발을 하는 것도 중요합니다 부족한 점이 학습이라면 시간을 투자함에 따라 넘을 수 있지만, 부족한 점이 경험과 생각이라면 시간을 마냥 투자해도 견문을 넓혀줄 무언가가 필요합니다. 이렇게 상황에 따라 다르게 움직여야하지만 1년차의 경험으론 이런 부분들을 판단하시기는 너무 어려우실 것 같아요. 지금 고민하시는 부분이 어떤부분인지 먼저 파악해보시고 그에 따라 팀장님과 의논해보시면 아마 혼자서 앓고 계신 상황 보다 더 나아지리라 믿습니다 ㅎ
지금 가입하면 모든 질문의 답변을 볼 수 있어요!
현직 개발자들의 명쾌한 답변을 얻을 수 있어요.
이미 회원이신가요?
지금 가입하면 모든 질문의 답변을 볼 수 있어요!
현직 개발자들의 명쾌한 답변을 얻을 수 있어요.