상사가 바로 알아보는 ‘일 잘하는 신입 개발자’의 특징

🚀 비슷한 실력을 갖추고 있고 같은 업무를 맡았음에도 유독 ‘일 잘한다’는 말을 듣는 신입이 있습니다. 그 차이는 대부분 태도와 소통 방식에서 비롯됩니다. 질문을 어떻게 하는지, 정보를 어떻게 공유하는지, 다른 팀과 협업할 때 어떤 자세로 임하는지 등에 의해 그 사람에 대한 인상이 형성됩니다. 그리고 이 인상은 곧 ‘함께 일하고 싶은 사람’, ‘믿고 맡길 수 있는 사람’으로 굳어집니다. 그렇다면 함께 일하고 싶은 사람, 신뢰할 만한 사람으로 자리매김하는 데 필요한 태도는 무엇일까요?

| 공유를 잘한다

처음 일을 시작했을 때는

작은 실수 하나에도 욕을 먹지는 않을까

전전긍긍하기도 합니다.

그래서 일정이 점점 밀리는데도

혼자서 끌어안고 있거나

실수를 조용히 덮고 넘어가는

경우도 있습니다.

하지만 이러한 태도는

팀 전체를 위험하게 만들 수 있습니다.

예를 들어

로그인 기능을 맡은 신입이

일정이 지연되는 상황을 공유하지 않다가

배포 하루 전날에야

“아직 완성하지 못했어요” 라고

밝힌다면 어떤 일이 벌어질까요?

로그인 기능을 기반으로 동작하는

다른 기능들의 일정까지 밀리게 됩니다.

하나의 기능이

전체 일정의 발목을 잡을 수 있기 때문에

신입은 사소한 어려움이라도

최대한 빨리 공유하는 것이 팀을 위한 일입니다.

「 Tip 」 공유를 잘하자!

일정대로 진행하기 어려울 것 같을 때 망설이지 말고 윗사람에게 이야기해야 합니다. 신입은 빨리 말할수록 수습하기 쉽고, 본인은 물론이고 팀에도 도움이 됩니다. 신입이 실수하는 것을 팀원은 당연히 여길 것입니다. 숨길 필요도, 기죽을 필요도 없습니다. 자신의 실력을 있는 그대로 인정하고 실수를 숨기지 않으며 배우려는 자세를 갖는 순간부터 진짜 성장이 시작됩니다.

| 질문을 잘하는 것도 실력이다

예전에 네이버에서 함께 일했던 동료들에게

개발자가 되고자 하는 학생들을 위해

조언을 해달랬더니

공통적으로 다음과 같이 말했습니다.

“질문을 잘하는 신입이 일도 잘하지.”

가르치는 사람으로서 질문은

언제든 반가운 일입니다.

하지만 전후 사정 없이

“안 돼요”, “에러가 나요”,

“왜 안 되는지 모르겠어요” 라고 하면

어디서부터 도와줘야 할지 막막합니다.

「 Tip 」 질문을 정리해보자!

질문을 잘하려면 먼저 상황을 입력 → 처리 → 출력 흐름으로 정리할 필요가 있습니다. 전체 흐름 중 어느 부분에서 문제가 발생했는지, 어떤 상황에서 무슨 작업을 하다가 문제가 생겼는지 스스로 정리해 보는 것입니다. 그리고 어떤 입력값과 조건으로 시도했는지, 문제를 해결하기 위해 어떤 방법들을 시도해 봤는지, 그 결과는 어땠는지를 차례대로 되짚어봐야 합니다. 이렇게 했는데도 해결되지 않으면 그때 질문을 하세요.

어디까지는 정상적으로 동작했고 어느 단계에서 문제가 발생했는지를 명확히 알려주면 상대방이 상황을 쉽게 파악할 수 있고, 그만큼 필요한 답변을 얻을 가능성이 높아집니다.

만약 다음과 같은 질문을 받는다면 어떨까요?

“/post 주소로 요청했고,

파라미터 값으로 A와 B를 넘겼습니다.

컨트롤러까지는 정상적으로 들어오는데

데이터베이스에 저장되는 값이 예상과 다릅니다.

이제 어떤 부분을 더 살펴보면 좋을까요?”

이처럼 정리된 질문의 경우

듣는 사람이 상황을 바로 이해할 수 있어

조언하기가 훨씬 수월합니다.

결국 질문을 잘하는 것도 실력입니다.

좋은 질문 하나로 업무의 방향이 바뀌기도 하고,

일의 속도가 빨라지기도 합니다.

| 다른 팀과 소통할 때의 주의점

필자의 부끄러운 과거 이야기를

하나 털어놓겠습니다.

입사한 지 얼마 지나지 않은 어느 날,

다른 팀이 메신저로 일을 부탁했습니다.

열정이 넘쳤던 필자는 아무 생각 없이

“알겠습니다” 라고 바로 답하고

작업에 들어갔습니다.

하지만 곧 크게 혼이 났습니다.

코드를 작성하기 전에

설계를 하는 것이 중요하듯이

업무 요청을 받았을 때도

전체를 보는 관점이 필요합니다.

당시에 필자가 가장 먼저 했어야 했던 일은

우리 팀이 담당한 업무인지

확인하는 것이었습니다.

나중에 알고 보니

그 업무는 다른 팀의 책임이었습니다.

그런데 필자가 손을 대는 바람에

우리 팀, 요청한 팀, 실제 담당 팀이

모두 혼란을 겪게 됐습니다.

이 경험을 통해 필자는

요청을 받았을 때

무조건 바로 작업을 시작하면

안 된다는 것을 배웠습니다.

또한 개발자가 자주 겪는 일 중 하나는

기획자와의 의견 충돌입니다.

버튼을 클릭했을 때

목록 화면이 새로고침되게 해달라는

요청을 받았다고 가정해 봅시다.

단순해 보이는 요구 사항이지만

실제로는 리스트가 여러 탭에 걸쳐 있고,

새로고침을 구현하려면

전체 캐시 구조를 수정해야 할 수도 있습니다.

기획자 입장에서는 작은 변경이지만

개발자 입장에서는 서비스 구조 전반에

영향을 주는 작업인 것입니다.

「 Tip 」 기획자와의 의견 충돌? 이렇게 해보자!

이럴 때는 간단히 “안 됩니다” 라고만 말하지 말고 현재 구조와 그로 인한 영향을 설명해야 합니다. 그리고 가능한 대안이 있다면 제시하는 것이 좋습니다.

“지금은 캐시 구조가 A→B→C 순으로 연결돼 있어서 이 부분을 바꾸려면 B와 C도 수정해야 합니다. 그러면 전체 서비스에 영향을 줄 수 있고요. 대신 리스트 항목만 갱신하는 방법이 있는데, 이건 어떨까요?”

이렇게 구조와 이유를 설명하고 대안을 제시하면 기획자가 상황을 잘 이해할 수 있습니다. 경우에 따라서는 기획 자체를 조정해 더 나은 방향을 찾을 수도 있습니다.