<div id="readability-page-1" class="page"><article><p>직장인이라면 자연스럽게 업무를 대하는 태도가 캐릭터 처럼 만들어져요. 개발자도 마찬가지고요. 신입이라고 태도가 항상 나쁜 것도 아니고 경력이라고 항상 태도가 좋은 것도 아니에요. 코딩 스킬처럼 개선될 수도 있고요. 연차가 적을수록 몰라서 잘못된 태도를 갖는 경우가 많습니다. 이렇게 만들어진 태도는 보통 연차가 높을수록 개선되기 힘들다고들 하죠. 태도라는 큰 추상적인 덩어리는 억울하게도 한 부분, 한 사건에 의해 모든 것을 퉁쳐서 판단되기도 하죠. <em>이런 태도의 중요한 한 부분은 업무 중 문제가 발생했을 때에 뚜렷하게 나타난다고 생각합니다.</em></p>
<h2>누구나 문제는 발생합니다</h2>
<p>어떤 사람은 업무를 맡기면 어떻게든 잘 해내는 반면 어떤 사람은 항상 문제가 생겨서 더 진행을 못하는 상황이 발생해요. 이런 차이는 많은 요인들이 영향을 주기 때문에 같은 사람이라도 그때그때마다 다를 수 있어요. 잘하던 사람도 어떤 때는 어려움을 겪을 수 있으니까요. 마치 운 같이 느껴질 수 있지만 <em>애석하게도 항상 어떤 일이든 매끄럽지 않게 진행되고 문제가 발생하는 사람이 있기도 합니다. 그런 부정적인 상황에 대처하는 방법이 구체적인 태도로 비치게 되고요.</em>  여기서 중요한 건 문제가 문제 자체가 아니라는 점입니다. 당연히 모든 업무가 성공적 일수는 없어요. 무슨 업무를 맡기던 잘 해낸다는 것은 모든 업무를 완벽하게 성공한다는 뜻이 아니에요. <strong>기대했던 옳은 성과를 이뤄냈다면 좋겠지만 문제가 발생해서 실패했다면 실패도 옳게 실패해야 합니다.</strong> <em>안 될 수밖에 없는 명확하고 좁혀진 이유와 안 되는 것으로 도출하기까지의 과정이 충분히 설득력 있어야 하고 나아가 차선책을 제안할 수 있어야 합니다.</em>  그렇지 않으면 결국 다른 사람이 차선책을 대신 고민해줘야 하니까요.  보통 이럴때 자신의 이슈, 남의 이슈 가리지 않고 차선책을 자주 제시하는 분들이 좋은 평가를 받기도 합니다.</p>
<h2>실패의 설득력</h2>
<p>태도의 문제라고 여겨지는 건 실패 자체가 아니라 문제의 상황에 대해 어떻게, 어디까지 대응하고 정리하는 가입니다. 업무라는 것은 완료와 미완료라는 상태 외에도 여러 가지 상태를 가질 수 있어요. 부정적인 상태로의 전환일수록 그 이유가 명확해야 합니다. <em>실패로 결론을 지으려면 어떤 상태에서 어디까지 했기 때문에 실패라고, 못한다고 결정을 할 수 있냐는 거죠.</em> 업무를 처리함에 있어서는 연차에 따라 분명 짬에서 오는 바이브가 있겠지만 그건 작업의 깊이와는 별도라고 생각합니다.  래밸이 낮더라도 문제를 깊이 있게 살펴보고 좁히는 것은 충분히 할 수 있습니다. 실력이라는 것은 몰랐던 것에 용기 내서 접근하고 해결하는 과정에서 만들어지는 것이잖아요? 물론 아는 것도 자주 하다 보면서 통찰이라는 능력이 생기기도 하지만 몰랐던 것을 배울 때가 배움의 부피는 더 큰 것 같아요. 그래서 더 재미있고요.</p><ins data-ad-layout="in-article" data-ad-format="fluid" data-ad-client="ca-pub-4811193197471582" data-ad-slot="7153541064"></ins>
<h2>질문의 무게</h2>
<p>나쁜 태도란 결국 문제가 발생했을 때 섣불리 작업을 중단하거나 도움을 받으려 하는 것을 말합니다. 질문을 하거나 도움을 받는다는 게 잘못되었다는 것이 아닙니다. 해볼 수 있는 충분히 실험해보고, 문제를 파볼만큼 판 후에 하는 질문과 그렇지 않은 질문은 큰 차이가 있습니다. <strong>질문할 정도로 깊이 있게 문제를 다룬 사람은 질문 자체도 명확하고 질문에 답변자가 알아야 할 정보가 충분해서 답변도 명확합니다. 답변을 조금만 들어도 “아!” 하고 금방 알아차립니다.</strong> 그렇지 않은 경우에는 답변을 어디서부터 해줘야 할지 몰라 <em>오히려 답변자가 질문할 것이 많아집니다.</em> 신입 사원들이 보통 많이 혼나는 영역이죠 :) 질문을 섣불리 해도 문제지만 질문해야 할 것을 안했을때도 혼납니다. 어렵죠. 저도 많이 혼났습니다.</p>
<p>이 모든 것을 그냥 퉁쳐서 문제 해결 능력이라고도 하죠. 부정적인 상황일수록 더 많이 눈에 띕니다.</p>
<h2>A군의 사례</h2>
<p>실제 제가 경험을 토대로 예를 들어볼게요. 프로젝트에서 사용하고 있는 프레임웍의 새 메이저 업데이트가 나와서 마이그레이션을 해야 하는 상황이에요. A라는 친구에게 그 업무가 할당되었죠. 하루 정도 업무를 진행하다가 갑자기 더 이상 작업이 불가능하다고 합니다. 이유를 물으니 마이그레이션 가이드를 참조해서 작업을 진행하고 있는데 알 수 없는 오류가 발생했고 깃헙 이슈를 검색을 해보니 비슷한 오류를 겪는 개발자들이 있었고 거기서 제안된 해결책을 적용해봤더니 소용이 없었다고 합니다. 그래서 더 작업을 진행할 수 없다는 것이죠.</p>
<p>문제가 발생했고 해결책을 검색했으나 해결책이 발견되지 않은 겁니다. 그런데 이 정도에서는 아무것도 명확하지 않아요. 문제의 원인도 명확하지 않고 좁히지도 못했어요. 에러 메시지가 의미하는 바가 무엇인지도 모르고 시도한 것은 그저 검색뿐이에요. 굉장히 단적인 예인 것 같지만 실제 제가 겪었던 일이에요.(상의 없이 케이스로 사용해서 미안하다 A군) 그래서 해야 했던 일 즉 제게 안된다고 하기 전에 했어야 할 일들을  다시 정리해 주었어요.</p>
<h3>1. 직접 질의</h3>
<p>명백한 버그라면 정말 아무것도 할 수 없는 상황일 거에요. 그럴 땐 프레임웍 개발자나 커뮤니티에 직접 물어봐야죠. 깃헙 이슈로 직접 질문을 해봤는지 물어보니 그러진 않았다고 합니다.  사실 이것도 문제입니다. <strong>정말 해결하고 싶은데 도무지 원인을 못 찾겠다면 깃헙 이슈건 메인테이너 트위터 계정이건 메일을 통해서건 물어봐야죠.</strong> 하지만 지금 상태는 질문하는 것 자체가 민폐인 상황이에요. “난 모르겠고 대신 알아서 좀 해줘”라고 한 것과 다를 게 없습니다.  그저 에러 메시지만 들이밀 수밖에 없는 상황이죠. 이런 질문은 오픈소스 메인테이너를 무척 힘들게 합니다. 핵심적인 질문과 필요한 정보를 줄 수 있도록 문제를 좁히고 명확하게 만들어야 해요. 그래야 정확한 답변을 빨리 받을 가능성이 커지죠.</p>
<h3>2. 문제 파악</h3>
<p>우선 에러 메시지가 의미하는 바를 명확하게 파악해야 합니다. <em>에러 메시지를 보자마자 일부를 카피해서 바로 검색창에 때려 넣는 게 도움이 되는 경우도 있겠지만 원하는 답이 없다면 에러 메시지를 이해해야죠.</em> 에러 메시지를 파악해본 결과 프레임웍에서 사용하는 XX라는 디펜던시의 호환성이 문제였습니다. 이 디펜던시는 서비스에서는 직접 사용하는 디펜던시는 아니었습니다. 프레임웍 플러그인의 디펜던시 였습니다.</p>
<h3>3. 문제 좁히기</h3>
<p>서비스에서 직접 사용하지는 않지만  프레임웍을 통해 간접적으로 사용되는 디펜던시가 문제를 일으키고 있는 것으로 의심되었어요.  딱히 프레임웍의 특별한 기능을 사용하는 것은 아니기 때문에 프레임웍 자체의 버그나 문제는 아닐 것으로 판단했습니다. 대부분의 상황에서는 정상적으로 동작할 것이고요. 되니까 배포하고 홍보했겠죠.</p>
<p>그럼 지금 해봐야 할 것은 한 가지입니다. <strong>프레임웍을 사용할 수 있는 최소한의 코드와 설정만 남기고 문제가 발생하는지 확인해 보는 것이죠.</strong>  정말 최소한인데도 불구하고 에러가 발생한다면 설정 밖에서 문제를 찾아야겠죠. Node.js의 버전 문제 일 수도 있고 NPM의 캐시 문제일 수도 있겠네요. 이쯤이면 정말 애초에 프레임웍의 버그일 수도 있겠고요.</p>
<p>다행히 기본적인 설정에서는 잘 돌아갔습니다. <strong>이제 문제를 좁히기 위해 의미 있는 단위로 묶어서 하나씩 설정과 서비스의 코드를 섞어 빌드 해봅니다. 그렇게 문제가 발생하는 지점을 찾아가야죠.</strong> 운 좋으면 금방 찾을 것이고 아니라면…. 고생하겠죠.</p>
<p>이 케이스에서는 애초에 에러 메시지를 통해 프레임웍 플러그인 쪽으로 의심됐어요. 그래서 <strong>설정에서 플러그인을 모두 뺐다가 하나씩 넣으면서 다시 빌드를 해봤죠.</strong>  그러다 다행히 문제가 발생되는 플러그인을 찾았습니다. <em>만약 플러그인 설정만으로 문제를 찾지 못했다면 서비스 코드에서 사용하는 특정 기능이나 API가 문제를 일으키는 것으로 의심하고 서비스 코드를 부분 부분 적용하면서 찾아봤을 겁니다.</em></p>
<h3>4. 해결 방안 검토</h3>
<p>특정 플러그인이 문제인 것으로 밝혀진 상황에서 제일 먼저 생각할 수 있는 <strong>해결 방법은 플러그인의 대체재를 찾는 것입니다.</strong> 같은 문제를 해결하려는 플러그인이 있을 수 있으니까요. 문제의 플러그인은 파비콘을 만들어주는 플러그인이었습니다. 다행히 서비스의 코드와 거의 엮여있지 않았어요. 그래서 쉽게 교체를 검토해볼 수 있었죠. <em>문제를 일으키는 플러그인이 서비스의 코드에서 직접적인 API로 사용된다면 그 코드의 양에 따라서 플러그인의 교체가 힘들수도 있겠죠?</em></p>
<p> 이 케이스는 다행히 그런 걱정은 없었어요. 만약에 그렇지 않았다면 사용되는 API중 어떤 것이 문제가 있는지를 찾아 또 문제를 또 한 번 좁혔을 것입니다.  <em>서비스 코드에서 기본적인 코드만 남기고 하나씩 서비스 코드를 의미 있는 단위로 추가해보면서 문제가 발생하는 부분을 찾습니다.</em> 그렇게 해서 원인이 되는 API를 찾았다면 좀 더 디테일하게 공유된 이슈나 해결 방법이 있는지 찾아볼 수 있습니다.</p>
<p> <strong>자 여기까지 왔으면 이제 이슈를 직접 만들어서 질문할 수 있을 만큼 문제가 날카로워졌습니다.</strong> 검색을 통해 해결책을 찾지 못했다면 질문을 올립니다. 이 문제의 시급도나 중요도에 따라서 그냥 기다릴 수도 있을 것이고 다른 해결 방법을 찾아볼 수도 있습니다. 일단은 빨리 어떻게든 해결되어야 하는 상황이라고 가정하고 다음으로 넘어갈게요. (다행히 A군의 케이스에서는 플러그인 교체로 해결했습니다)</p>
<h3>5. 직접 해결</h3>
<p>여기까지 왔다면 사실 제일 힘든 상황인 것 같아요.  특정 플러그인의 특정 API까지 좁혀졌고 신뢰할 수 있는 어딘가에 구체적인 질문도 올렸어요. 마냥 기다릴 수는 없는 상황입니다. 직접 문제가 발생하는 코드를 수정해야 합니다. 이 과정에서 오픈소스에 기여를 할 수 있는 기회도 잡을 수 있을 겁니다. <em>오픈소스의 코드를 직접 살펴보는 것은 두려울 수도 있지만 문제가 잘 좁혀져 있고 프레임웍에 익숙한 편이라면 어렵지 않은 경우가 생각보다 많습니다.</em>  특정 함수의 몇 번째 라인에서 조건문이 잘못되었다는 것 정도는 충분히 발견하고 해결할 수 있습니다. 버그인 경우 보통 그 정도의 문제인 경우가 많아요. 뭔가 대단하지 않습니다. 단순한 버그가 아니어서 크게 변경되어야 하거나 기능이 추가되어야 하는 상황이라도 작업해달라고 요청만 하는 것보다는 직접 작업해서 PR을 날려보는 것을 추천합니다. <strong>회사일 하면서 오픈소스 커리어를 만들 수 있는 아주 좋은 기회에요.</strong></p>
<p>코드도 살펴보고 이렇게 저렇게 시도를 해봤지만 도메인 지식 부족으로 결국 직접 해결할 수 없는 상황이라고 판단했다면,  음… 여기까지 와서는 정말 스펙을 변경하거나 삭제 혹은 유보할 수도 있겠네요. 이 문제가 해결되기 전까진 말이죠.  중요한 건 여기까지 왔기 때문에 포기할 수도 있는 겁니다. 이유도 충분하고요. 만약 실제 문제에서도 파비콘 플러그인이 아닌 다른 중요한 문제였고 여기까지 왔다면 프레임웍 마이그레이션을 당분간 유보했을 겁니다. 이렇게까지 해야 실패를 해도 옳게 실패했다고 볼 수 있겠죠.</p>
<h2>마무리</h2>
<p>“내용을 읽고 이렇게 당연한 것을 왜 이렇게 거창하게 설명까지 하지”라고 생각하시는 분도 계실 수 있고 “뭐 이렇게까지 해야 하나?”라고 생각하시는 분도 계실 겁니다. 근데 이렇게까지 해야 합니다.  알면서 안 하는 경우보다 몰라서 못하는 경우가 많아서 이렇게 글로 적어봤습니다. 저도 매번 말해주기 귀찮거든요. 앞으로는 이 글로 퉁칠 생각입니다. :)</p></article></div>

shiren.dev RSS Feed

직장인이라면 자연스럽게 업무를 대하는 태도가 캐릭터 처럼 만들어져요. 개발자도 마찬가지고요. 신입이라고 태도가 항상 나쁜 것도 아니고 경력이라고 항상 태도가 좋은 것도 아니에요. 코딩 스킬처럼 개선될 수도 있고요. 연차가 적을수록 몰라서 잘못된 태도를 갖는 경우가 많습니다. 이렇게 만들어진 태도는 보통 연차가 높을수록 개선되기 힘들다고들 하죠. 태도라는 큰 추상적인 덩어리는 억울하게도 한 부분, 한 사건에 의해 모든 것을 퉁쳐서 판단되기도 하죠. 이런 태도의 중요한 한 부분은 업무 중 문제가 발생했을 때에 뚜렷하게 나타난다고 생각…

욕 안 먹는 개발자되기

댓글