<div id="readability-page-1" class="page"><div><p><h2 id="7700">내가 만난 일잘러 신입의 특징</h2></p><p id="a3f8">NFT 거래 플랫폼을 만드는 IT 서비스 회사 ‘몽키즈3’에 신입 프로그래머 너구리씨가 입사했다. 같은 팀에서 일하는 7년차 프로그래머 토끼씨는 너구리씨에게 어떤 기대를 가지고 있을까?</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*5BoORlik5YtZ5Sa8nv1q3w.png" width="700" height="700" sizes="(min-resolution: 4dppx) and (max-width: 700px) 50vw, (-webkit-min-device-pixel-ratio: 4) and (max-width: 700px) 50vw, (min-resolution: 3dppx) and (max-width: 700px) 67vw, (-webkit-min-device-pixel-ratio: 3) and (max-width: 700px) 65vw, (min-resolution: 2.5dppx) and (max-width: 700px) 80vw, (-webkit-min-device-pixel-ratio: 2.5) and (max-width: 700px) 80vw, (min-resolution: 2dppx) and (max-width: 700px) 100vw, (-webkit-min-device-pixel-ratio: 2) and (max-width: 700px) 100vw, 700px" loading="eager" role="presentation"></p></div><figcaption><a href="https://openai.com/dall-e-2/" rel="noopener ugc nofollow" target="_blank">DALL·E 2</a>가 그려준 너구리씨</figcaption></figure><ul><li id="f7c9">제프 딘 빰치는 코딩 실력?</li><li id="3aa0">셰릴 샌드버그같은 운영 능력?</li><li id="5d1c">사티아 나델라 혹은 리사 수 같은 경영 능력?</li><li id="538b">점심에 뭐먹지?</li></ul><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*xCVTys_L8XLED7h5ePm9mA.jpeg" width="700" height="471" sizes="(min-resolution: 4dppx) and (max-width: 700px) 50vw, (-webkit-min-device-pixel-ratio: 4) and (max-width: 700px) 50vw, (min-resolution: 3dppx) and (max-width: 700px) 67vw, (-webkit-min-device-pixel-ratio: 3) and (max-width: 700px) 65vw, (min-resolution: 2.5dppx) and (max-width: 700px) 80vw, (-webkit-min-device-pixel-ratio: 2.5) and (max-width: 700px) 80vw, (min-resolution: 2dppx) and (max-width: 700px) 100vw, (-webkit-min-device-pixel-ratio: 2) and (max-width: 700px) 100vw, 700px" loading="lazy" role="presentation"></p></div><figcaption>(윗 줄) 제프 딘, 셰릴 샌드버그 / (아랫 줄) 사티아 나델라, 리사 수</figcaption></figure><p id="6590">토끼씨는 너구리씨에게 아무런 기대를 가지지 않는다. 자신이 사회 초년생일 때를 돌이켜보면 한 사람의 역할을 하기까지 얼마나 많은 선배들의 도움이 있는지 알기 때문이다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*uiQ-xF2kk9tvC1_2zHBXpg.png" width="700" height="362" sizes="(min-resolution: 4dppx) and (max-width: 700px) 50vw, (-webkit-min-device-pixel-ratio: 4) and (max-width: 700px) 50vw, (min-resolution: 3dppx) and (max-width: 700px) 67vw, (-webkit-min-device-pixel-ratio: 3) and (max-width: 700px) 65vw, (min-resolution: 2.5dppx) and (max-width: 700px) 80vw, (-webkit-min-device-pixel-ratio: 2.5) and (max-width: 700px) 80vw, (min-resolution: 2dppx) and (max-width: 700px) 100vw, (-webkit-min-device-pixel-ratio: 2) and (max-width: 700px) 100vw, 700px" loading="lazy" role="presentation"></p></div><figcaption><a href="https://openai.com/dall-e-2/" rel="noopener ugc nofollow" target="_blank">DALL·E 2</a>가 그려준 너구리씨와 토끼씨</figcaption></figure><p id="c8b1">그렇다. 신입 혹은 사회 초년생에게 대단한 능력을 기대하지 않는다. 앞으로 잘 배워서 맡은 일을 척척 처리하는 1인분하는 사람이 되길 기도할 뿐이다.</p></div><div><p id="678f"><strong>(광고)</strong> 강의 쿠폰 코드 공유합니다.</p><p id="0875">60,000원 할인 쿠폰코드: <strong>6665–3223f540e68c</strong></p><blockquote><p id="ffe9"><em>2022년 9월 30일까지 유효하며, 선착순 100명에게만 유효합니다</em></p></blockquote></div><div><p id="1887">1인분 하는 사람이란 능력의 차이를 말하는게 아니다. 능력이 차이나도 결국 그 일이 완료할 수 있으면 된다. 1인분 하는 사람이란 신뢰를 얻은 상태다.</p><p id="66d8">경력자라면 이전에 성취한 성과를 통해서 짐작해볼 수 있다.</p><blockquote><p id="0020">물론 그 성과가 지금의 조직안에서 그대로 발휘될 수 있는지는 또 다른 문제다.</p></blockquote><p id="56fb">반면 신입은 데이터가 전혀 없다. 협업을 했다고 말하지만 대부분은 조별과제, 경진대회, 해커톤 정도의 경험이다. 진짜 협업은 돈을 받고 일할 때만 의미가 있다. 앞서 말한 경험은 결과가 실패라도 그 과정에서 학습되는게 있기때문에 의미있다. 돈이 걸린 현업은 망하면 누군가 책임을 져야한다. 무게감에 다르다.</p><p id="1939">신입이지만 일잘러라고 불리는 사람은 1인분을 톡톡히 해낸다. 그럼 이들은 어떻게 그렇게 하는걸까? 짧은 사회 생활에서 만난 소위 일잘러 신입은 어떻게 일 하는지 몇가지 특징을 살펴보겠다.</p><h2 id="7eac">진행사항 알리기</h2><p id="a277">서비스 첫 화면에 캐러샐을 추가하는 일이 있는데 안타깝게도 개발기간이 2주다. QA까지 마치려면 빠듯하다. 의욕넘치는 너구리씨가 일을 맡았다. 그런데 5일이 지나도 아무런 얘기가 없다면 토끼씨는 어떨까?</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*3zH77XX8_Jb_Syc184hQhQ.png" width="700" height="275" sizes="(min-resolution: 4dppx) and (max-width: 700px) 50vw, (-webkit-min-device-pixel-ratio: 4) and (max-width: 700px) 50vw, (min-resolution: 3dppx) and (max-width: 700px) 67vw, (-webkit-min-device-pixel-ratio: 3) and (max-width: 700px) 65vw, (min-resolution: 2.5dppx) and (max-width: 700px) 80vw, (-webkit-min-device-pixel-ratio: 2.5) and (max-width: 700px) 80vw, (min-resolution: 2dppx) and (max-width: 700px) 100vw, (-webkit-min-device-pixel-ratio: 2) and (max-width: 700px) 100vw, 700px" loading="lazy" role="presentation"></p></div><figcaption>캐러샐 예시</figcaption></figure><p id="18a5">그렇다. 답답하다. 토끼씨는 진행사항이 어떤지 어려움은 없는지 궁금하다. 일잘러라면 진행사항을 알린다. 아래 몇가지 예시를 적어봤다.</p><pre><span id="280c">* 순항하고 있다.<br>* 그림부터 그리고 동작 붙이려고 한다.<br>* 프로포타입 작업이 되었는데 피드백 부탁 드린다.<br>* 디자인이 아직 안나와서 우선 프로토타입 작업중이다.<br>* git 레포지토리를 봤는데 누군가 구현한게 있다. 이거 써도 되나?<br>* 처음하는 일이라 그런지 감이 잘 잡히지 않는다.</span></pre><p id="dbd2">물론 좋은 팀이라면 먼저 어려움이 없는지 묻기도하고 혹은 함께 고민할 작업자가 있다. 하지만 언제나 좋은 환경에서 일할 순 없다. 정말 아무것도 없는 벌판에서 일할 수 있다. 그러니 누구에게라도 진행사항을 알리자.</p><p id="948a">점차 시간이 지나고 코드에 대한 장악력도 높아지고 도메인 지식을 쌓다보면 자연히 자신감이 붙는다. 이렇게 성장하는 모습을 보면서 동료들도 신뢰가 생긴다.</p><p id="3bc2">물론 신입이라면 맡을 일을 처리하지도 못했는데 진행사항을 알려야할지 고민될 수 있다. 그러나 팀 혹은 조직의 입장에서는 문제나 일을 처리하는게 중요하지 맡은 사람이 그걸 잘 하는지 못하는지 중요하지 않다. 진행이 더디거나 예상치 못한 문제가 발생하면 자원(시간, 사람 등)을 더 투입해서 해결하거나 다른 대안을 찾으면 된다. 반드시 일을 잘 마치겠다는 사명감은 내려놓고 진행사항을 알리자.</p><blockquote><p id="0468">진행사항만 잘 알려도 나중에 벌어질 큰 문제를 막을 수 있었던 판교 뚜벅초님의 사례</p></blockquote><figure></figure><h2 id="9015">고민보다 질문</h2><p id="e5d2">너구리씨는 입사한 다음날 팀 스탠드업 미팅에 참여했다고 해보자. 팀원 모두 각자 진행사항을 알아듣기 힘든 용어로 얘기한다. 너구리씨는 용어도 익숙치 않은데 뻘쭘하게 일도 없다. 기껏 할수 있는게 이메일 발급 기다려서 사내에 공유된 문서를 확인하는 일이다. 미팅을 마치고 메신저를 살펴보니 다들 뭔가 분주하고 뭘 묻고 답한다. 너구리씨는 빨리 점심이나 먹었으면 좋겠다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*Q-qH-Z4cyx1eoFl8mwL-mw.jpeg" width="700" height="467" sizes="(min-resolution: 4dppx) and (max-width: 700px) 50vw, (-webkit-min-device-pixel-ratio: 4) and (max-width: 700px) 50vw, (min-resolution: 3dppx) and (max-width: 700px) 67vw, (-webkit-min-device-pixel-ratio: 3) and (max-width: 700px) 65vw, (min-resolution: 2.5dppx) and (max-width: 700px) 80vw, (-webkit-min-device-pixel-ratio: 2.5) and (max-width: 700px) 80vw, (min-resolution: 2dppx) and (max-width: 700px) 100vw, (-webkit-min-device-pixel-ratio: 2) and (max-width: 700px) 100vw, 700px" loading="lazy" role="presentation"></p></div><figcaption>스탠드업 미팅을 찾았는데 어째서 앉아계신거에요.</figcaption></figure><p id="e6ef">과장된 면이 있지만 입사 초기 자기 효능감이 떨어지는 시기가 있다. 이건 10년차나 신입이나 다 똑같다. 이럴 때 뭐 안되면 메뉴얼을 잘 못 읽었나? 이러면서 보고 또 본다. 또 안된다. vpn 설치하다가 코드는 구경도 못하고 하루 이틀 지날 때 자괴감이 든다.</p><p id="c4f5">이때 고민하는 시간을 줄이고 질문하자. 보통 해야하는 일에 관한 문서가 있을 수 있지만 작성된 지 오래된 사문서일 수 있다. 혹은 최신 문서라도 사용하는 프로그램이 변경되어 사용법이 달라졌을 수 있다. 맡은 업무에 관한 배경과 설명이 나온 문서 업데이트 늦어져서 해야할 일이 변경되거나 사라졌을 수도 있다.</p><p id="e152">오래 고민해봐야 처음 조직에 합류한 사람은 당연히 기존 구성원보다 정보를 습득할 수 있는 경로가 적다. 내부 시스템을 통해서 문서를 확인해도 어떤게 맞는건지도 모르고 용어가 어떤건지도 모른다. 혼자하면 2시간동안 삽질할 일도 질문하면 1분만에 끝날 수 있다.</p><p id="0e7d">그렇지만 조직에 합류했을 때</p><ul><li id="4cfb">나만 모르는 듯하거나</li><li id="49e9">이것도 모르냐고 놀림받을까봐</li><li id="d336">혹은 이 질문때문에 다른 사람의 시간을 뺏을까봐</li></ul><p id="3e96">등 여러가지 이유로 질문하기 힘들 수 있다.</p><figure><p><img alt="" src="https://miro.medium.com/max/1240/1*TOVWwd3CL45Wv3ZQHr59fQ.jpeg" width="620" height="807" sizes="(min-resolution: 4dppx) and (max-width: 700px) 50vw, (-webkit-min-device-pixel-ratio: 4) and (max-width: 700px) 50vw, (min-resolution: 3dppx) and (max-width: 700px) 67vw, (-webkit-min-device-pixel-ratio: 3) and (max-width: 700px) 65vw, (min-resolution: 2.5dppx) and (max-width: 700px) 80vw, (-webkit-min-device-pixel-ratio: 2.5) and (max-width: 700px) 80vw, (min-resolution: 2dppx) and (max-width: 700px) 100vw, (-webkit-min-device-pixel-ratio: 2) and (max-width: 700px) 100vw, 620px" loading="lazy" role="presentation"></p><figcaption>신입을 대하는 올바른 자세: 잘 했다고 박수쳐주기</figcaption></figure><p id="29b6">조직의 심리적 안정감은 차이가 나겠지만 앞서 설명한 바대로 모두가 자신의 신입 시절을 기억하기 때문에 보통 신입에게 조직 구성원은 관대하다. 그러니 15분~30분만 고민하고 질문하자.</p><p id="ed03">잦은 재택근무로 떨어져서 일하는 경우가 많은 요즘은 즉답을 기대하기보다 메신저에 질문을 던져두면 어쨌든 누군가 대답해 줄거라고 믿고 질문을 남기자. 이때 시급도를 알 수 있는 말머리를 붙인다면 금상첨화다.</p><pre><span id="6e28">토끼: (급하지 않아요)<br>XX 회의에서 어떤 내용 논의하는지 궁금합니다. 관련 문서 전달 부탁드려요.</span></pre><h2 id="d11b">피드백 요청</h2><p id="cbc9">스케이트를 타러 아이스링크에 갔다. 경험이 없어서 혼자 벽잡고 한 바퀴 두 바퀴 돌다가 엉덩방아를 각오하고 조금씩 조금씩 앞으로 간다. 이 사람이 100일을 이렇게 했다. 그럼 스케이트가 얼마나 늘까? 어떤 피드백도 받지 못하니 어떤게 문제고 어디를 신경써야할지 알 방법이 없을테니 100일이 지나도 큰 향상은 기대하기 어렵다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*ESl9eyXHGYDoqZSLr04zcg.jpeg" width="700" height="467" sizes="(min-resolution: 4dppx) and (max-width: 700px) 50vw, (-webkit-min-device-pixel-ratio: 4) and (max-width: 700px) 50vw, (min-resolution: 3dppx) and (max-width: 700px) 67vw, (-webkit-min-device-pixel-ratio: 3) and (max-width: 700px) 65vw, (min-resolution: 2.5dppx) and (max-width: 700px) 80vw, (-webkit-min-device-pixel-ratio: 2.5) and (max-width: 700px) 80vw, (min-resolution: 2dppx) and (max-width: 700px) 100vw, (-webkit-min-device-pixel-ratio: 2) and (max-width: 700px) 100vw, 700px" loading="lazy" role="presentation"></p></div><figcaption>누구나 코치/매니저가 필요하다</figcaption></figure><p id="af1f">짧은 시간안에 좋은 피드백을 받을 수 있어야 성장하는데 유리하다. 프로그래머라면 코드 리뷰를 통해서 코드를 작성하는 일에 관해 빠르게 피드백받으며 성장가능하다. 그런데 아쉽게도 코드 작성은 일의 일부다.</p><figure><p><img alt="" src="https://miro.medium.com/max/1240/1*8EcD6NM2sfuV0VsuWicDwQ.png" width="620" height="577" sizes="(min-resolution: 4dppx) and (max-width: 700px) 50vw, (-webkit-min-device-pixel-ratio: 4) and (max-width: 700px) 50vw, (min-resolution: 3dppx) and (max-width: 700px) 67vw, (-webkit-min-device-pixel-ratio: 3) and (max-width: 700px) 65vw, (min-resolution: 2.5dppx) and (max-width: 700px) 80vw, (-webkit-min-device-pixel-ratio: 2.5) and (max-width: 700px) 80vw, (min-resolution: 2dppx) and (max-width: 700px) 100vw, (-webkit-min-device-pixel-ratio: 2) and (max-width: 700px) 100vw, 620px" loading="lazy" role="presentation"></p><figcaption><a href="https://thenewstack.io/how-much-time-do-developers-spend-actually-writing-code/" rel="noopener ugc nofollow" target="_blank">https://thenewstack.io/how-much-time-do-developers-spend-actually-writing-code/</a></figcaption></figure><p id="bbe1">2019년 조사에 따르면 프로그래머가 코드를 만들어내는데 쓰는 시간은 32%다. 코드 작성외에 필요한 업무 역량도 발전이 필요하지만 채우기 쉽지 않다. 예를 들어 동료와 원활히 의견을 주고 받기 위해 상대방이 이해하기 좋은 글을 쓰거나 설명하는 능력이 필요하지만 어디서 어떻게 학습하고 채워야할지 막막하다.</p><p id="875c">피드백을 요청해서 조금이나마 개선할 수 있다. 그렇다면 왜 피드백으로 개선점을 찾을 수 있을까?</p><blockquote><p id="45a7">“사람은 스스로의 감정은 잘 느끼지만 스스로 좋아지기를 바라는 지능, 매력, 창의력이나 희망사항 등의 특징은 남보다 더 모른다”</p></blockquote><p id="e271">미국 세인트루이스 워싱턴대학교 심리학과 연구팀의 사이민 바지르 박사는 ‘자아-타인 인지 불균형’ 실험에서 자신의 생각, 느낌, 슬픔, 걱정 등의 내면적 특징은 정확하게 평가하지만 밖으로 드러나는 지능, 매력, 창의성 등의 외향적 특징은 다른 사람보다 덜 정확하게 평가한다고 했다.</p><p id="7958">누구나 스스로가 스스로를 가장 잘 안다고 생각하지만 자신에 대해서 더 잘 알려면 다른 사람의 시선을 통해서 나를 봐야만 한다.</p><p id="98c0">그런데 이런 피드백은 자연 상태에서 받기 쉽지 않다. 많은 사람들이 자신외에 별로 관심이 없다. 먼저 나서서 피드백을 주는 사람은 거의 없다. 직접 피드백을 요청해야 받을 확률이 높아진다.</p><p id="7dbb">물론 부작용이 있을 수 있다. 상대방도 서툴러서 피드백달라고했더니 기분을 상하게 하는 사람도 있을 수 있다. 혹은 잘못 받아드려서 의도와 다르게 상처받기도 한다. 골탕이나 먹어보라고 나쁜 의도로 피드백을 전달하는 사람도 있다. 그러나 피드백을 통한 이득이 더 많기 때문에 요청해야한다.</p><p id="ad6b">대게 건강한 조직문화를 가지고 있다면 적어도 한 달에 한 번은 매니저의 피드백을 받을 수 있다. 더 좋은 곳이라면 1주일 최소 10분이라도 피드백 받는 시간이 있을 수 있다. 만약 조직에 합류했는데 이런 문화가 없다면 여러분의 요청으로 그런 문화가 생겨날 수 있으니 꼭 요청해보자.</p></div><p id="9e27">언급된 사항 외에도 많은 방법이 있겠지만 중요한건 실천이다. 알아도 써먹지 않으면 소용없다. 1mm라도 더 발전하는 내일을 위해 오늘 하나 실천해보자.</p><div><p id="2306">제가 속한 배민선물하기팀에서 FE, BE 프로그래머를 뽑고 있습니다. 어떻게 일하는지는 아래 발표를 통해 살짝 엿보실 수 있습니다. 많은 관심 부탁드립니다.</p><figure></figure></div></div>

Stories by 송요창 on Medium

totuworld

NFT 거래 플랫폼을 만드는 IT 서비스 회사 ‘몽키즈3’에 신입 프로그래머 너구리씨가 입사했다. 같은 팀에서 일하는 7년차 프로그래머 토끼씨는 너구리씨에게 어떤 기대를 가지고 있을까?
제프 딘 빰치는 코딩 실력?
셰릴 샌드버그같은 운영 능력?
사티아 나델라 혹은 리사 수 같은 경영 능력?
점심에 뭐먹지?
토끼씨는 너구리씨에게 아무런 기대를 가지지 않는다. 자신이 사회 초년생일 때를 돌이켜보면 한 사람의 역할을 하기까지 얼마나 많은 선배들의 도움이 있는지 알기 때문이다.
그렇다. 신입 혹은 사회 초년생에게 대단한 능력을 기대하지 않는다. 앞으로 잘 배워서 맡은 일을 척척 처리하는 1인분하는 사람이 되길 기도할 뿐이다.
(광고) 강의 쿠폰 코드 공유합니다.
60,000원 할인 쿠폰코드: 6665–3223f540e68c
2022년 9월 30일까지 유효하며, 선착순 100명에게만 유효합니다
만들면서 배우는 프론트엔드 DO IT 코딩 (Next.js, Typescript) - 인프런 | 강의
1인분 하는 사람이란 능력의 차이를 말하는게 아니다. 능력이 차이나도 결국 그 일이 완료할 수 있으면 된다. 1인분 하는 사람이란 신뢰를 얻은 상태다.
경력자라면 이전에 성취한 성과를 통해서 짐작해볼 수 있다.
물론 그 성과가 지금의 조직안에서 그대로 발휘될 수 있는지는 또 다른 문제다.
반면 신입은 데이터가 전혀 없다. 협업을 했다고 말하지만 대부분은 조별과제, 경진대회, 해커톤 정도의 경험이다. 진짜 협업은 돈을 받고 일할 때만 의미가 있다. 앞서 말한 경험은 결과가 실패라도 그 과정에서 학습되는게 있기때문에 의미있다. 돈이 걸린 현업은 망하면 누군가 책임을 져야한다. 무게감에 다르다.
신입이지만 일잘러라고 불리는 사람은 1인분을 톡톡히 해낸다. 그럼 이들은 어떻게 그렇게 하는걸까? 짧은 사회 생활에서 만난 소위 일잘러 신입은 어떻게 일 하는지 몇가지 특징을 살펴보겠다.
진행사항 알리기
서비스 첫 화면에 캐러샐을 추가하는 일이 있는데 안타깝게도 개발기간이 2주다. QA까지 마치려면 빠듯하다. 의욕넘치는 너구리씨가 일을 맡았다. 그런데 5일이 지나도 아무런 얘기가 없다면 토끼씨는 어떨까?
그렇다. 답답하다. 토끼씨는 진행사항이 어떤지 어려움은 없는지 궁금하다. 일잘러라면 진행사항을 알린다. 아래 몇가지 예시를 적어봤다.
* 순항하고 있다.
* 그림부터 그리고 동작 붙이려고 한다.
* 프로포타입 작업이 되었는데 피드백 부탁 드린다.
* 디자인이 아직 안나와서 우선 프로토타입 작업중이다.
* git 레포지토리를 봤는데 누군가 구현한게 있다. 이거 써도 되나?
* 처음하는 일이라 그런지 감이 잘 잡히지 않는다.
물론 좋은 팀이라면 먼저 어려움이 없는지 묻기도하고 혹은 함께 고민할 작업자가 있다. 하지만 언제나 좋은 환경에서 일할 순 없다. 정말 아무것도 없는 벌판에서 일할 수 있다. 그러니 누구에게라도 진행사항을 알리자.
점차 시간이 지나고 코드에 대한 장악력도 높아지고 도메인 지식을 쌓다보면 자연히 자신감이 붙는다. 이렇게 성장하는 모습을 보면서 동료들도 신뢰가 생긴다.
물론 신입이라면 맡을 일을 처리하지도 못했는데 진행사항을 알려야할지 고민될 수 있다. 그러나 팀 혹은 조직의 입장에서는 문제나 일을 처리하는게 중요하지 맡은 사람이 그걸 잘 하는지 못하는지 중요하지 않다. 진행이 더디거나 예상치 못한 문제가 발생하면 자원(시간, 사람 등)을 더 투입해서 해결하거나 다른 대안을 찾으면 된다. 반드시 일을 잘 마치겠다는 사명감은 내려놓고 진행사항을 알리자.
진행사항만 잘 알려도 나중에 벌어질 큰 문제를 막을 수 있었던 판교 뚜벅초님의 사례
https://medium.com/media/ebf468b1bc4ca8c5fa288beca150e395/href
고민보다 질문
너구리씨는 입사한 다음날 팀 스탠드업 미팅에 참여했다고 해보자. 팀원 모두 각자 진행사항을 알아듣기 힘든 용어로 얘기한다. 너구리씨는 용어도 익숙치 않은데 뻘쭘하게 일도 없다. 기껏 할수 있는게 이메일 발급 기다려서 사내에 공유된 문서를 확인하는 일이다. 미팅을 마치고 메신저를 살펴보니 다들 뭔가 분주하고 뭘 묻고 답한다. 너구리씨는 빨리 점심이나 먹었으면 좋겠다.
과장된 면이 있지만 입사 초기 자기 효능감이 떨어지는 시기가 있다. 이건 10년차나 신입이나 다 똑같다. 이럴 때 뭐 안되면 메뉴얼을 잘 못 읽었나? 이러면서 보고 또 본다. 또 안된다. vpn 설치하다가 코드는 구경도 못하고 하루 이틀 지날 때 자괴감이 든다.
이때 고민하는 시간을 줄이고 질문하자. 보통 해야하는 일에 관한 문서가 있을 수 있지만 작성된 지 오래된 사문서일 수 있다. 혹은 최신 문서라도 사용하는 프로그램이 변경되어 사용법이 달라졌을 수 있다. 맡은 업무에 관한 배경과 설명이 나온 문서 업데이트 늦어져서 해야할 일이 변경되거나 사라졌을 수도 있다.
오래 고민해봐야 처음 조직에 합류한 사람은 당연히 기존 구성원보다 정보를 습득할 수 있는 경로가 적다. 내부 시스템을 통해서 문서를 확인해도 어떤게 맞는건지도 모르고 용어가 어떤건지도 모른다. 혼자하면 2시간동안 삽질할 일도 질문하면 1분만에 끝날 수 있다.
그렇지만 조직에 합류했을 때
나만 모르는 듯하거나
이것도 모르냐고 놀림받을까봐
혹은 이 질문때문에 다른 사람의 시간을 뺏을까봐
등 여러가지 이유로 질문하기 힘들 수 있다.
조직의 심리적 안정감은 차이가 나겠지만 앞서 설명한 바대로 모두가 자신의 신입 시절을 기억하기 때문에 보통 신입에게 조직 구성원은 관대하다. 그러니 15분~30분만 고민하고 질문하자.
잦은 재택근무로 떨어져서 일하는 경우가 많은 요즘은 즉답을 기대하기보다 메신저에 질문을 던져두면 어쨌든 누군가 대답해 줄거라고 믿고 질문을 남기자. 이때 시급도를 알 수 있는 말머리를 붙인다면 금상첨화다.
토끼: (급하지 않아요)
XX 회의에서 어떤 내용 논의하는지 궁금합니다. 관련 문서 전달 부탁드려요.
피드백 요청
스케이트를 타러 아이스링크에 갔다. 경험이 없어서 혼자 벽잡고 한 바퀴 두 바퀴 돌다가 엉덩방아를 각오하고 조금씩 조금씩 앞으로 간다. 이 사람이 100일을 이렇게 했다. 그럼 스케이트가 얼마나 늘까? 어떤 피드백도 받지 못하니 어떤게 문제고 어디를 신경써야할지 알 방법이 없을테니 100일이 지나도 큰 향상은 기대하기 어렵다.
짧은 시간안에 좋은 피드백을 받을 수 있어야 성장하는데 유리하다. 프로그래머라면 코드 리뷰를 통해서 코드를 작성하는 일에 관해 빠르게 피드백받으며 성장가능하다. 그런데 아쉽게도 코드 작성은 일의 일부다.
2019년 조사에 따르면 프로그래머가 코드를 만들어내는데 쓰는 시간은 32%다. 코드 작성외에 필요한 업무 역량도 발전이 필요하지만 채우기 쉽지 않다. 예를 들어 동료와 원활히 의견을 주고 받기 위해 상대방이 이해하기 좋은 글을 쓰거나 설명하는 능력이 필요하지만 어디서 어떻게 학습하고 채워야할지 막막하다.
피드백을 요청해서 조금이나마 개선할 수 있다. 그렇다면 왜 피드백으로 개선점을 찾을 수 있을까?
“사람은 스스로의 감정은 잘 느끼지만 스스로 좋아지기를 바라는 지능, 매력, 창의력이나 희망사항 등의 특징은 남보다 더 모른다”
미국 세인트루이스 워싱턴대학교 심리학과 연구팀의 사이민 바지르 박사는 ‘자아-타인 인지 불균형’ 실험에서 자신의 생각, 느낌, 슬픔, 걱정 등의 내면적 특징은 정확하게 평가하지만 밖으로 드러나는 지능, 매력, 창의성 등의 외향적 특징은 다른 사람보다 덜 정확하게 평가한다고 했다.
Who knows what about a person? The self-other knowledge asymmetry (SOKA) model - PubMed
누구나 스스로가 스스로를 가장 잘 안다고 생각하지만 자신에 대해서 더 잘 알려면 다른 사람의 시선을 통해서 나를 봐야만 한다.
그런데 이런 피드백은 자연 상태에서 받기 쉽지 않다. 많은 사람들이 자신외에 별로 관심이 없다. 먼저 나서서 피드백을 주는 사람은 거의 없다. 직접 피드백을 요청해야 받을 확률이 높아진다.
물론 부작용이 있을 수 있다. 상대방도 서툴러서 피드백달라고했더니 기분을 상하게 하는 사람도 있을 수 있다. 혹은 잘못 받아드려서 의도와 다르게 상처받기도 한다. 골탕이나 먹어보라고 나쁜 의도로 피드백을 전달하는 사람도 있다. 그러나 피드백을 통한 이득이 더 많기 때문에 요청해야한다.
대게 건강한 조직문화를 가지고 있다면 적어도 한 달에 한 번은 매니저의 피드백을 받을 수 있다. 더 좋은 곳이라면 1주일 최소 10분이라도 피드백 받는 시간이 있을 수 있다. 만약 조직에 합류했는데 이런 문화가 없다면 여러분의 요청으로 그런 문화가 생겨날 수 있으니 꼭 요청해보자.
언급된 사항 외에도 많은 방법이 있겠지만 중요한건 실천이다. 알아도 써먹지 않으면 소용없다. 1mm라도 더 발전하는 내일을 위해 오늘 하나 실천해보자.
※주의※ 회사에서 읽지 마시오.
제가 속한 배민선물하기팀에서 FE, BE 프로그래머를 뽑고 있습니다. 어떻게 일하는지는 아래 발표를 통해 살짝 엿보실 수 있습니다. 많은 관심 부탁드립니다.
https://medium.com/media/4e74b2907558ba6bf376fcfa98ff13d8/href

내가 만난 일잘러 신입의 특징

댓글