<p style="text-align:justify;">본문은 <a href="https://www.deepl.com/translator"><u>deepL</u></a>을 활용해 만든 해외 번역 콘텐츠입니다. 필자인 <a href="https://taylor.town/"><u>테일러 트로시(Taylor Troesh)</u></a>는 소프트웨어 엔지니어로 최근 스텔스 AI 스타트업 ‘Gob’를 설립했습니다. 이 글은 10x 엔지니어가 아닌 -10배의 엔지니어가 되는 법에 대해 작가의 개인적인 견해를 담은 글입니다. <a href="https://www.wishket.com/w/mwtyETYqSy"><u>‘10배 이상 뛰어난 개발자가 되는 법’</u></a>과 함께 읽어보셔도 좋을 것 같습니다.</p><div class="page-break" style="page-break-after:always;"><span style="display:none;"> </span></div><figure class="image image_resized" style="width:100%;"><img src="https://yozm.wishket.com/media/news/2012/image1.jpg" alt="-10배 엔지니어"><figcaption><출처: freepik></figcaption></figure><p style="text-align:justify;"> </p><p style="text-align:justify;">+10배의 엔지니어는 신화적인 인물일지 몰라도 -10배의 엔지니어는 존재합니다. -10배의 엔지니어가 되려면 주당 400시간의 엔지니어링 시간을 신나게 낭비하면 됩니다. 아래의 전략들을 조합해 보세요.</p><p style="text-align:justify;"> </p><p style="text-align:justify;"> </p><h3 style="text-align:justify;"><strong>엔지니어 10명의 결과물을 무효화합니다</strong></h3><p style="text-align:justify;">가능한 한 개발 단계에서 요구 사항을 변경하세요. 비난을 피하려면 처음부터 요구 사항을 읽기 어렵게 만드는 것이 좋습니다.</p><p style="text-align:justify;"> </p><p style="text-align:justify;"> </p><h3 style="text-align:justify;"><strong>400시간 분량의 바쁜 작업을 만듭니다</strong></h3><p style="text-align:justify;">팀이 유사한 작업을 계속 수행하도록 요청하세요. 프레젠테이션, 다이어그램, 티켓 관리 등이 일반적인 예입니다. 무의미한 일을 계속해서 만드세요.</p><p style="text-align:justify;"> </p><p style="text-align:justify;"> </p><h3 style="text-align:justify;"><strong>번아웃을 독려하세요</strong></h3><p style="text-align:justify;">매사 감사할 줄 모르고 남 탓만 하면 됩니다. 혼란을 조성하고 자주 화를 내며, 다른 사람들이 초과 근무를 하게 만듭니다.</p><p style="text-align:justify;"> </p><p style="text-align:justify;"> </p><h3 style="text-align:justify;"><strong>엔지니어 10명을 기술 토론에 강제로 잡아둡니다</strong></h3><p style="text-align:justify;">엔지니어들이 아이디어를 토론하게 합니다. 실용주의보다 우아함을 추구하도록 격려하며, 누구도 결정을 내릴 권한을 갖지 못하게 하세요.</p><p style="text-align:justify;"> </p><p style="text-align:justify;"> </p><h3 style="text-align:justify;"><strong>커뮤니케이션에 많은 시간을 쓰게 하세요</strong></h3><p style="text-align:justify;">회의는 캘린더를 망칠 뿐입니다. 다른 사람의 시간을 눈에 띄지 않게 낭비하려면, 긴 메시지 또는 문서를 작성하여 가능한 한 널리 공유하세요. 모든 의견을 환영하고 참여를 목표로 합니다.</p><p style="text-align:justify;"> </p><p style="text-align:justify;"> </p><h3 style="text-align:justify;"><strong>클라우드 비용으로 10주치 임금을 낭비하세요</strong></h3><p style="text-align:justify;">느린 프로그램을 작성하고, DB 인덱스를 사용하지 마세요. 16코어 컴퓨터에서 단일 스레드 프로그램을 실행하고, 화려한 RAM과 GPU를 갖춘 이색적인 하드웨어를 선택하세요. RAM/디스크에 데이터를 넉넉하게 저장하고 아무것도 압축하지 마세요. 데이터 레이아웃에 신경 쓰지 마세요.</p><p style="text-align:justify;"> </p><p style="text-align:justify;"> </p><h3 style="text-align:justify;"><strong>쓸모없는 도구를 만듭니다</strong></h3><p style="text-align:justify;">기존 솔루션이 꼭 필요하지 않다고 판단합니다. 한 사람만 이해할 수 있는 스크립트를 작성하고, 스크립트가 중요한 작업을 수행하는 경우 문서화하지 마세요.</p><p style="text-align:justify;"> </p><p style="text-align:justify;"> </p><h3 style="text-align:justify;"><strong>컴파일/빌드에 400시간을 추가합니다</strong></h3><p style="text-align:justify;">느린 빌드는 시간을 낭비하고 복합적인 관심을 일으킵니다. 빌드 시간이 길어질수록 개발자는 집중력이 흐트러질 가능성이 높아집니다. 개발자가 컨텍스트를 전환할 수 있도록 재컴파일 시간은 최소 20초가 소요되어야 합니다. 느린 테스트를 작성해도 비슷한 효과를 얻을 수 있습니다.</p><p style="text-align:justify;"> </p><p style="text-align:justify;"> </p><h3 style="text-align:justify;"><strong>무의미한 테스트를 작성하세요</strong></h3><p style="text-align:justify;">기본 기능을 테스트하지 않고 특정 변수에 대한 종속성을 생성합니다. 원본 코드가 실행되지 않을 때까지 모의 함수 호출을 수행합니다. 테스트에 무작위성을 도입하여 이유 없이 테스트가 성공, 실패하도록 합니다.</p><p style="text-align:justify;"> </p><p style="text-align:justify;"> </p><h3 style="text-align:justify;"><strong>잘못된 아키텍처에 엔지니어링 400시간을 낭비하세요</strong></h3><p style="text-align:justify;">시간이 지남에 따라 시스템 설계가 어떻게 진화할지 전혀 고려하지 마세요. 또는 팀이 아키텍처 결정에 집착하도록 유도하여 가설을 테스트할 시간이 없도록 만드세요.</p><p style="text-align:justify;"> </p><figure class="image image_resized" style="width:100%;"><img src="https://yozm.wishket.com/media/news/2012/image2.jpg" alt="-10배 엔지니어"><figcaption><출처: freepik></figcaption></figure><p style="text-align:justify;"> </p><h3 style="text-align:justify;"><strong>배포에 400시간을 낭비하세요</strong></h3><p style="text-align:justify;">가능한 한 많은 환경을 만드세요. 프로덕션 환경과 스테이징 환경은 크게 달라야 합니다. 취약한 빌드 시스템으로 취약한 코드를 실행하고, 데이터베이스를 자주 마이그레이션합니다.</p><p style="text-align:justify;"> </p><p style="text-align:justify;"> </p><h3 style="text-align:justify;"><strong>불만족 고객으로 인해 10주치 임금을 낭비하세요</strong></h3><p style="text-align:justify;">심각한 버그를 반복적으로 감지하지만 이를 해결하지 마세요. 보안 취약점이 있어도 주의하지 않습니다.</p><p style="text-align:justify;"> </p><p style="text-align:justify;"> </p><h3 style="text-align:justify;"><strong>쓸모없는 문서를 작성하세요</strong></h3><p style="text-align:justify;">개인 메시지로 코드를 설명하고, 아무도 사용하지 않는 위키를 작성합니다.</p><p style="text-align:justify;"> </p><p style="text-align:justify;"> </p><h3 style="text-align:justify;"><strong>쓸데없는 프로젝트에 10명의 엔지니어를 묶어두세요</strong></h3><p style="text-align:justify;">유능한 엔지니어를 끌어들여 그들의 잠재력을 낭비합니다. 경영진에게 프로젝트의 난이도를 낮게 평가하고, 프로젝트의 유용성에 대해선 과대평가합니다. 더불어 프로젝트를 폐기할 때까지 경영진에게는 거의 완료되었다고 말합니다.</p><p style="text-align:justify;"> </p><p style="text-align:justify;"> </p><h3 style="text-align:justify;"><strong>유지 보수에 400시간이 필요한 종속성을 추가합니다</strong></h3><p style="text-align:justify;">엔지니어가 각 라이브러리를 개별적으로 학습하게 합니다.</p><p style="text-align:justify;"> </p><p style="text-align:justify;"> </p><h3 style="text-align:justify;"><strong>피벗을 지연시키세요</strong></h3><p style="text-align:justify;">실패를 인정하지 말고 팀을 매몰 비용에 빠뜨립니다. 상황을 개선할 수 있는 80/20 법칙을 무시합니다.</p><p style="text-align:justify;"> </p><p style="text-align:justify;"> </p><h3 style="text-align:justify;"><strong>0x 엔지니어를 10명 고용하세요</strong></h3><p style="text-align:justify;">기회비용은 치명적일 수 있습니다. 성과가 없는 평범한 엔지니어는 팀에 직접적인 해를 미치지는 않지만, 적극적으로 도움을 줄 수 있는 사람들의 자리를 차지하게 됩니다.</p><p style="text-align:justify;"> </p><p style="text-align:justify;"> </p><h3 style="text-align:justify;"><strong>-1x 엔지니어를 5명 추가 고용하세요</strong></h3><p style="text-align:justify;">0x 엔지니어 고용 후 안주하지 마세요. 재앙을 일으키고 학습에 저항하는 엔지니어를 적극적으로 고용하세요.</p><p style="text-align:justify;"> </p><p style="text-align:justify;"> </p><h3 style="text-align:justify;"><strong>-1x 엔지니어가 해고되는 것을 방지하세요</strong></h3><p style="text-align:justify;">그들의 실수를 지적하지 않습니다. 실패의 흔적은 문서로 남기지 않고, 잘못된 엔지니어링을 보증하세요.</p><p style="text-align:justify;"> </p><p style="text-align:justify;"> </p><h3 style="text-align:justify;"><strong>400시간 동안 버그를 분류하세요</strong></h3><p style="text-align:justify;">디버깅할 수 없는 프로그램을 만듭니다. 모든 것에 추상화 레이어를 덧씌우고 스파게티 코드를 작성하세요. 모든 것을 초기 조건에 민감하게 만들고 순수 함수를 피합니다. 종속성을 자유롭게 사용하고, 가능하면 "내 컴퓨터에서 작동합니다"라고 말하세요.</p><hr><p style="text-align:justify;"><함께 읽어보면 좋은 콘텐츠></p><ul><li style="text-align:justify;"><a href="https://www.wishket.com/w/JyJ5X2QxAX"><u>영리한 개발자와 현명한 개발자의 차이점</u></a></li><li style="text-align:justify;"><a href="https://www.wishket.com/w/KN2HmWtfrl"><u>훌륭한 개발자의 5가지 특징</u></a></li></ul><p style="text-align:justify;"> </p><p style="text-align:justify;"><원문></p><p style="text-align:justify;"><a href="https://taylor.town/-10x"><u>How to be a -10x Engineer</u></a></p><p style="text-align:justify;"> </p><p style="text-align:center;"><span style="color:#999999;">위 번역글의 원 저작권은 Taylor Troesh에게 있으며, 요즘IT는 해당 글로 수익을 창출하지 않습니다.</span></p>
