무엇이 강한 엔지니어를 강하게 만드는가? 를 보고

시간이 나면 GeekNews를 보는 버릇이 있다.

 

오늘도 잠깐 시간이 나서 글들을 보는데 "무엇이 강한 엔지니어를 강하게 만드는가?" 이것을 보고 흥미가 생겨서 클릭해서 보게되었다.

https://www.seangoedecke.com/what-makes-strong-engineers-strong/

What makes strong engineers strong?

관심이 있으신 분들은 한번 들어가서 봐보시기를 만약에 영어가 아닌 한글로 번역 및 요약이 되어진 것이 필요하면 아래링크로 들어가시면 됩니다.

https://news.hada.io/topic?id=21480

무엇이 강한 엔지니어를 강하게 만드는가 | GeekNews

 

일단 보고나서 느꼈던 것은 나랑 사고관이 비슷한 부분이 많다는 것이었다.

 

가장 크게 와닿았던 것은 "강한 엔지니어는 실제로 동작하는 결과물을 내는데 집중함" 이었다.

 

보통 새로운 프로젝트 혹은 아예 새로운 도메인, 기술 등을 시도를 할 때 완벽하게 모든 것을 학습하거나 혹은 어느정도 기준치가 되어야지만 시작하는 사람들이 있다.

하지만 나는 예전부터 그러한 형태로 개발을 많이 하지는 않았다.

 

중간중간 시간이 날 때면 따로 책을 읽거나 혹은 글을 통해서 공부를 하면서 지식을 틈틈히 쌓기는 했지만 무엇인가를 시도할 때에는 그렇게 많은 시간을 필요로 하지는 않았다.

오히려 시도를 통해서 헤딩하면서 문제를 해결하고 결과물을 만드는데에 초점을 맞추었다.

그러면서 어느정도의 퀄리티는 준수하려고 했지만 엄청나게 잘 짜여진 설계 혹은 코드 품질에 대한 초점을 맞추지는 않았다.

 

언제나 1순위는 돌아가냐였고 그 다음 순위들이 설계 혹은 코드 퀄리티였다.

 

그래서 보통 나의 목표가 돌아가는 것이 우선이다보니 일단 만들고 나중에 리팩토링하는 형태의 일을 주로 진행을 해왔다.

그러다보니 장점아닌 장점이 레거시 코드를 개선할 때 도움이 되었던 부분이 있었고

또 빠르게 결과물이 나오다보니 태핑을 시도하거나 결과물을 기준으로 피드백을 통하여 어떻게 나아가야 하는지에 대한 지표로 삼을 수 있었다.

 

최근 AI 관련 프로젝트를 할 때도 그랬다.

반려동물의 얼굴, 눈, 코 를 검출해야 하고 또 특징을 뽑아내 추후 다시 한번 들어올 때 유사도를 비교해야하는 부분이 있었다.

그때 얼굴은 어떻게 검출할 지에 대해서 확인해보니 YOLO 라는 부분이 있었고 그것을 학습하고 어떻게 실사용이 가능한지에 대해서 학습을 통해서 바로 실무에 적용을 하고 검출이 되어지는 것을 확인했다.

그리고 또, Embedding Model 흔히 특징을 검출해내는 모델에 대해서도 학습이 일단은 많이 되어진 것과 ViT 기반이 대세라는 것을 그냥 들었기에 괜찮겠지? 라는 생각으로 일단 시도를 했다. 그렇게 Embedding Model 을 통해서 특징을 뽑아내 유사도 체크를 했을 때 그래도 같은 개체에 대해서는 약 85% 에 대한 결과를 가져왔고 다른 개체인 경우에는 더 낮은 유사도인 0.5 정도의 유사도를 보여줬다.

물론 아주 유사하게 생긴 경우에는 그보다는 높은 유사도를 가져왔지만 일단 전이학습이 이뤄지지않은 상태에서는 나름 괜찮은 결과였다.

 

이렇게 무엇인가를 동작한다는 것에 초점을 맞추고 시작해 결과를 내었을 때, 무엇인가를 추가하거나 서비스적으로 이게 되어졌으면 하는 의견이 나왔기에 좋았던 결과였고 또 저 부분의 경우 모델의 성능이 좋아지면 결국에 프로그램의 퀄리티가 높아지는 것이기에 오히려 시도하는 것이 더욱 더 옳은 선택이었던 것 같다.

 

다시 글로 돌아와 무엇이 강한 엔지니어를 강하게 만드는가? 에 대해서 생각해보면

글에서는 자기 신뢰, 실행, 실용주의 적인 생각이 주를 이루었는데 나도 이 부분에 동의하고 있다.

그리고 스마트하지만 약한 엔지니어와의 갈등이 있을 수도 있다고 하는데 이부분도 어느정도 동의는 한다.

 

여기에서 약한 엔지니어라고 말하는 사람은 일단 내생각으로는 실행을 잘 안하는 사람이 될 것이다.

그러다보니 이론으로만 가지고 있어서 실제로 경험하는 부분이 매우 적어 업무에서 이렇게 이렇게 하면 되는거 아니야라고 하는 사람일 것 이다.

 

그런데 실제로 업무를 해보면 그게 아님을 안다.

인력, 시간, 자원 이러한 부분들이 이론과는 매우 차이가 나고 결국에는 시간내에 돌아가는 결과물이 나와야하는 것이 가장 큰 목표인데 스마트하고 약한 엔지니어는 그러지 않을 것이기 때문이다.

 

그래서 오히려 업무를 시작하기전에 혹은 업무를 하는 중에 태클을 주로 걸지않나 생각한다.