[ 프로젝트 BEP ] 최종장 - 엔지니어로서의 마인드셋에 대해 : 우수한 엔지니어는 누구이고, 가져야할 마인드 셋에 대해

 

들어가면서

이제 2025년도 얼마 남지 않은듯 하다. 

조금 길어질 수도 있기 때문에 

실제로 업로드 하는 것은 새해 이후가 될 가능성도 있으나 

올해는 이 글로 마무리 해보려고 한다.

이제 이 최종장을 끝으로 이 프로젝트를 다소 마무리 할 수 있을 것 같다.

물론 전체적으로 글 자체가 부족한 부분이 여려 곳 보이지만, 

이는 천천히 개선하기로 하고 일단 마무리를 잘 지어보려고 한다.

이 프로젝트의 목표는 어디까지나 주니어 엔지니어(넓은 범위로서)에게 

도움이 될 수 있는 부분을 정리해 놓은 것 이며, 이를 전달하는 것에 주력을 했다.

정확히는 그 사이에 몇 번이나 직장은 바뀌었지만, 

내가 다니고 있는 회사에서 작게는 멘터, 

크게는 주니어 교육에 활용하기 위한 초안이였다.

들어가기 앞서서 먼저 개발자는 무엇인가에서 부터 시작해서, 

수학은 필요한가, 그리고 학위에 대한 이야기를 나누어보았고,

그 다음으로 컴퓨터가 무엇인가에 대해서는, 

가장 첫 장인 컴퓨터 개론에서 메모리 손실과 함께 설명하였다.

다음으로는 개발 방법론과 시스템 설계, 

그리고 프로그래밍 언어에 대한 이야기로 간단하고 이론적인 이야기를 하였다.

눈치가 빠른 사람은 알 수 있듯이, 

현실에서 가질 수 있는 몇 가지 의문으로 시작해서 

컴퓨터라는 하드웨어 부터 시작해서, 

프로젝트(개발 방법론), 설계, 프로그래밍 언어 순으로 

일부러 점점 컴퓨터 세계로 들어가도록 구성을 해 놓았다.

여기서 한 걸음 더 나아가자면, 알고리즘이 들어갈 수는 있겠으나 

어디까지나 가볍게 전달하는대에 목적이 있기도 하고, 

개인적으로는 당장은 크게 중요하지 않은 부분이 라고 생각 했기 때문이다.

먼저 이 부분에 대해서 좀 더 자세히 이야기해보도록 하자.

시작 부터 모든 지식을 쌓을 수는 없다

이는 개발 영역에서만 해당되는 이야기는 아니지만, 

모든 것에는 순서가 있는 법이다.

순서대로 계단을 밟고 올라가야 1층에서 2층으로 오를 수 있는 것 처럼 말이다.

또한, 솔루션을 위한 기술이 아닌, 학문으로서 이론을 배우고,

사회의 암묵적인 룰을 전혀 모르는 주니어들에게 있어서

미리 쌓을 수 없는 것 들이기 때문에 이는 당연한 것 이다.

개인적으로는 어떠한 사람들이 이야기 하는 '기본'은 

너무나도 터무니 없이 높아 보인다.

물론, 이 이야기 또한 어떻게 바라보느냐에 따라 뉘앙스가 정반대가 될 수 있으나

올라가는 방법에 대해서는 특별한 왕도가 없으며,

기본적으로는 바텀 업 방식과 탑 다운 방식으로 다가갈 수 있다는 점이다. 

때로는 혼용되는 방식으로 가져갈 때도 있지만,

나는 기본적으로 탑 다운 방식을 선호하며, 

내가 멘터로 있을 때에는 멘토를 탑 다운 방식으로 유도하고는 한다.

다만, 때로는 두 가지 방법을 혼용해서 사용할 때가 있는데,

실제로 나는 생성형 AI 관련 이론에 대해서 탐구 할 때는

기본인 Neural Network를 착실히 쌓고, 

그 다음에는 흥미가 있는 순으로 모델을 탐구하고 있다. 

물론 이는 어디까지나 업무와 직접적으로는 관련 없는 

개인적인 흥미에 의해 탐구하고 있는 것이기에 바텀 업 방식을 가져갈 수 있지만,

업무에 있어서는 빠르게 변화하는 업계 특성상, 

업무에서 필요한 기술을 포함한 대부분의 것들은 탑다운 방식으로 가져가고 있다.

물론 이 또한 개발의 영역에서만 통용되는 이야기는 아니다.

상황에 따라 취사 선택할 수 있어야만, 

상황에 따라 현실적 한계를 고려한 문제에 대한 최선의 솔루션이 나올 수 있다.

언제나 최선의 환경이 주어지는 것은 아니며,

대게 굉장히 리소스가 부족한 상황에서 솔루션을 만들어 내야만 한다.

모든 상황에 적용할 수 있는 솔루션은 사실상 이 세상에 존재하지 않는다.

왜냐하면, 이를 적용할 수 있는 법칙이 존재한다면, 

그것이야 말로 진리이기 때문이다.

입버릇 처럼 스스로의 주장을 진리라고 이야기하는 사람은 무척이나 많지만,

진리라는 것은 그렇게 가벼운 단어가 전혀 아니다.

어쨋든, 과거와 다르게 IT업계에서 기술이 발전한 만큼, 

그 기술의 발자국 수도 늘어났고,

그 만큼 알아야할 것(혹은 그렇게 주장하는 것들)도 그 만큼 늘어났기 때문에

그 많은 것들을 이해 시킬 수도 없으며,

이를 가르치려는 본인 스스로도 전부 이해하는 건 사실상 불가능에 가까울 것 이다.

게다가, 과거 보다 복잡해지고 많아진 기술과 

이에 따른 사회에 요구에 따라 기술직 또한 더 깊게 분할 되었다.

인프라 부분은 규모가 작은 서버로도 충분한 경우, 

비싼 장비를 들여와서 사내 IDC 구축해서 보다 클라우드에서 운용 것이 

사실상 유리하기 때문에 

기술의 시프트가 일어난 분야도 존재하지만, 

대부분의 경우 기술의 발달로 인해, 가용할 수 있는 시간이 증가 되었고, 

이를 생산성 증대에 활용되었다.

예컨데, 웹 애플리케이션을 한정으로 이야기한다면,

불과 10~20년 전만해도 백앤드와 프론트의 엄밀한 구분이 사실 상 없었다.

좀 더 정확히는 있었으나, 

백앤드에서 HTML 까지 가공하고 브라우저는 단순히 표시할 뿐이라, 

프론트의 비중이 그렇게 높지 않았던 시대이다.

기술적인 한계 또한 있었으나, 

PHP와 JSP가 자주 사용되었던 타당한 이유가 있는 셈이다.

이 한계가 다소 해소되고 있는 시점과 시대의 흐름, 

정확히는 2010년 초반 전세계에 디바이스는 아이폰, 

애플리케이션에서는 Facebook이 전 세계에 대중화 되면서 

(물론 의도한 결과는 아니겠지만, 소프트웨어 업계에서는 Facebook 가장 큰 역할을 해주었다고 생각 한다.)

좀 더 눈을 즐겁게 해주는 UI/UX가 가미된 소프트 웨어들이 좋은 멀티플을 받게 되면서 

(이 부분은 아이폰의 iOS와 내부 소프트웨어가 가장 큰 역할을 해주었다.)

시대에 요구에 따라 프론트 앤드의 영역이 넓어지기 시작한 것 또한 이유가 있는 셈이다.

단순히 기능 개발에도 시간이 촉박했던 것이 기술의 발달(혹은 도구의 발달)로 인해 

생산성이 증대되었고, 다른 중요한 부분에도 시간을 할애 할 수 있게 된 것 이다.

이 시대에 업계에서 일을 하고 있었다면, 패러다임의 변화를 목도한 것 이다.

그 시대에 살고 있고, 필드에 일하고 있던 엔지니어라면

당연히 이 것들은 직접 경험한 시니어들은 당연하게도 몸으로 채득한 상황이지만,

과거에는 왜 PHP나 JSP로 개발했고, 

지금에서는 왜 React를 사용해야하고 있는지를, 

더 나아가, React 내부에서도 왜 패러다임이 변화했는지에 대한 이유 또한 이해하고 있다고 보긴 힘들 것 이다.

이는 2010년대의 이야기 일 뿐 일까?

아니다. 

좀 더 나아가서 30~40년 전에는 하드웨어의 제한으로 인해 

컴퓨터가 더 쉽게 이해할 수 있게 프로그래밍 해야 했다.

따라서, 시니어는 아무리 우수한 주니어라고 하더라도

이런 전반적인 이해에 따른 가공된 지식이 있을 것이라 기대해서는 안되고

이를 몇번 가르 쳤다 하더라도 이해를 바라는건 다소 무리가 있다.

이런 시대적인 부분 까지 포함 한다면, 

여기서 이야기한 모든 것들은 사실 

조그만한 조각이라도 머리 속에 자리 잡고 있다면 그것으로 충분할 것 이다.

업무에서 필요에 따라 이 조그만한 이미지를 조금씩 구체화 해도 늦지 않다.

물론 여기서 구체화 했다하더라도 

인간은 망각의 동물이기 때문에, 사용하지 않는다면 서서히 잊혀질 것임에는 틀림 없으나

여기서 이야기하는 탑다운 방식에 잘 맞는 사람이라면, 

구체화 된 것을 다시 살리는데에는 그리 많은 시간이 필요하지 않을 것이기 때문에

크게 문제는 없을 것 이다.

모든 지식을 쌓기에는 그에 비해 우리에게 허용된 유효 시간이 너무 짧으며,

흥미가 없는 부분이라면, 사실상 효율이 저하되어 

너무나도 많은 시간을 할애해야하기 때문에 

학계에서 연구를 하는 연구원이 아니라면, 

대부분의 경우 탑다운 방식이 가장 적절하다고 개인적으로는 생각하고 있다.

또한 모든 사람들이 프로그래머나 넓은 의미에서 엔지니어라는 직업을 

정말 하고 싶어서 하는 사람들은 소수라는 것을 한번 쯤은 생각해볼 법 하다.

정말로 하고 싶어하고, 즐겁게 업무를 할 수 있는 사람들은 

대단히 소수의 사람들이고, 그렇게 할 수 있는 사람들은 정말 운이 좋고 축복 받은 것 이다.

선택한 첫 번째 직업이 적성에 맞는 것은 매우 희귀한 케이스 이다.

이를 이해할 수 있어야만, 시니어를 떠나서 어른일 수 있는 것 이고,

타인의 이해에 영역에 발을 다른 사람들과 옳바른 협력을 할 수 있는 것이라 생각한다.

또한 이미 10년 전 부터, 검색 엔진의 발달로 많은 것 들을 외울 필요가 없어졌으며,

현재 NN기반의 AI 솔루션의 발달로 

이제 많은 기술에 세세한 부분 까지 더더욱 외울 필요가 없어졌다.

이미지만 가지고 있다면 충분하고, 

가지고 있지 않더라도 필요할 때마다 학습 하면 된다.

즉, 문제해결능력만 충분하다면, 혹은 그에 준하는 마인드 셋을 지니고 있다면

기술을 머리속에 넣고 있지 않아도 솔루션 개발에는 차고 넘치기 때문에 

지금 무엇을 할 수 있느냐 보다는 

본인이 그리고 있는 커리어와 업무에서 이를 어떻게 녹여낼 것인지에 포커스를 맞춰야한다.

개발 도구로써 AI 에이전트의 유용성이 증명된 이상, 

과거보다 가용될 수 있는 시간이 늘어났고, 

이 시간을 유용하게 사용하기 위해 새롭게 고민해봐야 하는 시간이 도래했다.

이것이 반영되지 않는 조직은 결국 침체될 수 밖에 없는 것 이다.

유효한 생산력에 직결되는 문제이기 때문이다. 

이 흐름을 타지 못 한다면, 

이러한 흐름을 타고 있는 다른 경쟁자들과의 생산성은 큰 차이로 벌어지고, 

현재 얼마나 훌륭한 솔루션을 가지고 있더라도 

비지니스에서는 높은 평가를 받을 수 없는 것 이다.

지속불가능한 순간, 비지니스는 순식간에 무너진다.

모두가 인식하고 있는 바와 같이 

회사는 대게 직원의 커리어에 관심이 없으며, 그러한 척을 할 뿐, 

사실 매출만 좋으면 그 다지 관심이 없다.

따라서, 스스로의 커리어는 스스로 챙겨야하는 것이며, 

이를 얻어내기 위해, 항상 스스로의 성과를 어필해야만 한다.

물론, AI발달로 현재의 시니어 또한 여기에서 벗어 날 수는 없게 되었지만 말이다.

따라서, 우리는 이 시점에서 우수한 엔지니어(넓은 의미에서)는 누구이고, 

가져야만 하는 마인드 셋에 대해서 다시 한번 생각해볼 시기가 도래했음을 알 수가 있다.

우수한 엔지니어는 누구인가?

여기 까지 해서 꽤나 많은 부분을 할애해서 

먼저 멘터로서의 방향성에 대해 이야기를 나누어봤다.

그렇다면 이제 본론에 들어가보자.

우수한 엔지니어는 누구일까? 

우수한 엔지니어를 정의내릴 수 있다면, 

멘티가 가져가야만 할, 마인드 셋 또한 후속으로 정의내릴 수 있을 것 이다.

이 부분에 대해서는 사람마다 

편차가 있음을 먼저 밝히는 편이 좋을지도 모르겠다.

취향과 선호에 대한 이야기 이기 때문에

중요시하는 부분이 다를 수 있음을 먼저 밝히는 편이 좋을 것 이라 생각 된다.

하지만, 그럼에도 불구하고 감히 

우수한 엔지니어에 대해 이야기 해보려고 한다.

다만, 정말 소수의 연구직(기업)과 일반적인 학계에서의 연구직을 제외한다면, 

우리가 바라봐야만 하는 곳은 사실상 정해져 있다고 볼 수 있다.

바로, 좋은 솔루션을 만드는 엔지니어 이다.

그렇다면, 좋은 솔루션이란 무엇일까?

이는 시대에 따라 다르다고 할 수 있다.

왜냐하면, 솔루션은 그 의미 그대로, '문제해결'에 집중 되어 있기 때문이다.

현실의 문제를 해결해주는 해결사에 가깝다.

조금 과거의 이야기를 해보자.

불과 몇 십년 전만 해도 인류에게는 몇 가지 문제가 있었다.

바로 빠른 인구 수 증가에 따른 여러 가지 문제들인데,

가장 부각되었던 것들은 물을 포함한 기본적인 생존을 위한 음식물들이였고,

그 외의 것들로는 종이가 포함되었다.

왜냐하면, 매년 세계적으로 인구가 증가되는 수를 봤을 떼, 

종이를 만들 때 필요한 나무가 자라나는 시간이 부족하여,

감당할 수 없다고 판단 되었기 때문이다.

하지만, 그러한 예상과는 다르게 이러한 걱정들이 순식간에 사라졌는데 

아이폰(혹은 스마트 폰)이 대중화 되면서 전환이 정말 빠르게 이루어졌기 때문이다.

이제 모든 것이 종이로 이루어졌던 

우편, 서류 등과 같이 종이를 매개체로서 사용되었던 것들이 

디지털 기기를 매개체로서 이용하게 되면서, 

일부분을 제외하고는 이제 대부분 디지털 기기를 통해 업무를 한다.

뿐만 아니라, 이제 일상 생활에서 까지 빠르게 침투하였고,

결과적으로 업계에서 흔히 말하고, 강력하게 어필해왔었지만, 굉장히 느리게 전환되고 있던 

디지털 전환(Digital Transformation, DX)이 정말로 순식간에 이루어진듯 보였다.

이러한 상황이 되자 재미있게도 

이제 그 누구도 종이가 부족할 것이라는 이야기가 순식간에 사라졌다.

마치 그러한 이야기가 언제 있었느냐는 것 처럼 말이다.

물론, 종이는 다양한 곳에서 활용되기 때문에 

완전히 해소되었다고 보기에는 다소 무리가 있으나 

이제 누구도 종이에 대한 걱정을 하지 않는듯 보인다.

눈치가 빠른 사람이라면 벌써 이해하고 있겠지만, 

이러한 것들을 보았을 때, 

멋드러진 최신 기술을 활용해 

정말로 아무리 좋은 솔루션을 내놓았다고 한다하더라도 

사회(또는 유저)에서 원하지 않는다면 

그러니깐, 단순히 말해서 팔리지 않는다면 아무런 의미가 없다는 것 이다.

이를 위해서는 시대적인 어떠한 '트리거'가 필요 하다.

어느 정도 DX에 달성한 현재에는 어떠할까?

조금 과거에는 책이나 회계, 판매 등의 

기존의 아날로그를 디지털로 전환하는 것에 집중 했다면, 

이것이 어느 정도 끝난 현재는 

편의성과 경험하지 못한 새로운 것들을 

제공해주는 것으로 패러다임의 변화가 이루어졌다.

따라서, 현재의 좋은 솔루션은 디지털 전환을 뛰어넘어 

많은 사람들에게 편의성과 새로운 경험(UX)를 제공해주는 것이 

좋은 솔루션이라 볼 수 있을 것 이다.

즉, 넓은 의미에서 서비스에 집중되어 있는 제품이어야만 한다.

물론, 이는 단순히 소프트웨어만 대상되는 것은 아니고,

서비스에 관련된 모든 업종에도 해당되는 이야기 이다.

다만, 문제는 소프트웨어의 경우 실제 세계의 엔지니어링과 

사실상 다른 영역에 존재하고 있다는 점인데,

왜냐하면, 솔루션에 대한 유저의 평가는 새로운 경험이지

최신 기술을 사용했거나, 필요 이상의 좋은 성능은 유저 입장에서는 그리 중요하지 않다.

따라서, 이상적으로는 

우수한 엔지니어란 이 세상에 모든 기술을 알고 이해하고 있어, 

상황에 따른 최적의 기술을 배치 할 수 있는 엔지니어겠지만, 

이는 현실적으로 불가능하기 때문에 

넓게는 문제해결능력이 뛰어난 사람이거나 혹은 그에 준하는 사람이라면 

우리는 그를 우수한 엔지니어라 부를 수 있을 것 이다.

하지만, 이 조차도 사실 현실속에서 찾기가 매우 힘들기 때문에,

이에 준하는 '마인드 셋'을 가지고 업무를 대한다면

나는 좋은 엔지니어라고 평가하고 싶다.

좋은 엔지니어링 이란 무엇인가

이제 좀 더 나아가 엔지니어링에 대한 이야기도 나누어보자.

비지니스는 아무리 좋은 솔루션(입장 차이이 따라 정의는 달라지겠지만) 

고객이 없다면 성립할 수 없기 때문에

위에서 언급한 좋은 엔지니어에 대한 정의도 여기에 강력하게 영향을 받을 수 밖에 없다.

같은 이유에서 좋은 엔지니어링도 비지니스와 그에 따른 솔루션에 강력한 영향을 받게 된다.

그렇기 때문에 좋은 엔지니어는 

반드시 절반 이상은 코드의 세계에서 벗어나 있어야 하며,

알고리즘이나 프로그래밍과 같은 부분 보다는 아키텍처 관점에서 머물러야 한다.

알고리즘과 프로그래밍은 결국, 

인풋과 아웃풋이 결정되어 있는 상태에서 최악의 경우 성능상 문제가 없다면 

어떤 방식으로 프로그래밍 하던 상관 없기 때문이다.

어떻게 보면 이는 하나의 전문가로서 매우 질이 떨어지는 언행일 수도 있는데

이러한 마인드가 다소 허용될 수 있는 이유는

시장에서의 영향력이 없을 때는, 견고한 엔지니어링 보다 제품의 릴리스가 우선시 되기 때문이며

더나아간다면 본질적으로 소프트웨어는 

처음 부터 완벽한 설계는 존재할 수 없기 때문이다.

소프트웨어 엔지니어링은 

느낌상 건축의 엔지니어링에서 많이 차용한 것으로 보이지만, 

사실 그대로 가져와서 사용하기에는 다소 무리가 있다.

건축은 허용된 공간이 불변하지 않는다는 명확한 한계속에서 

엔지니어링을 하기 때문에 설계 대로 건축이 가능하다.

즉, 사실상 완벽히 불변하지 않는 정해진 물리적인 공간 안에 엔지니어링을 하기 때문이다.

또한, 건축이 완료된 상태에서 조금이라도 수정하려면 비용도 많이 들기 때문에 

방금 만든 건물을 부수고 다시 짓는 것은 일반적으로는 사용자에게 고려대상이 되지 않는다.

하지만, 소프트웨어는 그렇지 않다.

물리적인 공간이 존재하지만, 얼마든지 늘릴 수 있기 때문에, 

즉, 불변하는 물리적 공간이 아니기 때문에, 얼마든지 수정이나 추가 할 수 있다.

한계는 분명히 존재하지만, 공간이 부족하면, 추가하면 되기 때문이다.

여기서 건축의 엔지니어링과 많은 괴리가 발생하게 된다.

소프트웨어에서는 처음에는 불변하지 않는 공간을 예상해서 설계 했지만,

건축을 예로 들자면, 필요에 의해 예상도 못했던 방이나, 

발코니를 추가해달라는 요구나, 설치해야만 하는 그러한 상황이 발생한다는 점이다.

이러한 이유에서 솔루션 레벨에서는 완벽한 설계가 불가능하다.

이것이 가능한 사람이 있다면, 매우 운이 좋은 사람이거나, 

혹은 천리안을 가지고 있는 사람이 아니고서는 불가능에 가깝다.

이러한 한계에 의해, 

명확하게 예측 가능한 솔루션(패키지 게임과 같은)이 아니라면,

결국 솔루션 레벨(혹은 엔터프라이즈 레벨)로 오게 된다면, 

내부의 프로그래밍 방식과 알고리즘 보다는 

어떻게 아키텍처를 가져가는 것이 가장 좋은지가 중요하게 되고, 

어떻게 프로그래밍을 할지, 알고리즘을 가져갈지 보다는 

이키텍처가 더더욱 중요해 진다는 것 이다.

완벽한 설계를 할 수 없는 시점에서 결국 언젠가는 리펙토링 해야하기 때문이다.

따라서, 미래에 많은 수정 사항이 불가피하게 발생하는 시스템이라면,

즉, 대부분의 시스템(솔루션)에서 가장 중요한 것은 

시스템과 프로그래밍(프레젠테이션/비지니스 로직) 레벨에서 확장성 있는 아키텍처를 설계하는 것 이다.

이는 당연하게도 성능 보다 우선시 된다.

따라서 좋은 엔지니어링이란 엔터프라이즈 혹은 솔루션 레벨에서는 

적은 유지/운용 비용과 확장성 그리고 적당한 성능을 가지고 있는 엔지니어링 이며,

프레젠테이션/비지니스 로직 레벨에서는 

확장성이 있으며, 적당한 성능을 가지고 있는 엔지니어링 일 것 이다.

확장성 있는 아키텍처를 설계하는데에 많은 시간을 투자하고,

매우 애석하게도 주어진 시간 내에 남는 시간은 알고리즘과 프로그래밍에 활용해야 한다.

만약 반대가 되어버린다면, 

몇 년 후가 되면 점점 보이지 않는 부채가 쌓여 

손도 댈 수 없는 순간이 되어

사실상 다시 개발하는게 더 나은 수준이 되어버린다면,

솔루션에 폭탄을 하나 달고 운용하는 셈이 된다.

하지만, 냉혹한 비지니스의 세계에서는 매출이 없다면, 

솔루션도 존재할 수 없기 때문에 

이 비용을 감당할 수 있는 회사가 아니고서는 

충분한 엔지니어링과 프로그래밍에 투자할 여유가 없는 경우가 대부분이기 때문에 

이 조차도 힘든 경우를 심심치 않게 찾아볼 수 있을 것 이다.

그렇기 때문에 이 경우는 대게

회사 내부에 질이 떨어지는 엔지니어 밖에 없기 때문이 아니라

이러한 소프트웨어 엔지니어링/아키텍처를 구성하는대에 있어서 

명확한 한계가 존재하기 때문임을 먼저 인식할 필요가 있을 것 이다.

결론적으로, 사실상 가변적인 공간에서 설계할 수 밖에 없는 

소프트웨어의 특성상, 그 무엇보다 확장성 있게 아키텍처를 구성하고 

그 밑으로 엔지니어링 하는 것이 가장 중요하다고 할 수 있으며,

이를 좋은 엔지니어링이라고 부를 수 있을 것 이다.

협업과 커뮤니케이션 능력에 대해

사실 이러한 엔지니어링 보다 더더욱 중요한게 있는데,

바로 협업 할 수 있는 커뮤니케이션 능력이다.

현재 우리가 살고 있는 시대는 이미 고도로 분업화 되어 있기 때문에

모든 것을 잘하기란 사실 상 불가능 하고,업무의 양도 많기 때문에 

일을 나누거나, 혹은 내가 못하는 부분을 커버 해줄 사람들이 필요 하다.

따라서, 위의 능력이 다소 부족하더라도, 분담할 수 있는 사람이나

혹은 능숙히 할 수 있는 사람과 협업을 해야만 한다.

상성이 잘 맞는 사람들과는 생산성이 배로 상승하는 효과도 있기 때문에 

엔지니어 또한 협업은 필수불가결한 상황이 되어 버렸다.

하지만, 컴퓨터 세계에 같혀, 모니터와 타자기를 통해 소통하여

여기에 너무나도 익숙한 엔지니어의 특성상

다른 직업들과 비교해서 비교적 커뮤니케이션 능력이 떨어지는 것은 어쩔 수 없는듯 하다.

디자인 업무나 실제 고객의 이야기를 들어주는 업무를 하는 사람들과의 커뮤니케이션 인데,

그들은 엔지니어링에 대한 지식이 없기 때문에, 

확실히 되는 것과 안되는 것과 예측 불가능함에 따른 리스크를 이야기 하고

예측 가능하게끔 협상을 해야 한다. 

이는 시간이라는 물리적인 한계이기 때문에 

흔히 좋은 엔지니어도 할 수 없는 영역이다.

시간을 필요에 따라 조절할 수 있는 마법사가 아니라면 말이다.

위에서 좋은 엔지니어와 좋은 엔지니어링에 대한 이야기를 했는데,

나는 이 두가지 보다 '협업'과 '커뮤니케이션 능력'이 더 중요하다고 보고 있다.

도입 부분에서 살짝 이야기 했듯이 

엔터프라이즈급 애플리케이션은 매우 복잡하여, 

시간 내에 개발 할 수 없기 때문에 같은 엔지니어건 그렇지 않더라도 결국 협업을 해야만 한다.

나는 커뮤니케이션이 무엇인지에 대한 정의 보다

이 커뮤니케이션에 대해 많은 오해가 있는 것으로 생각되기 때문에 

이 오해를 푸는 것에 많은 부분을 할애하고 싶다.

왜냐하면, 대화나 회의를 했다는 그 자체가 커뮤니케이션이 될 수 없기 때문이다.

이러한 오해와 착각으로 인해, 커뮤니케이션이 부족하다고 느끼면, 

회의량을 늘려 단순히 대화를 하려고 시도하게 되어, 생산량을 매우 하락시키게 된다.

그러니깐, 내가 상대방의 이야기를 들어주고 대화를 나누었다는 것이 커뮤니케이션이 아니라는 점이다.

왜나하면, 어떤 문제에 대한 다른 시각과 그에 따른 관점을 가지고 있는 것은 당연한 것 이고, 

이 관점의 차이에 의해 인식의 갭이 생겨, 결국 나중에는 서로 다른 이야기를 하게 되기 때문이다.

최악의 경우, 시간을 들여 제작했던 작업물들이 의미가 없게 되어 

다시 작업해야하는 경우가 발생 하게 된다.

따라서, 문제에 대한 상호 인식과 관점을 맞추고, 

행동 방식에 대한 '조율'이 빠져 있는 커뮤니케이션은 

자주 언급되어지는 '커뮤니케이션'이라고 부르기에는 매우 민망한 것이다.

이렇게 되어버리면, 차라리 안하느니만 못하는 상황이 되는 것 이다.

그래서 여기서 이야기하는 좋은 커뮤니케이션 이란, '양방향'이 전제 되어야만 한다. 

때로는, (한국에서는 눈치와 같은)'일방향' 커뮤니케이션을 매우 중시하는 사람들이 있는데,

의미있고 손실 없는 커뮤니케이션으로서 일방향이 유효하려면,

서로 상호간의 깊은 이해와 강한 신뢰가 있을 때 뿐이다.

하지만, 현실에서는 대게 초면의 사람들과 협업을 진행하기 때문에 

신뢰 구축되기 전에 업무를 해야 하는 경우가 대부분이며,

최악의 경우 상성이 맞지 않은 사람들과도 협업을 해야할 때가 존재하기 때문에

업무에 있어서 좋은 커뮤니케이션을 하고 싶다면, 

'양방향' 커뮤니케이션을 지향하는 것이 생산성 향상에 매우 도움이 될 것 이다.

그러니깐, 한국 사회에서 일반적으로 눈치라고 불리우는 

일방향 커뮤니케이션 방식은 협업이 필수 불가결한 곳에서는 매우 최악의 방법이고, 

나는 좀 더 엄격하게 해서 협업이 필수불가결한 업무에 있어서는 

일방향 커뮤니케이션을 커뮤니케이션이라는 카테고리에 넣어서는 사실 안된다고 생각 한다.

올바른 양방향성 커뮤니케이션과 혼동을 주고, 

이에 커뮤니케이션에 가치가 매우 떨어져, 마지막에는 단절이 이루어지기 때문이다. 

물론 이에 대해서는 앞서 이야기 했듯이 답이 존재하는 것은 아니며,

어디 까지나 개인에 의견이고, 다소 기준이 다르다 하더라도 크게 문제는 없을 것 이다.

같은 곳을 바라보고 있다면, 어느 교차점에서 만나게 될 테니 말이다.

그 시점에 우리는 다시 한번 이 문제에 대해 의미있는 논의를 해볼 수 있을 것 이다.

마인드 셋은 왜 중요한가

이로서 우수한 엔지니어가 가져야만 하는 것에 대해 

꽤나 길게 이야기를 나누어보았다.

그렇다면, 마지막으로 왜 이런 것들이 중요한지에 대해 다시 한번 정리하면서 이야기 해보자.

마인드 셋은 일종의 앵커와도 같다.

이번에는 엔지니어라는 직종에 대한 앵커로서 마인드 셋을 이야기 했지만,

사실 인생에서의 마인드 셋도 이와 크게 다르지 않다.

왜냐하면, 우리 구 인류는 사회적인 동물이고, 

타인의 마음을 읽어낼 수 없기 때문에, 

좋은 마인드 셋을 가질 수 있다면, 혹은 그에 준하는 마인드를 가질 수 만 있다면

그것이 좋은 엔지니어로 갈 수 있게 유도하기 때문이다.

비지니스의 세계에선 더더욱 그럴 것 이다.

자본주의 시장이 이 신뢰로 움직이기도 하니 

패러다임 측면에서도 이러한 마인드셋을 가져가는게 옳을 것 이다.

AI 에이전트의 유용성이 증명된 이 시점에서 

이러한 이야기는 꽤나 고리타분한 이야기로서 들릴 수는 있겠으나,

엔지니어에게 요구되는 능력은 '문제해결능력'임은 변하지 않을 것 이다.

또한 단순한 생산성 향상은 직업이 사라지는 것이 아닌, 

시간상 할 수 없었던 다른 중요한 업무를 할 수 있게 됨으로써 

역할과 임무가 달라져 사라지는 것 처럼 보이지만, 새로운 직업이 탄생할 뿐이다.

기존으로 유지 된다면, 

아마 생산성이 낮아지지 않는 현재보다 더 작은 최적의 인원으로 

지금 보다 더 좋은 솔루션들을 사회에 내놓을 수 있을 것 이다.

이는 10년전에 아이폰이 등장했을 때와 사실 크게 변하지는 않는다.

수요에 따른 기술의 확장과 시프트로 인해, 

업무가 분할되어 그 수 만큼 직업이 나타날 것 이다. 

물론, 완벽한 AGI가 나타난다면, 다소 이야기가 달라질 수는 있겠지만 말이다.

도달 했을 시점에 다시 한번 이 이야기를 나누어 재정의를 해보는 것도 좋을 것 이다.

따라서, 크게 보자면, 

좋은 엔지니어는 문제해결능력이 우수한 엔지니어라고 볼 수 있고,

여기서 이야기하는 문제해결능력은, 좋은 엔지니어링(아키텍처를 설계)할 수 있는 엔지니어라 할 수 있으며,

양방향 커뮤니케이션을 할 수 있는 마인드 셋을 가지고 있어야만 한다. 

마인드 셋은 어디까지나 방향성에 가깝기 때문에 

가지지 못한다 하더라도 수치적으로 산출할 수는 없지만, 

평균 그 근처에만 도달하기만 해도 문제는 없을 것이라 생각 된다.

왜냐하면, 단순히 마인드셋 가지고는 비지니스가 가능한 

지속 가능한 애플리케이션을 만들어 낼 수 없기 때문이다.

따라서 좋은 마인드셋 위에 엔지니어링 능력을 올릴 필요가 있고,

이 밸런스를 좋게 가져가는 것이 다소 현실적일 수 있다.

마치며

블로그를 작성하다보니 새해를 넘기고 말았다.

아마 우수하고 좋은 엔지니어가 되고 싶은 이유에서는 

어떠한 야망이 있거나, 아니면 단순히 높은 급료를 받고 싶다는 등의 

여러 이유가 있을 수 있을 수 있을 것 이다.

스스로의 자아 실현이던, 어떠한 야망이던, 높은 급료를 받고 싶던간에 

이를 목표로 한다면, 좋은 엔지니어가 되기 위한 

좋은 마인드 셋을 가지고 있어야만 할 것 이다.

이러한 좋은 마인드 셋에는 여러가지 언급 될 수 있으나,

주니어에게 가장 필요한 것은 지금 내가 무엇을 알고 있는냐 보다는 

학습 방식과 커뮤니케이션에 대한 태도가 가장 중요하다고 생각하고 있다.

물론, 급격하게 변하는 IT 업계에서는 시니어에게도 요구되는 능력이기도 하며,

지금과 같은 패러다임의 변화가 이루어지는 시대에는 더더욱 필요한 능력이기도 하다.

이에 따라갈 수 없다면 스스로의 가치가 상대적으로 낮아지게 될 테니 

이를 받아들일 마음의 준비가 필요할 것 이다.

어쨋든, 기본적으로 학습에 관련해서는

업무에 필요한 기술들을 필요에 따라 취사선택할 수 있는 탑 다운 방식

커뮤니케이션에 대한 태도는 양방향 커뮤니케이션을 지향할 수 있도록 해야만 한다.

특히, 커뮤니케이션 방식 중 가장 최악의 방식인 

일방향 커뮤니케이션(한국에서는 눈치나 센스라 불리우는 것)은 가장 피해야만 한다.

왜냐하면, 이 방식은 명령 하달 방식으로 일방향 커뮤니케이션을 하는 당사자가 

모든 면에서 우월해야만 효과가 있으며,

고도로 분업화된 시대에는 알맞은 커뮤니케이션 방식이 아니기 때문이다.

대화를 통해 서로의 인식, 그러니깐 정의와 목표, 우선순위, 리스크를 조율할 수 있는 

양방향 커뮤니케이션이 아니고서는 지속가능한 복잡한 애플리케이션을 만들 수가 없다.

따라서, 현 시점에서 우수하다고 볼 수 있는 엔지니어는 

최소한 이 두 가지 마인드셋을 가질 수 있어야 한다고 볼 수 있다.

이는 주니어 뿐만 아니라 시니어에게도 중요한 것임에는 틀림 없으나,

시니어는 당연하게도 경력을 쌓으면서 어느 정도 가지고 있는 경우가 많기 때문에

주니어에게는 그 무엇 보다 좋은 마인드 셋을 가질 수 있게 유도해야만 한다.

이는 전반적인 커리어에 강력한 영향을 줄 뿐더러, 

인생의 많은 시간을 일에 투자해야하기 때문에 

인생 전체에도 강력한 영향을 주기 때문이다.

이는 커리어에 대한 한정한 이야기는 아니며,

인생 전반적인 것에도 관통하는 이야기이기도 하다.

그래서, 이상적이라고 할 수는 있겠지만,

가능하다면 우리는 이러한 사람들에게 높은 베네핏을 주고,

이쪽으로 나아갈 수 있게 유도할 필요가 있다.

당연하게도 이는 당장 외적으로 드러나지는 않겠지만, 

조직에게는 매우 좋은 영향을 가져다 주기 때문에

시니어 본인에게도 시간을 투자한다고 해도 전혀 손해는 아닐 것 이다.

회사에 어필 할 수 있는 좋은 기회가 되니깐 말이다.

그리고 이러한 마인드 셋을 가지게 할 수 있는 것이 

시니어로서의 역할이고 

더 나아가 사회의 어른으로서의 역할이기도 할 것 이다.