주니어개발자인데, 상사에게 질문을 얼마나 해야되는지 모르겠어요

그냥 지나가던 개발자입니다. 질문있을때 저는 저 나름의 템플릿이 있는데요. 1. xx님, 저 aa주제 관련해서 질문이 있습니다! 2. 문제가 되는 코드는 이 부분인데요. 어떻게 구현하는지 잘 감이 안옵니다. 3. 이 코드를 작성한 배경은, 기획서에 이렇게 나와있잖아요. 이 조건을 따라가면 이 경우에 이 기술을 써서 해결해야겠다는 생각이 들었습니다. 4. 이걸 위해 제가 찾아본 방법은 a,b,c가 있는데요, 우리 상황에는 b가 적당할 것 같아서 이 방법대로 가려고 합니다. 5. 문제는 이 방법을 실제로 구현하려다보니 xx님의 도움이 필요해졌습니다. (답변 받은 뒤) 1. xx님 아니였으면 저 며칠은 삽질했을 것 같습니다. 시간 많이 아껴주셔서 감사하고 많이 배웠습니다. 2. 말씀하신 방향대로 구현하고 테스트 코드 포함해서 PR올릴테니 그때 같이 한번 봐주시면 감사하겠습니다. 요런 흐름으로 가면 무난하더라구요 ㅎㅎ 지나가겠습니다~

엄청 고민이 되실텐데 그렇다고 딱 명확한 답변이 있는 내용이 아니라 답변을 드리는게 조심스럽지만, 제가 주니어분들과의 경험했던 것들을 바탕으로 약간의 조언을 드리면 좋을거 같습니다. 사실 제 개인적인 생각으로는 질문을 받았을 때 이런 것도 모르냐의 대답을 하는 것은 좋지는 않은 시니어의 자세라고 생각합니다. 같은 내용을 100번은 반복해서 말해야 똑같이 이해한다는 농담같지만 진담인 우스갯소리가 왜 있을까 싶은거죠 ㅎㅎ 다만 제가 시니어로써 이렇게 질문 했으면 좋겠다고 하는 가이드가 있는데 '질문을 때 객관식으로 해라 '입니다. 즉, 질문을 하실 때 예상되는 답변을 몇개 들고 가시고 그 답변 중에 골라 달라고 하는거죠. 그 예상 답변에 시니어가 생각하는 답변이 없을 수도 있겠지만, 적어도 예상 답변을 들으면 왜 질문하는 사람이 답변을 그렇게 생각했는지에 대한 알 수 있고, 답변을 생각하는 과정에서 무엇이 부족한지도 알 수 있습니다. 그리고 조금 더 나아가서, 같은 피드백을 받는 것에 대해서 좀 더 정확하게 이유를 찾으시는 것도 필요할거 같아요. 말씀하신 것처럼 단순히 이건 무엇인가요의 질문도 아닌데 이런 것도 모르냐의 반응을 계속 받으셨다면 피드백을 주신 분에게 왜 모르면 안되는지에 대해서 물어보시는건 어떨까요? 3년차면 아마도 이제는 본인의 강점과 단점이 드러나는 시기일 텐데 만약 시니어 분들이 무엇인가 같은 단점을 질문 시간을 이용해서 지적하고 있는 것일 수도 있습니다. 피드백을 받는게 사실 말처럼 쉽지는 않지만 그래도 더 성장하는 나를 위해 필요한 일이더라구요. 화이팅 하시길 응원하겠습니다 :)

질문하는 사람만 생각하면 어느 정도로 질문해야할 지 모릅니다. 답변하는 사람이 얼마나 호의적이냐가 고려된다면 이 문제는 정답이 있다기보다 관계마다 다 다릅니다. 질문하는 사람도 실력이 드러나고, 답변하는 사람도 실력이 드러나므로 각자 꺼려지는 이유가 있고요. 실력과 상관없이 서로 성장하려는 관계 형성이 되어 있다면, 질문의 범위는 제한이 없을 겁니다. 먼저 다른 방법으로 인간적으로 친해질 수 있다면 더 좋겠습니다.

저도 주니어 개발자인데요 저의 경우 직접 구현 해보고 구현 도중 애매하거나 모르는 부분을 구체적으로 적은 후 적은 내용을 토대로 들고가서 물어봅니다 그러면 사수분도 제가 뭘 모르는지 정확히 파악을 할 수 있어서 쉽게 설명해주시더라구요 만약 이것도 모르냐는 느낌을 받았을땐 그냥 제 자신이 더 공부를 열심히 해야겠다고 생각하고 공부를 더 열심히 하고있습니다 화이팅입니다

지금은 질문이 아니라 커뮤니케이션, 정보 교환과 공유가 필요하신 것 같아요. 업무에서 질문은 단순한 질의응답이 아니거든요. 그래서 스크럼을 약간 도입한 질문 방법을 제안 드립니다. 이것도 모르냐는 말을 들으신다면, 혼자 해결해 보려는 모습 때문이 아닐까 합니다. 지금은 관계가, 삽질 - 질문 - 모르냐?의 이터레이션이 돌고 있는 듯 합니다. 그래서 작업 공유 - 계획 검토 - 질문 - 피드백으로 바꿔보시는게 어떨까 합니다. 1. 시기: 업무 시작 전이 좋겠습니다. 2. 내용: 먼저 질문자께서 오늘 진행할 부분을 알려드리고, 이렇게 해도 되겠습니까? 정도로 시작해서, 잘 몰라서 불안한 부분을 먼저 말씀드리고, 오늘 오후 3시까지 작업 혹은 시도해 보겠습니다. 3. 질문: 이제 질문을 하는데, 질문 내용을 모으고, 분류해서 우선순위가 높은 걸 한 번에 물어보고 다시 질문을 시도하는 것이 좋겠습니다. 4. 마무리: 윗분께서 답변을 주신 것은 알려주신 내용대로 진행하여, 해결했습니다. 라고 윗분이 알려준 내용과 투입한 시간이 효율적으로 진행되었다고 피드백 하고, 하루를 마무리 하시는 것이 좋겠습니다. 업무 시작 전 내용을 제외하고는 문서나 슬랙, 메신저로 진행해도 좋겠습니다. 그러면서 질문의 빈도나 주기를 줄이고, 질문을 좀 더 핵심적인 내용으로 발전시킨다면, 윗분도 만족하시고 실력도 많이 크실 듯 합니다. 처음엔 누구나 다 모릅니다. 그리고 모른다고 하면 맘도 상하죠. 하지만, 그 기간이 짧을 수록 빨리 성장하는게 아닐까 합니다.

답이 정해져 있는 것은 아니라서 답변이 어려운 문제네요. 일단 질문을 하는 습관자체는 좋은 것 같습니다. 개발이라는게 결과만 나오면 끝인게 아니라 지속적인 유지관리 차원에서의 고민도 필요하기 때문에 자신이 없거나 애매한 경우 시니어개발자에게 도움을 요청하는 것이 장기적인 관점에서 팀에 도움이 될 것 같아요. 다만 이 요청의 수준이 어느정도냐가 중요할 것 같은데 일단 질문이 명확한지 스스로 확인해볼 필요가 있을 것 같습니다. 고민이 부족하면 질문도 추상적인 경우가 많습니다. 이런 경우 질문자와 답변자 모두 핵심을 찾아가기 위해 스무고개를 시작해야 하는데 이런 순간들이 반복이 되면 답변자도 짜증이 날 것 같아요. 두번째로는 성의 문제 일 것 같은데요. 질문하고자 하는 내용에 대해서 본인도 스스로 답을 찾기 위해 노력하는 과정이 필요할 것 같습니다. 검색만 하면 나오는 것을 물어보면 질문을 받는 사람 입장에서 한숨이 나올 것 같아요. 답을 스스로 찾다보면 질문도 명확해집니다. 다만 너무 오랜 시간을 찾다보면 업무에 대한 퍼포먼스가 떨어질텐데 이런 부분에서 균형을 잡을 필요는 있을 것 같습니다. 하루정도 찾아보고 안되면 질문 혹은 1시간 정도 파보고 안되면 질문 등 나름의 기준을 가져보는 것도 좋을 것 같아요. 질문을 너무 하지 않는다라는 피드백이 정확히 어떤 것인지 상사와 이야기 해보아도 좋을 것 같아요. 어떤 질문들이 필요해보이는지 당사자가 이야기 해주는게 제일 정확할 것 같거든요. 다만 공유주신 사례에서 상사의 태도는 그닥 바람직해보이지는 않네요. 질문/답변의 과정에서 불편함이 자주 느껴지고 딱히 도움이 안된다 느껴지시면 그냥 적당히 피하시는 것도 좋을 것 같네요.

아주 주관적인 기준이긴 하지만, 질문의 양보단 질의 문제가 더 크게 작용하는 것 같습니다. 질문을 받았을 때, 물어볼만 했다란 생각이 드는 질문과 그렇지 않은 질문이 있는데요. 후자의 경우에 이런걸 물어보냐 라는 답이 나가는 것 같습니다. 물어볼만 하다는 여러가지로 판단하게 되는데요. 대표적으로 프로젝트 히스토리에 대한 부분이 있습니다. 히스토리는 해당 팀에서의 경험이 없으면 알 수 없는 부분이기에 작업 히스토리에 대한 질문은 반드시 하셔야하고, 그런 질문이 제때 안오면 걱정되기도 합니다. 그 다음은 기술적 난이도가 있는 부분들인데, 이건 케바케입니다. 그 사람의 실력에 따라 느끼는 난이도가 다르게 되어서요. 일단 기술적 질문을 할 때는 내가 최대한 찾아보고 노력했는데 이 부분에서 막힌다 로 디테일하게 내용을 가지고 접근하셔야 합니다. 찾아보지도 않고 떠넘긴다는 느낌이 들면 해보지도 않고 쓸데없는 질문을 한다가 될 수 있습니다. 저는 보통 구글링해보고 스택오버플로우 링크등을 첨부해서 질문했습니다. 그리고 이전에 질문했던 것을 짧은 텀 사이에 다시 하는 것입니다. 이건 그 전에 알려준 것을 귀담아 듣지 않았다 로 해석이 되어 인성의 문제로 생각될 수 있습니다. 질문을 하기 전에 혹시 전에 했던 질문인지 확인하는 것도 좋습니다. 마지막이 양의 문제인데, 이건 객관적으로 볼때도 너무 자주 한다는 느낌이 들면 당연히 문제가 될 수 있습니다. 여러가지 참고하셔서 센스있게 하시면 될 것 같습니다.

관계 설정이 먼저인 거 같습니다. 뻔한 얘기지만, 어느정도 잡담도 하면서 친해지고,서로 알아가면서, 주의할 것은 먼지, 취향, 추구하는 가치 등등 서로 알게되면, 조금씩 신뢰가 쌓여가면서 서로 윈윈할 수 있는 구조를 만들면 쉬워질 거 같습니다. 굳에 예시를 안들어 알거 같으니 이만 총총.

혼자 n시간 고민해보고 그래도 모르겠으면 질문하세요~ 여기서 n값은 상사와 협의하는게 깔끔합니다. 저는 팀원들에게 삽질시간은 3시간으로 얘기합니다. ㅎㅎ

질문을 할때 어디어디를 찾아봤는데 모르겠다라고 검색 여부를 알려주면 되지 않을까 싶네요. 검색 요령이나 키워드를 교정 받을 수 있습니다

질문하는게 나쁜건아니지만좋은 질문이라도 받는사람의컨디션 환경등이 크게작용 하기도하고업무시간이라는게 무한정이아니라 회사같은곳에서는 시간의제약압박 같은것도 무시할수없죠 구래서 솔직히 얼마나해야하나 뭘해야하나보다. 상황을고려해서 너무 무의미하지않은질문들로 최대의효율을뽑아내는것이 중요하겠죠 저는그냥 오지게하고 욕먹었습니다 ㅋㅋ

1. 내가 먼저 해 보고, 2. 안 되는 것을 정리한 뒤에(에러 로그가 있으면 좋습니다), 3. 구글 검색을 해 본 뒤, 4. 다시 한 번 해 보고, 5. 그래도 모르겠다 싶으면 질문하는 것을 추천합니다. 1~4의 과정에 적어도 30분은 써야 양질의 질문이 나올 수 있습니다.