20년 소프트웨어 엔지니어를 하면서 배운 것들

Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>

yundream
2023-05-24
2023-05-24
5730

![idea](https://docs.google.com/drawings/d/e/2PACX-1vRPLu2DDhqLvTuVi1WUCHqcakCDabJxdFAq2wdOLcxgMTW3TD0p3eptUvfmVPpD8qdFzR2ShiD_qrfk/pub?w=732&h=390)
## 들어가기 전에
사람들은 많은 경험, 경력을 가진 업계 전문가의 게시물을 읽으려고 한다. 그 이유는 우리보다 앞선 사람의 경험으로부터 배우고자 함이다. 하지만 모든 사람은 세부적인 인생경로가 다르기 때문에 조언은 그 사람이 처한 상황에 따라서 달라질 수 있다는 것을 염두에 두고 읽어야 한다.

맥락을 이해하지 못한 조언은 무의미하거나 오히려 나쁠 수 있다. 수만명의 고객을 확보한 인터넷 서비스 회사가 있다고 가정해보자. 이 회사는 기존의 모놀리스를 마이크로서비스로 전환하는 작업을 성공적으로 수행했다. 이 회사의 개발자는 "모든 것을 마이크로 서비스로 구축해야 합니다. 마이크로 서비스를 구축하면 각 팀이 독립적으로 기능을 추가할 수 있고 블라블라... 그래서 우리는 더 크게 성공할 수 있었습니다."라고 말할 것이다.

하지만 인터넷 상에서는 마이크로서비스로 바꾸는 바람에 시간과 사람을 낭비하고 고통을 겪었다는 글들도 쉽게 찾아볼 수 있다. 농경시대에는 옆 동네 사는 노인의 조언을 그대로 받아들여도 문제가 없을 것이다. 하지만 지금 시대에는 그걸 바랄 수 없다. 각 개인이 "그 사람의 경험과 조언을 받아들였을 때 어떤 결과가 나올를 상상력을 발휘해서 시뮬레이션 해야 한다."

따라서 내 경험을 이야기 하기전에 내가 어떤 일을 해왔는지 맥락을 설명해야 할 것 같다. 나는 독학으로 시작하여 1999년 부터 소프트웨어 엔지니어로 일을 했다. 웹 애플리케이션 개발, 검색엔진, 보안솔류션, 가상화 솔류션, 클라우드 소프트웨어 개발자, 백앤드 애플리케이션 개발, 클라우드 엔지니어, DevOps 엔지니어 등 다양한 업무를 수행했다. 기업규모로는 벤처와 중소/중견기업, 대기업을 경험했다. 대기업의 경우에도 제조업, IT, 금융등 다양한 산업을 경험했다. 대기업이라고 하지만 디지털전환기에 업무를 수행했기 때문에 25명 정도의 팀에서 일을 했다. 몇 개의 성공 그리고 많은 실패를 경험했다.

내 경험을 형성하는 주요한 특징은 아래와 같다.
1. 작은 규모로 새롭고 도전적인 일을 수행한다.
2. 새로운 팀에서 시작하거나 팀을 만드는 경우가 많았기 때문에 커뮤니케이션 구조, 업무 프레임워크를 설정하는 것을 중요하게 생각한다.
3. 소프트웨어는 일단 작동해야 하며, 시간/비용/기능간의 트레이드오프를 중요하게 생각한다. 즉 기술부채는 제거해야하는 것이 아닌 관리해야 하는 것으로 생각한다. 
4. 벤처/스타트업과 대기업 양쪽 환경에서 함께 일을 했다. 일단 작동하는 소프트웨어를 만드는 것을 중요하게 생각하지만 조직 구성을 만들고 역할/책임(R&R), 업무 프레임워크 개발, 아키텍처링하는 과정도 중요하게 생각한다.

### 디자이너 처럼 생각하기 
기업은 고객에게 어떤 가치를 제공하기 위한 서비스를 제공하는게 목적이다. 고객에게 전달하는 가치를 이해하지 못하는 상황에서 좋은 소프트웨어를 만들 수 없다. 훌륭한 엔지니어는 코드의 사용자 경험을 중요하게 생각한다. 고객이 원하는 가치를 원하는 방식으로 API, 프로토콜, 인터페이스를 개발하기 위해서 노력한다. 고객이 누구인지, 그 기능을 왜 어떻게 사용할것인지 중요기능이 무엇인지, 중요 비기능이 무엇인지를 고려한다.

### 평범한 팀에서 훌륭한 소프트웨어를 만든다.
많은 조직들이 최고로 잘하는 동료를 모아서 최고의 소프트웨어를 만들고 싶어한다. 모든 조직이라고 하지 않은 이유는 많은 회사들이 "**최고의 팀원을 모아서 최고의 소프트웨어를 만든다**"는 좋은 아이디어가 아니라는 걸 어느정도 경험해서 생각이 바뀌고 있기 때문이다.

10배 잘하는 프로그래머라는 신화가 생긴데에는 나름대로의 역사가 있다. 존 카멕(John Carmack), Linus Torvalds, 국내에도 주로 게임쪽에서 전설적으로 회자되는 프로그래머들이 있다. 일단 우리 대부분은 일생동안 노력해도 존 카멕이 했던 일을 해낼 수 없을 것이다.  이들은 어릴때 부터 믿을 수 없을 정도로 똑똑했으며, 믿을 수 없을 정도로 많은 시간을 노력했고, 주제에 대한 전문의식을 가지고 있었으며 다른 사람이 생각하지 못하는 방식으로 세상을 볼 수 있는 사람들이다.  그리고 그들 대부분은 그들만의 독특한 업무 방식을 가지고 있으며, 조화를 이루기가 쉽지 않을 것이다.

또한 최근에는 예전보다는 이런 신화적인 인물들의 이름을 듣기가 쉽지 않다. 산업이 복잡해지고 고도화 되었기 때문에 혼자서 할 수 있는 일이 거의 없어졌기 때문이다.

최근의 애자일 관행을 보자. 애자일 관행은 평범한 사람들이 모여서 일해도 최적의 결과를 만들기 위한 프레임워크이지, 최고의 팀원이 모인 조직을 만드는게 목표가 아니다.

### 기술보다 태도
20년이 넘는 시간 IT에 종사하다보면 생각이 바뀌는 부분이 있기 마련이다. 요즘에는 기술보다는 태도를 더 중요하게 생각하고 있다. 혼자서 할 수 있는 일이 줄어들면서 다른 사람들과의 소통, 설득, 협력, 업무 프로세스에 대한 긍정적 적응이 중요해지고 있기 때문이다. 기술이 중요하지 않다는게 아니다. 기술은 그냥 기본이다.

### 면접으로 알 수 있는 것들은 제한적이다.
요즘에는 기술 뿐만 아니라 인성(문화면접이라는 이름으로 이루어지는)도 중요하게 보는데, 2-3번의 면접으로 이것을 알아내는 것은 너무 힘들다. 대화를 통해서 그들이 훌륭한 팀원인지 추측하는 것은 무익한 노력이다. 그 누구도 인터뷰에서 "자신을 믿을 수 없거나 거만하거나 회의 시간에 나타나지 않는다"고 말하지 않기 때문이다. 사람은 가면을 쓰기 마련인데, 이런 면접자리에서는 **그 가면조차 만드는 걸 귀찮아 하는 사람** 정도를 걸러낼 수 있을 뿐이다.

앞서 **기술보다 태도**가 더 중요하다고 했는데, 태도는 일하면서 알아내는 수 밖에 없다.

그래도 좋은 사람을 뽑을 확률을 더 높이고 싶다면 과제 중심 인터뷰를 해보자.

기술 인터뷰에서 중요한 것은 주어진 전문 분야에 얼마나 관심이 있고 이해하려고 노력하고 있는지를 검토하는게 좋다. 그 사람의 가면을 벗길려면 다면적으로 접근 할 수 있는 장치가 필요하다. 알고리즘 코딩 테스트는 스크리닝 용도로 시간을 아끼기 위한 목적정도로 사용할 수는 있겠지만 그 이상은 어렵다. 다양한 상황에 노출할 수 있는 과제 중심으로 인터뷰를 하는 걸 권장한다. 그 사람의 태도에 대해서 더 많은 것들을 알 수 있다.

### 데이터는 코드보다 오래지속된다.
로그, 사용자 데이터, 사용자 활동 데이터, API 호출 데이터, 모든 거래 데이터들은 코드보다 오래 지속된다. 코드에 대한 기술부채는 중요하게 생각하지만 데이터에 대한 부채를 생각하지 않는 많은 프로젝트들을 봤다. 이들 프로젝트들은 얼마안가서 혼란속에 파묻히게 될 것이다. 코드를 질서 정연하고 깨끗하게 유지하는 그 이상으로 데이터에 에너지를 쏟아서 복잡도를 낮춰야 한다. 그러면 중/장기적으로 좋은 결과를 얻을 것이다.

### 프로세스는 간결하게 유지해야 한다. 그렇다고 프로세스가 필요없다는 말이 아니다.
프로세스는 필요 없다는 팀에서도 일을했으며, 프로세스가 지나치게 복잡한 팀에서도 일을 해봤다. 소프트웨어 산업에 애자일이 도입된지 20년이 지난 지금까지도 프로세스에 대한 이해가 서로 다르다는 것이 놀랍다.

애자일은 작은단위로 무언가를 만들고 그 가운데 학습을 한다음 다음 주기를 반복하는 것이다. 매 짧은 주기에 걸쳐서 가치를 추가하여서 제품을 만드는건데, 그렇게 하는 이유는 시장의 변화에 민첩하게 대응하기 위해서다.

여기에서 오해가 발생한다. 짧은 기간(보통 2주 정도)에 완결된 기능을 제공하면 되니 계획도 문서도 필요 없다는 팀 심지어는 그것들이 프로젝트의 발목을 붙잡는다는 팀도 만나봤다. 코드 알고리즘 하나 만드는데도 계획을 짜고 시뮬레이션을 하는데, 프로젝트 진행에 문서와 설계, 역할과 책임 필요 없다는 아이디어는 나온 이유를 모르겠다.

> 측정할 수 없으면 관리할 수 없고, 관리할 수 없으면 개선할 수 없다.

프로세스의 핵심은 문서를 통한 기록이다.

### 나는 사람을 관리하는데 관심이 없다 ?
대부분의 개발자는 **사람을 관리하는데 관심이 없다**(프로젝트 관리도 결국 사람을 관리하는 것) 라고 말한다.

대부분의 경우 이것은 사실이 아니다. 이러한 생각은 개발자에서 관리자로 전환하는데에는 가파른 학습곡선이 필요하다는 믿음에 뿌리를 두고 있다. 그리고 이 학습의 영역이 "심리적"이라는 익숙하지 않은 영역이라는 것에 대한 두려움도 가지고 있다. 개발자라는 익숙하고 안락한 영역이 있는데, 왜 모험을 하는 리스크를 감수해야 하는가 ?

하지만 리스크를 감수하는 만큼 얻는 것이 있을 것이며, 예상외로 잘 할 수 있는 영역일 수 있다.

### 컴포넌트를 최적화하기 전에 시스템을 최적화하자.
소프트웨어 공학에서는 구성요소 최적화보다 시스템 최적화가 더 중요하다. 시스템 최적화는 소프트웨어 성능에 대한 솔류션 차원에서의 접근 방식을 취하고 구성 요소 간의 상호 종속성을 고려하여 확장성과 효율성을 개선하고 시간이 지남에 따라 유지 관리성과 안정성을 향상시킨다.

당연히 이래야 하는 것 아닌가 ? 라고 생각 할 수 있지만 현실에서는 컴포넌트 최적화에 목메는 경우를 종종 볼 수 있다. 특히 이기적인 조직이 더욱 그러하다. "저 팀은 자기들 실적만을 생각해, 시야가 너무 좁아서 얘기하기 힘들어"와 같은 평가가 나온다면 조직이 이기적으로 변하고 있는지 혹은 회사 문화가 그것을 조장하고 있는지 검토해 보자.

### 풀 스택 엔지니어 되기.
**풀 스택**이 주는 멋진 느낌과는 달리 풀 스택 엔지니어가 되어야 한다는 것은 도발적인 주장이 될 수 있다. 풀 스택 엔지니어에 대한 정의가 서로 다르때문인데, 어떤 사람들은 모든 걸 조금씩 해내야 하는 잡부로 정의하기 때문이다.

아래 이미지는 [Stack Overflow 2022 Developer Survery](https://survey.stackoverflow.co/2022/#overview) 결과다.
![full stack](https://docs.google.com/drawings/d/e/2PACX-1vRDNTZQoLptZU4LrZ_FoTKT6hjIDCNwGjMpGeEede1r75kro0bqlcLblFSnPmXUxaDaNG8ft6tHKVq7/pub?w=788&h=864)
절반 이상의 개발자들이 자신이 풀-스택 즉 서로 다른 두 가지 이상의 업무를 수행하고 있다고 응답했다. 그 이유는 아래와 같이 생각해 볼 수 있을 것이다.

프론트 앤드 개발자라고 하더라도 백앤드 개발자, 클라우드 엔지니어, DevOps 팀과 논의를 한다. 자연스럽게 이들과 커뮤니케이션 할 수 있는 수준의 지식을 획득하며, 조직 또한 이것을 원한다.

백앤드, 프론트 앤드 상관 없이 클라우드가 도입되면서, 예전과 달리 인프라와 배포와 모니터링, 운영환경을 쉽게 경험할 수 있게 됐다.

프론트 앤드, 백 앤드, 인프라, 운영이 충분히 성숙하고 전문화되면서 이들을 효과적으로 통합하는게 지금의 추세다. 전문분야외의 분야들에 대해서도 일정 수준이상의 지식이 있으면 한층 효과적으로 업무를 수행할 수 있으며, 자신을 어필할 수 있다.

### 최고의 코드는 코드가 없거나 혹은 유지할 필요가 없는 코드다.
> 망치를 든 사람에겐 모든 것이 못으로 보인다.

특정 직업에 종사하는 사람은 자신이 잘하는 방법을 이용해서 문제를 해결하려고 한다. 대부분의 소프트웨어 엔지니어는 특히 비기술적인 사양이 명확하지 않을 때, 코드 개발 측면에서 실수를 하는 경향이 있다. 많은 엔지니어링 팀들이 바퀴를 재발명하기를 원한다. 물론 바퀴를 재발명해야 하는 경우도 있다. 하지만 균형이 필요하다.

인프라 담당자는 모든 것을 자동화하는 것을 지상과제로 한다. 소프트웨어 개발 역시 가능한 코드 없이 솔류션을 만드는 방향으로 고민을 해보자. 더 적은 시간에 더 안정적이고 효과적인 솔류션의 개발이 가능할 것이다. 이를 위해서는 "문제해결이 아닌 솔류션 제공"이라는 마인드를 가져야 한다.

### 모든 시스템은 형편없다. 적응하고 극복하라.
> 언어에는 두 가지 종류만 있습니다. 사람들이 불평하는 언어와 아무도 사용하지 않은 언어죠. - Bjarne Stroustrup

아마도 여러분은 지금의 설계, 라이브러리, 개발환경 모든 것이 만족스럽지 않을 것이다.

소프트웨어 엔지니어는 완벽함을 지향해야 겠지만, 또한 완벽한 시스템은 존재하지 않는다는 것을 받아들여야 한다. 사람뿐만 아니라 기술과 조직도 완전하지 못하기 때문이다. 소프트웨어 엔지니어는
1. 시간 : 고객에게 전달되어야 하는 비즈니스 목표.
2. 비용 : 투입가능한 돈. 
3. 품질 : 인프라, 백앤드, 프론트앤드, 고객관리 등 품질에 대한 제약사항
4. 기술숙련도 : 조직의 능력과 조직 구성원의 능력

등 다양한 부분에서의 **상충조건(trade-off)** 을 검토하여 "완전함이 아닌 온전한 솔류션"을 개발해야 한다. 이것을 상황을 개선할 필요가 없다는 변명으로 받아들이면 안된다. 완벽함과 아름다움에 대해서 걱정하는 대신에 **지속적인 개선을(Continuous Improvement)** 위해 노력하고 이를 위한 시스템을 구축하라는 의미다. GitOps, DevOps, CICD Pipeline, 코드리뷰 등 개선 및 가치증분 중심의 시스템으로 부터 도움을 받을 수 있다.

### 솔류션의 소유
누군가가 작업결과가 나와 상관 없다고 생각하면 프로젝트에 대해서 덜 신경을 쓰게 된다. 프로젝트에 신경을 쓰지 않는다면 좋은 제품이 만들어질리가 없다. 내가 제품을 책임지고 있으며 소유하고 있다는 이 느낌을 우리는 **주인의식** 이라고 부른다.

인간은 나와 별 관계가 없는 것에 신경을 쓰지 않는다. 내가 통제할 수 없는 것에 대해서도 마찬가지다.그래서 제품의 구성요소들을 찢어 놓고서는 **주인의식** 타령하는 것은 사람 기분만 상하게 할 뿐이다.

이런 것들은 사람 바꾸려하지말고(주인의식 타령하지 말고) 시스템화(조직과 문화를 만드는) 하는 것으로 해결해야 한다. 회사들이 교차 기능팀이나 DevOps 조직을 만드는 시도를 하는 이유다. 이 시도의 핵심은 각 팀이 "**자기가 맡은 부분만 최적화 하는 것을 넘어서서, 솔류션 관점에서 바라보게 하는 것**"이다. 즉 각 팀이 "코드 혹은 컴포넌트 소유하는게 아닌 솔류션을 소유"하도록 해야 한다. 열정적인 사람들의 그룹에 프러덕트의 모습을 공유하고 소프트웨어의 설계, 구축에 대한 소유권을 부여하면 놀라운 일이 일어날 것이다.

### 반짝이는 기술보다는 오래 살아남은 기술
IT 산업에서 오래 살아남은 기술들은 그럴만한 이유가 있어서 살아남은 것들이다. 이러한 도구, 기술은 화려하지도 않고 흥미롭지도 않지만 빠르고 안정적으로 작업을 마무리 할 수 있도록 도와줄 것이다. 그러니 이러한 기술에 반대하지 말고 타당한 이유가 있을 경우에만 교체하자.

### 시니어 엔지니어와 주니어 엔지니어의 가장 큰 차이점중 하나는 그것이 있어야 하는 이유에 대한 의견을 형성했다는 점이다.
뛰어난 엔지니어는 어떤 **기술이나 솔류션에 대한 의견**을 가지고 있다. 단 실패와 성공의 경험을 통해서 형성된 의견이어야 한다. 그렇지 않은 의견은 **부정적 선입견**으로 작용 할 수 있으니 주의해야 한다. 다른 언어, 라이브러리, 패러다임, 플랫폼을 탐색하고 그것을 적극적으로 수행해야 한다. 이 보다 기술을 더 빨리 올리는 방법은 없다.

### 대대적인 패러다임 변화와 새로운 발명보다 "작은 변화"
크고 멋진 결과물을 만들어내는 변화를 이끌어내고 싶겠지만 중대한 변화는 조직을 불안하게 만든다. 작은 변화를 통한 지속적인 개선 모델은 두려움을 줄이고 출시 속도를 높일 수 있다.

대대적인 패러다임 변화를 비교적 빠르게 만들어내는 조직이 있기는 하다. 나도 몇 번 그런 것들을 본 적이 있는데, 아래의 것들이 맞아 떨어져야 한다.
1. 적당한 크기의 조직
3. 해당 리더가 말과 글로 설득하고 동의를 이끌어내고, 앞장서서 조직을 재편하고, 기술을 실행 할 수 있을 정도로 정치적으로 실무적으로 뛰어나다.
2. 대대적인 패러다임 변화는 곧 조직의 변화를 의미하기 때문에 리더가 충분한 권한을 가지고 있어야 한다.

이런 것들이 갖춰져 있지 않은 상태에서 대대적인 패러다임 변화는 매우 높은 확률로 실패할 것이다.

### 마이크로매니징
나는 마이크로매니징을 하지 않는다. 그럼 어떻게 관리하냐면, 작업 방향을 가이드하고 결과를 측정 할 수 있는 환경을 만드는데 집중 한다. 작업자가 스스로 자신이 작업한 결과를 측정하고 부족한 부분을 생각해서 개선할 수 있도록 한다. 그러니까 나는 방향을 제안하되 프로젝트 품질에 중대한 영향을 미치는 것이 아니라면 개발자가 선택 하도록 하고 그 결과에 책임지도록 한다. 자신의 결과를 측정하고 그에 대해서 책임을 질 수 있어야 발전하는 것이다.

여기에서 "책임"이라는 것은 "너가 잘 못해서 이러한 결과가 나왔으니 무엇을 해야되"가 아니다. 다음 개발주기에 스스로 혹은 함께 개선안을 찾아내는 것을 의미한다.

결국 마이크로매니징에서 벗어나려면 3가지가 필요하다.
1. 업무 측정/평가 프로세스를 만들정도로 **능동적**이어야 한다.
2. 새로운 업무 측정/평가 프로세스를 만들정도로 **생각이 열려 있어야** 한다.
3. 자유를 주는 만큼 리스크(책임)이 늘어난다. 리스크를 관리할 수 있을 정도로 **실무적으로 똑똑**해야 한다.

## 나이 차별은 존재한다.
바라는 세상과 살아가는 세상은 다르다는 것을 인정해야 한다. 나이 차별은 존재한다. 앞으로 나아질 수도 있지마 엄연한 현실이다.

30대 중반 개발자가 30대 중반 개발자가 가져야 하는 능력을 가졌다면 쉽게 직장을 찾을 수 있을 것이다. 45세 개발자가 30대 중반의 능력을 가졌다면 직장을 찾을 수 없을 것이다. 나이를 안본다면 나이와 상관없이 30대 중반 실력만큼 연봉을 주고 고용하면 되는 것 아닐까 ? 이렇게 생각하는 채용담당자를 본적이 있는가 ?

45세 개발자가 그정도 연차에 예상되는 기술을 가졌다면 직장을 찾기가 어려울 것이다.

조세프 캠벨의 "천의 얼굴을 가진 영웅"에서 영웅의 여정의 단계를 묘사하고 있다. 영웅의 여정은 개인의 삶에서도 발견되는 과정이기 때문에, 현재 우리의 처지와 비교해서 해석 할 수 있다. 
1. 일상 세계: 여정을 떠나기전 여정을 준비하는 기간.
2. 모험의 부름, 거부, 승낙: 과업을 달성하기 위한 모험에 참여하라는 부름, 부름에 대한 거부, 부름에 대한 승낙.
3. 직면: 새로운 영역으로 진입하고 실질적인 도전에 직면한다.
4. 시험과 동료: 다양한 시험을 겪고 동료를 만나며, 함께 성정하고 경험을 공유한다.
5. 성장과 위기 그리고 보상: 이를 통해서 성장하고, 위기를 이겨내고 보상을 받는다.
6. 되돌아보고, 회복하고 변화시킨다: 마지막 위기를 극복하고 심리적 정신적으로 성숙하며 모험에서 얻은 유물과 경험을 사회로 가져와서 후배를 교육시키고 일상을 변화시키는 영향력을 행사한다.

즉 나이를 먹으면서 5번과 6번 단계로 나아 갈 것을 기대하게 된다는 것이다. 조직에서 나이 많은 시니어에게 무엇을 기대하는지를 생각해보라. 빠르게 코딩을 하는 그 이상의 것을 원할 것이다.

물론 지식이 생산수단이되는 정보화시대에서 나이에 대한 인식이 변하는 것은 사실이지만, 나이는 생물학적 특성에 기반한 사회/문화적 환경을 기반에 두고 있기 때문에 기술적인 변화보다는 느릴 것이고, 당신이 해당 직업영역에서 특별한 무언가를 가지고 있지 않다면 직업을 찾기가 점점더 어려워질 것이다.

다른 말로 당신이 나이를 먹더라도 일할 걱정을 하지않으려면 "추가적인 가치를 계속 더해가야" 할 것이다. 40세 이상의 개발자에게 사람 관리를 맡기려하는 것이 선입견 혹은 잘못된 판단일까. 그만한 이유가 있다고 생각해야 하지 않을까 ?

## 홍보 
![devOps & Cloud Guru](https://docs.google.com/drawings/d/e/2PACX-1vRLbjCo9i1hxQYG3_1sKs9F0VH880eIL4XJcMdUB_GiwDpEuVT3QQYtQTFtD-hdwNGWSh4BlAdTh2hD/pub?w=944&h=414)
[Facebook DevOps & Cloud Guru](https://www.facebook.com/groups/1554282475101375) 그룹 개설했습니다. 방문 가입 부탁드립니다.

Search For:

BY TAGS

Recent Posts

Archive Posts

Tags

About

Get in Touch

Categories