이직한지 3주 차라면 코드베이스 등 큰 그림에 대한 이해도가 아직 부족할 수밖에 없는 단계겠어요. 새로운 시스템에 적응하는 램프업 기간은 모두가 거쳐가는 과정이에요. 그러니 헤매는 상황에 대해 너무 스트레스를 받지 않으면 좋겠어요. "이 일을 계속 붙들고 있어도 잘 처리가 되지 않고"의 부분에서 제가 나눠볼 만한 부분이 있는 것 같아요. 저도 주어진 일이 잘되지 않아 오래 붙들고 있었던 경험이 있는데요, 저 같은 경우에는 주로 문제의 본질을 파악하지 못하고 (주로 생각 없이) 이것저것 닥치는 대로 시도해 볼 때 진전 없이 오래 붙들게 되더라고요. 저의 경험에서 효율적으로 task를 해결하는 데 유용했던 방법을 나눠볼게요. 1. 객관적인 시선으로 상황을 파악하기 문제가 주어졌을 때 제일 먼저 이 문제에 대한 자신의 이해도를 파악하는 것이 중요해요. 저는 주로 이런 순서로 파악해요: 문제 자체에 대한 이해 -> 문제를 풀기 위해 필요한 요소 -> 그 요소들 중 내가 이해하고 있는 부분 (known) -> 잘 모르는 부분 (unknown) -> 필요하다고 생각한 요소 말고 혹시 내가 놓치고 있는 부분이 있는지 파악. 이렇게 써 내려간 후 한 개씩 태클하다 보면 실마리가 보이기 시작해요. 디버깅을 할 때도 비슷한 방식으로 접근해요. 2. 효율적으로 질문하기 아는 것과 모르는 것을 파악하고 나면 이제 unknown을 알아가야 하는데요, 스스로 하다가도 결국 막히게 되는 경우가 있어요. 이때 사수나 동료의 도움을 요청해 볼 수 있어요. 1번의 과정을 거쳤기 때문에 밑도 끝도 없이 "이건 왜 안될까요? 이건 어떻게 하면 되나요?"라는 식의 정답을 물어보는 질문 대신 지금까지 조사한 부분에 대한 컨텍스트와 함께 도움이 필요한 부분을 콕 집어 물어볼 수 있게 됩니다. 예를 들면 이런 방식으로 물어볼 수가 있어요. "문제 x를 보고 있는데요, 이게 발생하는 이유는 a, b, c라 보여서 d와 e의 방법으로 접근해 보려고 하는데 잘 안됩니다. 제가 놓치고 있는 부분이 있을까요?" 사수가 설명을 해 주었을 때 100% 이해가 가지 않는다는 생각이 들면 이렇게도 질문을 해볼 수 있습니다. "지금 설명해 주신 부분을 제가 잘 이해하고 있는지 요약해 볼 테니 틀린 부분이 있는지 봐주시겠어요? 그래서 ~~~~~ 이렇게 얘기하신 게 맞나요?" 이런 형식의 질문을 하면 질문을 받는 입장에서도 질문자의 니즈를 정확히 파악할 수 있어서 효율적으로 도움을 줄 수 있게 됩니다. 질문자도 질문하는 과정에서 생각이 정리되는 효과도 있고요. 3. 문제를 해결한 후: 큰 그림에 대한 이해도 높이기 1번의 방식으로 문제를 해결하고 나면 이 문제가 어려웠던 이유를 알게 됩니다. 만약 이게 익숙하지 않은 프레임워크나 언어 때문이었다면 후에 이 분야를 따로 시간 내어 공부해서 전반적인 이해도를 높이면 제일 좋습니다. 다음에 비슷한 문제가 발생했을 때 더 수월하게 해결할 수 있게 될 거에요. 저는 연차가 쌓이면서 시니어 개발자가 되는 과정은 결국 이런 문제해결방법을 터득해가는 과정이라는 생각이 들더라고요. 지금은 막 입사한 단계라 모든 것이 낯설겠지만 시간이 걸려도 작은 문제 하나하나를 해결해 가는 과정이 본인의 코드베이스에 대한 이해도를 넓혀가는 과정이라 생각하고 배우는 마음으로 임하시면 자신도 모르는 사이에 큰 그림을 보는 안목이 생길 거예요.