소프트웨어 엔지니어링에서 예측 가능성에 집착하면 자동화를 저해하고 테크니션을 양산하게 된다는 주장과, 실제 사례 및 엔지니어와 테크니션의 차이에 대한 논의.
Haskell for all: 소프트웨어 엔지니어는 (그리고 그래서는) 테크니션이 아니다
===============
소프트웨어 엔지니어는 (그리고 그래서는) 테크니션이 아니다
===============
나는 사실 소프트웨어 엔지니어링에서 예측 가능성이 좋은 것이라고 생각하지 않는다. 이는 일부 사람들(특히 관리자들)에겐 놀랍게 들릴 수 있지만, 내가 무슨 뜻인지 설명하겠다.
내가 보기에 훌륭한 소프트웨어 엔지니어는 반복적/수작업을 자동화하는 사람이다. 이건 기준이 꽤 낮다고 생각할 수도 있다. 반복 작업의 자동화는… 그러니까… 프로그래밍 101 아니던가? 그렇다면 대부분의 소프트웨어 엔지니어가 내 기준으로 훌륭한 엔지니어여야 하지 않나?
아니다.
내 주장은 대부분의 대규모 소프트웨어 엔지니어링 조직이 반(反)자동화를 장려한다는 것이다. 그 주된 이유는 예측 가능성, 특히 예측 가능한 산정과 예측 가능한 업무에 대한 집착 때문이다. 왜냐하면 예측 가능한 일이라는 것은 자동화할 수 있었지만 자동화되지 않은 일인 경우가 많기 때문이다.
이전 직장에서의 예측 가능한 업무 사례를 하나 들겠다. 초기에 우리는 웹 API를 유지보수하는 전담 개발자가 있었다. 다른 팀이 내부 서비스에 새로운 gRPC API 엔드포인트를 추가할 때마다 이 개발자는 동일한 정보를 HTTP API로 노출하는 일을 맡았다. 꽤나 반복적인 일이었지만 여전히 그들의 시간과 고민이 필요했다.
초반에는 관리자는 이 개발자가 (업무가 잘 이해되어 있기 때문에) 신뢰할 수 있게 일정을 산정할 수 있다는 점을 좋아했고, 이 개발자도 자신의 안락한 구역을 벗어나지 않아도 된다는 점을 좋아했다. 하지만 그것은 비즈니스에는 좋지 않았다! 이 사람은 자신의 수작업을 개발 파이프라인의 필수 단계로 끼워 넣었기 때문에 신규 기능 출시의 병목이 되곤 했다. 이들은 수요 증가에 대응하기 위해 자신과 같은 개발자를 더 뽑아야 한다고 경영진에 주장했다.
우리 팀은 이 개발자의 일이 너무 예측 가능해서 완전히 자동화할 수 있다는 점을 지적하며 반대했다. 같은 일을 할 사람을 더 뽑기보다는 자동화를 늘려야 한다고 설득했고, 다행히 그렇게 했다. 그 개발자는 곧 회사를 떠났고, 우리는 대체 인력을 채용하는 대신 그 업무를 자동화해 없애 버렸다. 우리는 해당 gRPC API로부터 HTTP API를 자동 생성하는 코드를 작성했고[1] 이는 새 개발자를 채용하는 것보다 비즈니스에 훨씬 더 큰 가치를 가져왔다.
나는 (A) 일이 충분히 잘 이해되어 있고 (B) 자주 안락한 구역을 벗어날 필요가 없는 일을 하는 개발자를 “테크니션”이라고 부르는 편이다. 물론 엔지니어와 테크니션 사이에 분명한 경계가 있는 것은 아니지만, 일반적으로 일감이 예측 가능하고 루틴할수록 개발자는 테크니션 쪽으로 기울게 된다. 위 예시에서 웹 API를 유지하던 개발자는 엔지니어라기보다는 테크니션에 가까웠다고 본다.
반대로, 누군가가 엔지니어답게 일할수록 그들의 업무(와 일정 산정)는 더 예측 불가능해진다. 지속적으로 자동화하면 예측 가능한 일감은 점차 사라지고 남는 것은 예측 불가능한 일뿐이다. 소프트웨어 엔지니어의 일은 점점 더 많은 것을 자동화할수록 더 도전적이고 야심찬 과제를 다루게 되는 성격을 띤다.
나는 대부분의 테크 기업은 예측 가능성에 편향되어서는 안 되며 테크니션을 채용·육성하는 것을 피해야 한다고 믿는다. 테크 기업이 높은 가치를 인정받는 이유는 자동화 때문이다. 예측 가능하고 잘 이해된 일에 치우치면 자동화 대신 수작업을 부추기게 된다. 많은 테크 기업이 이를 눈치채지 못하는 이유는 코드가 관련되기만 하면 자동화라고 가정하기 때문이지만, 실제로는 항상 그렇지 않다[2]. 이를 인지하지 못한 회사는 과다 채용을 하고, 인원이 늘었는데 왜 일이 덜 끝나는지 의아해하게 된다.
다르게 말하면, 엔지니어나 팀이 예측 가능한 “플로우”에 들어가면 나는 오히려 경고 신호로 본다. 그들이 유망한 자동화 기회를 외면하고 있다는 뜻이기 때문이다.
요즘은 grpc-gateway 같은 기성 도구가 있지만, 당시엔 우리에겐 그런 게 없었다.↩︎
… 아니, 대개 그렇지도 않다. 나는 대부분의 테크 회사의 엔지니어링 효율에 대해 개인적으로 매우 냉소적이다.↩︎
작성: Gabriella Gonzalez, 오전 7:10
이메일로 보내기블로그에 게시X에 공유Facebook에 공유Pinterest에 공유
Speed Salmon2024년 7월 23일 오후 3:02
테크니션에 대한 당신의 기준이 마음에 듭니다. 엔지니어의 최우선 과업은 생각하는 일인데, 그 부담을 자주 회피하게 되고 그러다 보면 테크니션 역할이 유혹적으로 느껴지죠.
[답글](javascript:;)
2. Kevin G. R. Greer2024년 7월 24일 오전 5:29
저도 같은 점을 느꼈습니다. 우리는 코드의 약 95%를 생성하기 때문에 결과적으로 매우 효율적입니다. 그러나 우리는 그다지 예측 가능하지 않습니다. 우리가 작성하는 건 우리가 아직 쓸 줄 모르는(그래서 자동화하지 못한) 5%뿐이기 때문이죠. 알았다면 그것도 자동화했을 겁니다. 어떤 사람들은 이를 답답해하지만, 그렇다고 우리가 예측 가능하게 10배 더 오래 걸리길 바라나요?
우리는 이렇게 합니다: https://www.youtube.com/watch?v=S4LbUv5FsGQ
1.  [Les Tombay](https://www.blogger.com/profile/03314250228640327924)[2024년 7월 26일 오전 9:32](https://www.haskellforall.com/2024/07/software-engineers-are-not-and-should.html?showComment=1722011522935#c52545332903514651)
직관에 반할지 몰라도, 이에 대한 답은 종종 ‘그렇다’입니다. 사람은 불확실성보다 확실성을 선호하는 게 본성이지요. 어떤 상황에서는 비용보다 예측 가능성이 더 선호되기도 합니다. 물론 맥락에 크게 좌우됩니다.
[답글](javascript:;)
1.  [InvaderZ](https://www.blogger.com/profile/14784476331235214633)[2024년 7월 24일 오후 2:06](https://www.haskellforall.com/2024/07/software-engineers-are-not-and-should.html?showComment=1721855179709#c6480464272719366902)
내 생각엔 당신의 포인트가 약간 주제에서 벗어났다고 보지만, 그래도 한 가지 지적하고 싶어 의견을 남깁니다. 당신의 감정/결론은 이해하고, 동의합니다. 다만 다른 면에서 보자면, 그 ‘셸 프로그래머’가 해고된 이유는 아마도 매니저 몰래 일을 벌였기 때문일 겁니다. 그것도 ‘사소한 일’(비즈니스에 위험이 거의 없는)의 수준이 아니라, 당신이 말했듯 중요한 서버 작업과 관련된, 비즈니스 측면에서 ‘치명적일 수 있는’ 영역이었고요. 더 심각한 건, 당신이 썼듯 거의 1년 동안 그게 계속됐다는 점입니다! 무슨 문제가 생겼다면 그게 매니저에게 어떻게 비쳤을지 생각해 보세요. 설령 매니저가 그 모든 걸 무시하고 프로그래머의 관점만 봤다 하더라도, 그가 휴가를 가거나 아프거나 회사를 그만두는 등(즉 상시 혹은 일시 부재) 상황이 되어서 누군가가 그 사실을 알게 되고 그 정보가 경영진에까지 올라갔다면, 그들은 어떻게 받아들였을까요? 게다가 대부분의 (대기업) 조직에는 이런 상황을 어떻게 구현해야 하는지에 대한 정책이 있습니다. ‘체인지 매니지먼트’라 불리는 것으로, 위험 평가, 롤백 전략, 최악의 경우(롤백 실패) 시나리오까지 포함하며, 이는 ‘주요 시스템 자동화’ 프로젝트에 해당하므로 전체 개발·검증·테스트·배포 생애주기를 거쳐 단계적으로 시행됩니다. 물론 그 프로그래머는 ‘학문적으로 똑똑’했을지 모르나, ‘비즈니스 감각’은 분명하지 않았습니다. 물론 그런 건 그 회사의 잘못일 수도 있죠(회사 정책과 절차가 없었거나 제대로 알리지 않았던). 그럼에도 불구하고 결론은 이겁니다. 매니저는, 당신이 어떻게 생각하든, 당신이 직무기술서(SOP) 밖의 일을 하려 한다면 항상 그 과정을 공유받아야 합니다. 그리고 매니저가 당신의 아이디어를 받아들이지 않으면 한 단계 위로 올리세요. 최악의 경우, 당신이 해야 할 일을 계속 하면서 다른 일자리를 찾으면 됩니다(가능한 한 빨리요. 그래서 야망을 붙들고만 있지 말고 진전을 위해 밀어붙이는 게 중요합니다).
[답글](javascript:;)
코딩은 어렵지 않고, 설계도 어렵지 않습니다… 스파게티 코드를 신문 기사처럼 정리해 내는 일이 어렵습니다.
[답글](javascript:;)
5. Nadia Yvette Chambers2024년 7월 24일 오전 7:10
프로그래머의 역할과 예측 불가능성, 혹은 내가 좋아하는 말로는 ‘영감’에 대한 당신의 말이 좋습니다. 다만 사람들이 테크니션들에게 조금 과하게 엄격하게 대하는 건 아닌지 걱정돼요. 자동화가 그들에게 단지 해악이 되지 않게 하거나, 그들의 자리를 어떻게 마련할지에 대한 구체적인 생각이 있는 건 아니지만요.
[답글](javascript:;)
6. Nasser2024년 7월 25일 오전 2:57
잘 말씀하셨습니다.
‘테크니션’의 문제는, 사실을 무시하는 관리자들에게 자신의 일을 더 가치 있는 것으로 포장한다는 점입니다.
[답글](javascript:;)
구독: 게시물 댓글 (Atom)
이 저작물은 크리에이티브 커먼즈 저작자표시 4.0 국제 라이선스에 따라 이용할 수 있습니다. Simple theme. Powered by Blogger.