<div id="readability-page-1" class="page"><article>
    <div>

                
                

				<h2 id="개요">개요</h2>

<p>개발자로 일하다 보면 생각보다 많은 수의 개발자가, 솔로 플레이처럼 일하는 경우가 많다.</p>

<p>함께 일한다는 의미는, 서로의 생각과 방향이 비슷해지고, 서로 돕고 도움 받는 것을 통해 시너지가 나는 것이라고 생각한다.</p>

<p>허나 나의 판단만 옳다고 여기거나, 내가 틀릴 리 없어와 같은 생각으로 문제 상황을 회피하거나 숨기는 경향을 보이는 경우도 많다.</p>

<p>애석하게도 버그는 개발자에게 필연적인 요소다. 버그가 없었다면 난도가 높지 않았거나, 이미 숙련된 일을 해내고 있을 확률이 높다.</p>

<p>훌륭한 개발자들이 모여있을 빅 테크의 제품도, 수없이 많은 버그 픽스와 보안 패치가 이뤄진다.</p>

<p>이는 당연하게도 버그란 없을 수 없고, 때로는 요구 사항에 대한 이해도 차이로도 버그로 판정될 수도 있다는 뜻이다.</p>

<h2 id="결국은-팀-작업">결국은 팀 작업</h2>

<p>Dev Toy 프로덕트나, 스타트업의 MVP, 인하우스 혹은 백 오피스 도구 중에서도 규모 작은 수준의 제품이라면 모를까 고도화가 되거나 제품이 커지다 보면 결국 팀 작업이 된다.</p>

<p>내가 똑똑함을, 내 생각이 옳음을 증명하기 보다는 <strong>근거를 만들고 설득을 시도하는 습관</strong>이 좋다.</p>

<p>많은 회사가 개발자 채용 시에, <strong>근거 기반의 사고</strong>, <strong>논리력</strong>을 보는 경우가 많은데 바로 그렇게 일하는 사람이 팀에, 회사에 도움이 된다는 것을 체감했기 때문이다.</p>

<p>결국 건강한 토론을 해야 되는데, 닫혀있는 사람과는 소모적인 토론이 일어나기 때문이다.</p>

<p>심지어는 자신만 옳다고 여기는 사람은, 토론 자체가 성립이 안되는 경우도 생기기 때문에, 팀을 구성하는 데에 있어 리더, 구성원 할 거 없이 열려 있는 사람이 좋은 결과로 이어진다고 생각한다.</p>

<h2 id="그렇다고-역량이-안-중요하진-않지만">그렇다고 역량이 안 중요하진 않지만…</h2>

<p>역량이 부족하면 결국 다른 구성원들이 메꿔야 되는 상황도 존재하고, 기술 부채도 더 많이 만들게 되는 등 다양한 문제를 만드는 것은 사실이다.</p>

<p>하지만 개인적인 경험상 역량이 부족한 사람보다, 닫혀 있는 사람이 더 팀웍이나 팀 퍼포먼스에 악영향을 줬다.</p>

<p>물론 여러가지 측면에서 다 만족스러운 사람을 채용하는 것이 베스트겠지만, 긴가 민가 하거나 리스크가 걱정 되는 상황에서의 채용을 해야 되는 상황이라면, 역량이 부족하지만 태도가 좋은 사람을 채용하고, 이 사람의 스킬과 업무 스킬에 도움을 주는 쪽이 더 낫다고 생각한다.</p>

<h2 id="마치며">마치며</h2>

<p>결국은 사람과 사람이 하는 일이다 보니, 왜 날이 선 사람, 자신만 옳다고 느끼는 사람, 동료에 대한 존중이 부족한 사람에 대한 채용을 꺼려 하는지 잘 알게 됐다.</p>

<p>나 역시 고집스럽고, 자신감이 과도하게 넘쳐서 타인의 의견을 무시하는 행위, 설득이 아니라 억지를 부리는 시기가 있었다.</p>

<p>이 시기에 좋은 동료와 상사에게 피드백을 받았고, 이러한 부분이 얼마나 팀에 나쁜 영향을 주는 지를 이해하고 고치려 노력했다.</p>

<p>혹시나 과거의 나와 같은 성향을 가졌다면, 성향을 바꾸고 노력한다는 것이 쉽지 않다는 것은 알지만, 이를 통해 더 나은 프로덕트, 역량 발전, 즐거운 회사 생활에 보탬이 된다는 것을 알고 노력하는 사람이 조금이라도 더 많아지면 좋겠다.</p>


                <hr>
                
                <hr>

                
                
                
                
                

                
            </div>
</article></div>

Elky Essay

개요
개발자로 일하다 보면 생각보다 많은 수의 개발자가, 솔로 플레이처럼 일하는 경우가 많다.
함께 일한다는 의미는, 서로의 생각과 방향이 비슷해지고, 서로 돕고 도움 받는 것을 통해 시너지가 나는 것이라고 생각한다.
허나 나의 판단만 옳다고 여기거나, 내가 틀릴 리 없어와 같은 생각으로 문제 상황을 회피하거나 숨기는 경향을 보이는 경우도 많다.
애석하게도 버그는 개발자에게 필연적인 요소다. 버그가 없었다면 난도가 높지 않았거나, 이미 숙련된 일을 해내고 있을 확률이 높다.
훌륭한 개발자들이 모여있을 빅 테크의 제품도, 수없이 많은 버그 픽스와 보안 패치가 이뤄진다.
이는 당연하게도 버그란 없을 수 없고, 때로는 요구 사항에 대한 이해도 차이로도 버그로 판정될 수도 있다는 뜻이다.
결국은 팀 작업
Dev Toy 프로덕트나, 스타트업의 MVP, 인하우스 혹은 백 오피스 도구 중에서도 규모 작은 수준의 제품이라면 모를까 고도화가 되거나 제품이 커지다 보면 결국 팀 작업이 된다.
내가 똑똑함을, 내 생각이 옳음을 증명하기 보다는 근거를 만들고 설득을 시도하는 습관이 좋다.
많은 회사가 개발자 채용 시에, 근거 기반의 사고, 논리력을 보는 경우가 많은데 바로 그렇게 일하는 사람이 팀에, 회사에 도움이 된다는 것을 체감했기 때문이다.
결국 건강한 토론을 해야 되는데, 닫혀있는 사람과는 소모적인 토론이 일어나기 때문이다.
심지어는 자신만 옳다고 여기는 사람은, 토론 자체가 성립이 안되는 경우도 생기기 때문에, 팀을 구성하는 데에 있어 리더, 구성원 할 거 없이 열려 있는 사람이 좋은 결과로 이어진다고 생각한다.
그렇다고 역량이 안 중요하진 않지만…
역량이 부족하면 결국 다른 구성원들이 메꿔야 되는 상황도 존재하고, 기술 부채도 더 많이 만들게 되는 등 다양한 문제를 만드는 것은 사실이다.
하지만 개인적인 경험상 역량이 부족한 사람보다, 닫혀 있는 사람이 더 팀웍이나 팀 퍼포먼스에 악영향을 줬다.
물론 여러가지 측면에서 다 만족스러운 사람을 채용하는 것이 베스트겠지만, 긴가 민가 하거나 리스크가 걱정 되는 상황에서의 채용을 해야 되는 상황이라면, 역량이 부족하지만 태도가 좋은 사람을 채용하고, 이 사람의 스킬과 업무 스킬에 도움을 주는 쪽이 더 낫다고 생각한다.
마치며
결국은 사람과 사람이 하는 일이다 보니, 왜 날이 선 사람, 자신만 옳다고 느끼는 사람, 동료에 대한 존중이 부족한 사람에 대한 채용을 꺼려 하는지 잘 알게 됐다.
나 역시 고집스럽고, 자신감이 과도하게 넘쳐서 타인의 의견을 무시하는 행위, 설득이 아니라 억지를 부리는 시기가 있었다.
이 시기에 좋은 동료와 상사에게 피드백을 받았고, 이러한 부분이 얼마나 팀에 나쁜 영향을 주는 지를 이해하고 고치려 노력했다.
혹시나 과거의 나와 같은 성향을 가졌다면, 성향을 바꾸고 노력한다는 것이 쉽지 않다는 것은 알지만, 이를 통해 더 나은 프로덕트, 역량 발전, 즐거운 회사 생활에 보탬이 된다는 것을 알고 노력하는 사람이 조금이라도 더 많아지면 좋겠다.

함께 일하기

댓글