<div id="readability-page-1" class="page"><div>
 <a href="/m/category/%EA%B8%B0%ED%83%80">기타</a><h2>[번역] 지루한 기술을 선택해라 (Choose Boring Technology, Dan McKinley)</h2>
 <cite>
 chancethecoder
 </cite>
 </div><time>2020. 11. 16. 15:11</time>
 
 
 <a href="#comment" onclick="Utils.smoothScroll(this);return false">
 
 </a>
 
 
 
 
 
 
 
 <div>
 해당 글의 원문은 아래에서 확인하실 수 있습니다. (저자의 확인을 받고 작성한 번역 글입니다.)
<a href="https://mcfunley.com/choose-boring-technology">https://mcfunley.com/choose-boring-technology</a>
<figure id="og_1605285032678" contenteditable="false" data-ke-type="opengraph" data-og-type="website" data-og-title="Choose Boring Technology" data-og-description="Probably the single best thing to happen to me in my career was having had Kellan placed in charge of me. I stuck around long enough to see Kellan’s technical decisionmaking start to bear fruit. I learned a great deal from this, but I also learned a grea" data-og-host="mcfunley.com" data-og-source-url="https://mcfunley.com/choose-boring-technology" data-og-url="https://mcfunley.com/choose-boring-technology" data-og-image="https://scrap.kakaocdn.net/dn/mPxXA/hyIeeHaQL0/jJp7r9UdbdC30Lj5g2KLD1/img.jpg?width=697&amp;height=697&amp;face=416_138_461_188,https://scrap.kakaocdn.net/dn/xnK9A/hyIc9nc1S6/TpG6EReGePO4xHC2ZwVjT1/img.jpg?width=697&amp;height=697&amp;face=416_138_461_188"><a href="https://mcfunley.com/choose-boring-technology" target="_blank" rel="noopener" data-source-url="https://mcfunley.com/choose-boring-technology">

<div>
Choose Boring Technology
Probably the single best thing to happen to me in my career was having had Kellan placed in charge of me. I stuck around long enough to see Kellan’s technical decisionmaking start to bear fruit. I learned a great deal from this, but I also learned a grea
mcfunley.com
</div>
</a><img src="https://scrap.kakaocdn.net/dn/mPxXA/hyIeeHaQL0/jJp7r9UdbdC30Lj5g2KLD1/img.jpg?width=697&amp;height=697&amp;face=416_138_461_188,https://scrap.kakaocdn.net/dn/xnK9A/hyIc9nc1S6/TpG6EReGePO4xHC2ZwVjT1/img.jpg?width=697&amp;height=697&amp;face=416_138_461_188"></figure>
<hr contenteditable="false" data-ke-type="horizontalRule" data-ke-style="style1">
<h3 id="id-지루한기술을선택해라(번역ChooseBoringTechnology,DanMcKinley)-지루함을받아들여라" data-ke-size="size23">지루함을 받아들여라</h3>
모든 회사가 혁신 토큰을 세 개 정도 받는다고 가정합시다. 당신은 여기서 원하는 만큼 사용할 수 있지만, 수량은 한정되어있습니다. 일정 수준의 안정성과 성숙도를 얻는다면 토큰은 조금 늘어나겠지만, 일반적으로는 본인이 가진 것을 과대평가하는 경향이 있습니다. 이 모델은 유사치에 해당하지만, 어느 정도는 맞을 겁니다.
당신이 웹사이트 제작을 위해 NodeJS를 사용하기로 했다면, 1개의 토큰을 사용한것입니다. 여기에 MongoDB를 사용한다면, 1개의 토큰을 사용한것입니다. 여기에 유지된 지 1년이 채 안 된 서비스 디스커버리 솔루션(<a href="https://www.consul.io/">Consul</a>)을 사용한다면, 1개의 토큰을 사용한것입니다. 여기에 당신이 자체 제작한 데이터베이스를 사용한다면 엄청난 곤경에 처하게 될 겁니다.
만약 당신이 자바스크립트 컨설턴트거나, 데이터베이스 회사에 다닌다면 이런 선택이 합리적일 수는 있습니다. 하지만 아마도 그렇지는 않을 겁니다. 당신은 Etsy에서, 혹은 stripe에서, 혹은 특정 목표를 추구하는 회사에서 일 하고 있을 겁니다. (Etsy, stripe은 저자가 다닌 회사) 이런 맥락에서, SSH를 혁신하는 일에 당신의 제한된 집중력을 쏟는 것은 실패로 가는 길이거나, 잘 해도 성공을 지연시키는 길입니다.
지루한게 무엇을 의미할까요? 약간 교묘하지만, "지루함"을 "나쁜것"과 합치면 안됩니다. 세상에는 지루하면서 나쁜 기술이 존재합니다. 이들은 사용하면 안되겠죠. 하지만 지루하면서 좋은 기술, 적어도 괜찮은 기술도 존재합니다. MySQL은 지루합니다. Postgres는 지루합니다. PHP는 지루합니다. Python은 지루합니다. Memcached는 지루합니다. Squid는 지루합니다. Cron은 지루합니다.
(한정적이지만) 지루한 것의 좋은 점은 이들의 능력이 잘 알려져 있다는 점입니다. 하지만, 그보다 중요한 것은 이들의 한계도 잘 알려져 있다는 것입니다. 저를 잘 아는 사람이라면 Donald Rumsfeld의 망령을 불러일으키는 것이 저를 엄청나게 불쾌하게 만든다는 것을 알고 있을 겁니다만, 지금은 그렇게 해야만 하겠네요. (저자가 럼스펠드를 극도로 싫어하는 듯.&nbsp;<a href="https://en.wikipedia.org/wiki/There_are_known_knowns">그의 브리핑</a>과 연관 있음.) 기술을 선택할 때, 당신에게는 두 가지가 있습니다. 모르는지를 아는 것과 모르는지 조차 모르는 것들. (<a href="https://en.wikipedia.org/wiki/I_know_that_I_know_nothing">소크라테스 역설</a>&nbsp;참고)
<ul>
<li>
모르는지 아는 것: 우리는 이 데이터베이스가 100%의 CPU에 달하면 어떤 동작을 하는지 모릅니다.
</li>
<li>
모르는지 모르는 것:&nbsp;<a href="https://www.evanjones.ca/jvm-mmap-pause.html">JVM stats를 쓰는 게 GC Pause를 야기</a>시킬 수 있는지 전혀 몰랐습니다.
</li>
</ul>
두 가지 경우 모두 존재합니다. 오래된 기술도 마찬가지로요. 그러나, 주목받는 신기술일수록 모르고있는 것의 크기가 더 크며, 이것은 매우 중요한 사실입니다.
<h3 id="id-지루한기술을선택해라(번역ChooseBoringTechnology,DanMcKinley)-넓은범위로최적화해라" data-ke-size="size23">넓은 범위로 최적화해라</h3>
저는 지루한 기술을 선호하는 편견이 좋다고 생각하지만, 고려해야할 유일한 사항은 아닙니다. 기술적인 선택은 개별적으로 이루어지는 것이 아닙니다. 기술에는 팀, 조직, 혹은 특정 범위의 시스템 등 영향을 미치는 범위가 존재합니다.
당신이 회사의 기술 스택에 새로운 기술을 추가하는 것은 비용을 수반합니다. 추상적이지만, 다음 문장은 명백합니다: "우리가 이미 Ruby를 사용하고 있다면, 거기에 추가적으로 Python을 섞어서 쓰는 것은 현명하지 않다" 왜냐하면 결과적으로 올라가는 복잡성이 Python의 효용성을 능가할 것이기 때문입니다. 하지만 우리가 Python과 Scala, 혹은 MySQL과 Redis에 대해서 이야기를 할 때, 사람들은&nbsp;<a href="https://martinfowler.com/bliki/PolyglotPersistence.html">정신을 놓고</a>&nbsp;(저자가 Polyglot programming을 비꼬는 것 같음) 모든 제약을 버리면서 뭘 사용할지에 대해 열광하기 시작합니다.
간단히 말해서, 소프트웨어를 선택하는 것은 비즈니스 문제를 솔루션 공간에 매핑시키는 것입니다. 소프트웨어 선택에 짐이 없다면, 당신은 지역적으로는 문제해결에 적당할 지 모르지만 전체적으로는 엉망인 선택을 하게 될 것입니다. 하지만 물론 짐은 존재합니다. 우리는 그 짐을 "운영" 혹은 "인지적 부하"라고 부릅니다. 당신은 모니터링을 해야합니다. 유닛 테스트도 계속 생각해야하죠. 기초 지식도 알아야 합니다. init 스크립트도 필요합니다. 며칠만 지나도 이 모든 것이 빠르게 반복됩니다.
"일처리에 적합한 도구"를 생각하는 것의 문제점은 "일"과 "적합성"에 근시안적인 시각을 가지게 한다는 점입니다. 당신이 해야할 일은 회사가 비즈니스적으로 잘 돌아가도록 하는 것입니다. 그리고 "최선"의 도구는 가능한 많은 문제에 대해 "최소한의 최악"의 포지션을 차지하는 것입니다. 시스템이 안정적으로 유지되는 데 드는 비용은 항상 시스템을 만들 때 발생하는 불편함의 비용을 훨씬 능가했습니다. 성숙하고 생산적인 개발자라면 이를 알고 있어야합니다.
<h3 id="id-지루한기술을선택해라(번역ChooseBoringTechnology,DanMcKinley)-가끔은새로운기술을선택해라" data-ke-size="size23">가끔은 새로운 기술을 선택해라</h3>
위의 추론을 귀류법으로 생각해보면 웹사이트를 만들 때 Java 이외에 어떤 것도 사용하지 않아야 할 것입니다. 그리고 그 것은 미친 짓이죠. 도구상자에 몇 가지를 추가할 수단이 필요합니다.
중요한 첫 단계는 이 것이 프로세스고, 대화라는 것을 깨닫는 것입니다. 새로운 기술은 결국 회사 전체에 영향을 줄 것이고, 따라서 새로운 기술을 도입하는 것은 회사 전반의 관점이 필요한 결정입니다. 조직은 특성에 따라 서로의 대화를 강요 할 수도, 누구와도 대화하지 않고 새 데이터베이스와 큐를 추가하게 만들 수도 있습니다. 어떤 식이든 여러분은&nbsp;새로운 기술이 우리 모두가 동의하는 것이라는 문화적 기대감을 형성해야 합니다.
여기서 제가 추천하는 방법은&nbsp;새로운 어떤 기술도 추가하지 않고 당면한 문제를 어떻게 해결할지 생각해보는 방법입니다. 먼저, 이 질문을 던짐으로써 누군가가 새로운 기술을 사용하려 하는 "문제"가 있는 상황을 감지할 수 있습니다. 만약 그렇다면, 당신은 그 상황을 곧바로 저지해야 합니다. (내가 이 그래프 데이터베이스에 대한 웨비나를 봤는데, 이거 우리 해보자! → 놉)
작은 기술셋으로 얼마나 많은 것을 할 수 있는지 알면 놀라울 수도 있습니다. 위 방법의 질문에 대한 답변은 거의 "불가능해요" 보다 대부분은 "글쎄요, 해보긴 하겠는데, 너무 어렵겠네요" 정도에 가까울 겁니다. 만약 여러분이 현재 가지고있는 것으로 목표를 달성할 수 없다고 생각한다면, 여러분들은 아마도 충분히 창의적으로 생각하지 않은 것일 수 있습니다.
현재 스택에서&nbsp;문제를 해결하기에 너무 비싸고 어렵게 만드는 것이 무엇인지 정확하게 적어두는 방법은 매우 도움이 될 겁니다. 이는 위에 말한 방법과 연관이 있지만, 조금 다릅니다.
새로운 기술 선택이 기존에 없던 것을 추가할 수 있습니다. (예를 들어: 우린 아직 캐시 레이어가 없습니다. Memcached를 추가합시다.) 그러나 이미 사용중인 것과 겹치거나 대체될 수도 있습니다. 만약 그렇다면, 당신은&nbsp;기존 기능을 새로운 시스템으로 이전하는 것에 대한 정확한 기대치를 설정해야 합니다. 정책은 정해진 기간 안에 "이전하는 것에 모두 동의"와 같아야 합니다. 이 과정의 의도는 파편화된 실수를 관리 가능한 수준으로 줄이고, 근시안적인 결과물을 방지하고자 하는 것입니다.
이 과정은 부담스럽지 않으며, 그다지 번거롭지도 않습니다. 정책 회의에 이어서 질문을 간단히 작성하면 됩니다. 새로운 기술(또는 인프라에 구축될 새로운 서비스)이 이러한 과정을 통과한다면, 이를 적용하는 것은 괜찮습니다.
<h3 id="id-지루한기술을선택해라(번역ChooseBoringTechnology,DanMcKinley)-그저소프트웨어를만들어라" data-ke-size="size23">그저 코드를 배포해라</h3>
Polyglot Programming은 개발자가 자유롭게 자신의 도구를 선택할 수 있도록 하면 문제 해결에 더 효과적일 수 있다는 기대를 줍니다. 이것은 기껏해야 문제를 단순히 정의한것이며, 최악의 경우 동기 추론(정당화)입니다. 매일의 운영 업무에 대한 짐은 여러분들의 몫입니다.
기술에 대한 신중한 선택은 엔지니어적인 사고방식을 가진 사람들에게 진정한 자유, 즉 더 큰 문제를 생각할 수 있는 자유를 가져다줍니다. 기술 그 자체를 위한 것은 터무니 없는 소리입니다.
 
 
					
 
 
 </div></div>

생각나는대로 적어본다.

해당 글의 원문은 아래에서 확인하실 수 있습니다. (저자의 확인을 받고 작성한 번역 글입니다.)
https://mcfunley.com/choose-boring-technology
지루함을 받아들여라
모든 회사가 혁신 토큰을 세 개 정도 받는다고 가정합시다. 당신은 여기서 원하는 만큼 사용할 수 있지만, 수량은 한정되어있습니다. 일정 수준의 안정성과 성숙도를 얻는다면 토큰은 조금 늘어나겠지만, 일반적으로는 본인이 가진 것을 과대평가하는 경향이 있습니다. 이 모델은 유사치에 해당하지만, 어느 정도는 맞을 겁니다.
당신이 웹사이트 제작을 위해 NodeJS를 사용하기로 했다면, 1개의 토큰을 사용한것입니다. 여기에 MongoDB를 사용한다면, 1개의 토큰을 사용한것입니다. 여기에 유지된 지 1년이 채 안 된 서비스 디스커버리 솔루션(Consul)을 사용한다면, 1개의 토큰을 사용한것입니다. 여기에 당신이 자체 제작한 데이터베이스를 사용한다면 엄청난 곤경에 처하게 될 겁니다.
만약 당신이 자바스크립트 컨설턴트거나, 데이터베이스 회사에 다닌다면 이런 선택이 합리적일 수는 있습니다. 하지만 아마도 그렇지는 않을 겁니다. 당신은 Etsy에서, 혹은 stripe에서, 혹은 특정 목표를 추구하는 회사에서 일 하고 있을 겁니다. (Etsy, stripe은 저자가 다닌 회사) 이런 맥락에서, SSH를 혁신하는 일에 당신의 제한된 집중력을 쏟는 것은 실패로 가는 길이거나, 잘 해도 성공을 지연시키는 길입니다.
지루한게 무엇을 의미할까요? 약간 교묘하지만, "지루함"을 "나쁜것"과 합치면 안됩니다. 세상에는 지루하면서 나쁜 기술이 존재합니다. 이들은 사용하면 안되겠죠. 하지만 지루하면서 좋은 기술, 적어도 괜찮은 기술도 존재합니다. MySQL은 지루합니다. Postgres는 지루합니다. PHP는 지루합니다. Python은 지루합니다. Memcached는 지루합니다. Squid는 지루합니다. Cron은 지루합니다.
(한정적이지만) 지루한 것의 좋은 점은 이들의 능력이 잘 알려져 있다는 점입니다. 하지만, 그보다 중요한 것은 이들의 한계도 잘 알려져 있다는 것입니다. 저를 잘 아는 사람이라면 Donald Rumsfeld의 망령을 불러일으키는 것이 저를 엄청나게 불쾌하게 만든다는 것을 알고 있을 겁니다만, 지금은 그렇게 해야만 하겠네요. (저자가 럼스펠드를 극도로 싫어하는 듯. 그의 브리핑과 연관 있음.) 기술을 선택할 때, 당신에게는 두 가지가 있습니다. 모르는지를 아는 것과 모르는지 조차 모르는 것들. (소크라테스 역설 참고)
모르는지 아는 것: 우리는 이 데이터베이스가 100%의 CPU에 달하면 어떤 동작을 하는지 모릅니다.
모르는지 모르는 것: JVM stats를 쓰는 게 GC Pause를 야기시킬 수 있는지 전혀 몰랐습니다.
두 가지 경우 모두 존재합니다. 오래된 기술도 마찬가지로요. 그러나, 주목받는 신기술일수록 모르고있는 것의 크기가 더 크며, 이것은 매우 중요한 사실입니다.
넓은 범위로 최적화해라
저는 지루한 기술을 선호하는 편견이 좋다고 생각하지만, 고려해야할 유일한 사항은 아닙니다. 기술적인 선택은 개별적으로 이루어지는 것이 아닙니다. 기술에는 팀, 조직, 혹은 특정 범위의 시스템 등 영향을 미치는 범위가 존재합니다.
당신이 회사의 기술 스택에 새로운 기술을 추가하는 것은 비용을 수반합니다. 추상적이지만, 다음 문장은 명백합니다: "우리가 이미 Ruby를 사용하고 있다면, 거기에 추가적으로 Python을 섞어서 쓰는 것은 현명하지 않다" 왜냐하면 결과적으로 올라가는 복잡성이 Python의 효용성을 능가할 것이기 때문입니다. 하지만 우리가 Python과 Scala, 혹은 MySQL과 Redis에 대해서 이야기를 할 때, 사람들은 정신을 놓고 (저자가 Polyglot programming을 비꼬는 것 같음) 모든 제약을 버리면서 뭘 사용할지에 대해 열광하기 시작합니다.
간단히 말해서, 소프트웨어를 선택하는 것은 비즈니스 문제를 솔루션 공간에 매핑시키는 것입니다. 소프트웨어 선택에 짐이 없다면, 당신은 지역적으로는 문제해결에 적당할 지 모르지만 전체적으로는 엉망인 선택을 하게 될 것입니다. 하지만 물론 짐은 존재합니다. 우리는 그 짐을 "운영" 혹은 "인지적 부하"라고 부릅니다. 당신은 모니터링을 해야합니다. 유닛 테스트도 계속 생각해야하죠. 기초 지식도 알아야 합니다. init 스크립트도 필요합니다. 며칠만 지나도 이 모든 것이 빠르게 반복됩니다.
"일처리에 적합한 도구"를 생각하는 것의 문제점은 "일"과 "적합성"에 근시안적인 시각을 가지게 한다는 점입니다. 당신이 해야할 일은 회사가 비즈니스적으로 잘 돌아가도록 하는 것입니다. 그리고 "최선"의 도구는 가능한 많은 문제에 대해 "최소한의 최악"의 포지션을 차지하는 것입니다. 시스템이 안정적으로 유지되는 데 드는 비용은 항상 시스템을 만들 때 발생하는 불편함의 비용을 훨씬 능가했습니다. 성숙하고 생산적인 개발자라면 이를 알고 있어야합니다.
가끔은 새로운 기술을 선택해라
위의 추론을 귀류법으로 생각해보면 웹사이트를 만들 때 Java 이외에 어떤 것도 사용하지 않아야 할 것입니다. 그리고 그 것은 미친 짓이죠. 도구상자에 몇 가지를 추가할 수단이 필요합니다.
중요한 첫 단계는 이 것이 프로세스고, 대화라는 것을 깨닫는 것입니다. 새로운 기술은 결국 회사 전체에 영향을 줄 것이고, 따라서 새로운 기술을 도입하는 것은 회사 전반의 관점이 필요한 결정입니다. 조직은 특성에 따라 서로의 대화를 강요 할 수도, 누구와도 대화하지 않고 새 데이터베이스와 큐를 추가하게 만들 수도 있습니다. 어떤 식이든 여러분은 새로운 기술이 우리 모두가 동의하는 것이라는 문화적 기대감을 형성해야 합니다.
여기서 제가 추천하는 방법은 새로운 어떤 기술도 추가하지 않고 당면한 문제를 어떻게 해결할지 생각해보는 방법입니다. 먼저, 이 질문을 던짐으로써 누군가가 새로운 기술을 사용하려 하는 "문제"가 있는 상황을 감지할 수 있습니다. 만약 그렇다면, 당신은 그 상황을 곧바로 저지해야 합니다. (내가 이 그래프 데이터베이스에 대한 웨비나를 봤는데, 이거 우리 해보자! → 놉)
작은 기술셋으로 얼마나 많은 것을 할 수 있는지 알면 놀라울 수도 있습니다. 위 방법의 질문에 대한 답변은 거의 "불가능해요" 보다 대부분은 "글쎄요, 해보긴 하겠는데, 너무 어렵겠네요" 정도에 가까울 겁니다. 만약 여러분이 현재 가지고있는 것으로 목표를 달성할 수 없다고 생각한다면, 여러분들은 아마도 충분히 창의적으로 생각하지 않은 것일 수 있습니다.
현재 스택에서 문제를 해결하기에 너무 비싸고 어렵게 만드는 것이 무엇인지 정확하게 적어두는 방법은 매우 도움이 될 겁니다. 이는 위에 말한 방법과 연관이 있지만, 조금 다릅니다.
새로운 기술 선택이 기존에 없던 것을 추가할 수 있습니다. (예를 들어: 우린 아직 캐시 레이어가 없습니다. Memcached를 추가합시다.) 그러나 이미 사용중인 것과 겹치거나 대체될 수도 있습니다. 만약 그렇다면, 당신은 기존 기능을 새로운 시스템으로 이전하는 것에 대한 정확한 기대치를 설정해야 합니다. 정책은 정해진 기간 안에 "이전하는 것에 모두 동의"와 같아야 합니다. 이 과정의 의도는 파편화된 실수를 관리 가능한 수준으로 줄이고, 근시안적인 결과물을 방지하고자 하는 것입니다.
이 과정은 부담스럽지 않으며, 그다지 번거롭지도 않습니다. 정책 회의에 이어서 질문을 간단히 작성하면 됩니다. 새로운 기술(또는 인프라에 구축될 새로운 서비스)이 이러한 과정을 통과한다면, 이를 적용하는 것은 괜찮습니다.
그저 코드를 배포해라
Polyglot Programming은 개발자가 자유롭게 자신의 도구를 선택할 수 있도록 하면 문제 해결에 더 효과적일 수 있다는 기대를 줍니다. 이것은 기껏해야 문제를 단순히 정의한것이며, 최악의 경우 동기 추론(정당화)입니다. 매일의 운영 업무에 대한 짐은 여러분들의 몫입니다.
기술에 대한 신중한 선택은 엔지니어적인 사고방식을 가진 사람들에게 진정한 자유, 즉 더 큰 문제를 생각할 수 있는 자유를 가져다줍니다. 기술 그 자체를 위한 것은 터무니 없는 소리입니다.

[번역] 지루한 기술을 선택해라 (Choose Boring Technology, Dan McKinley)

댓글