대체할 수 없는 존재

읽은 책

린치핀
개발자로 살아남기
그냥 하지 말라
실리콘밸리는 무엇을 기획하고 어떻게 개발하는가
이펙티브 엔지니어
프로그래머의 뇌
심플 소프트웨어
소프트웨어 장인

많은 사람들이 딥마인드의 알파고와 이세돌의 바둑 대결 이후에 자신의 직업이 AI에 대체되지 않을까 염려를 많이 했다. 그리고 시간이 흘러 이번에는 ChatGPT가 다시 한번 사람들에게 경각심을 주었다. 나도 나의 직업을 AI로부터 지킬려면 어떻게 해야 할지 고민을 한다. "린치핀"에서는 과거 사람들은 산업화와 분업에 의해서 공장에서 기계처럼 일을 했는데, 이렇게 기계처럼 일하는 노동은 쉽게 다른 사람에게 대체 될 수 있다고 말한다. 그리고 그렇게 대체가 쉽기 때문에 회사 입장에서는 최대한 적은 금액으로 고용하고 이윤을 최대화 하려고 한다. 하지만 현재는 브르주아만 생상수단을 독점하는 것이 아니라, 인터넷이라는 것을 통해서 누구나 생산수단을 가질 수 있는 세상이 되었다. 그런데 "린치핀"에서는 기계처럼 공장에서 일 하는 것뿐만 아니라, 그냥 회사에서 시키는 일만 하고 임금을 받는 것도 동일하게 공장에서 일 하는 것이라고 말한다. 우리는 학교에서 지침을 잘 따르면서 미래의 공장노동자로 양성되고 있고, 사회적 성공을 확인하기 위해서 소비한다. "나도 공장에서 일 하는 것처럼 하루 업무를 하고 있지 않은가?" 스스로 질문을 던져 본다. 당신이 하는 일들이 메뉴얼화 될 수 있는가? 이렇게 메뉴얼화 될 수 있으면 그것은 자동화 되거나 더 싼값에 아웃소싱 될 수 있는 일들이다. 그럼 대체 될 수 없는 "린치핀"이 되기 위해서 어떻게 해야 할까?

재미있게도 "린치핀"에서는 감정노동의 중요성을 강조한다. 나는 감정노동이라는 것은 서비스 업무를 하는 사람에게만 해당되고, 이 단어로부터 부정적인 느낌을 받았다. 그런데 인간관계를 맺고 상호작용하는 것이 우리를 대체할 수 없는 존재로 만들어 줄 수 있다고 한다. 따라서 업무처리 하는 기술뿐만 아니라 이러한 대인기술과 상호 작용도 개선하는 것이 필요하다고 말한다. 대체될 수 없는 존재는 어려운 문제들을 해결할 수 있는 사람이다. 그런데 이러한 어려운 문제들이 인간의 다양한 관계들 속에서 풀어내야 하기 때문에 중요하다고 하지 않았을까?

"그냥 하지 말자"에서도 동일하게 톱니바퀴처럼 일하거나 평범함을 추구하면 그 사람은 대체될 수 있다고 말한다. 그래서 자동화된 프로세스를 제공하는 플랫폼을 구축하거나, 특정한 분야의 장인이 되어야 한다고 말한다. "개발자로 살아남기"에서는 "초보 개발자는 시키는 일을 잘하고, 중급 개발자는 시키지 않아도 일을 잘하고, 고급 개발자는 남에게 시키는 일을 잘하면 됩니다. 그보다 위에 있는 고수 개발자는 모르는 일, 한 번도 안 해본 일을 하는 사람입니다."라고 말한다. 남이 만들지 않은 새로운 서비스를 만들 때, 새로운 문제들에 대해서 해결할 수 있는 능력이 필요하다고 한다. 그리고 년차 별로 필요한 역량 중에 매니지먼트와 비지니스 역량도 같이 소개하고 있는데, 이러한 분야는 "감정노동"이 상당히 필요한 영역이다.

예전에 페이스북의 커리어 종류들이 아래처럼 있다라는 공유된 글을 봤었다.

Generalist : 일반적으로 프로젝트를 처음부터 끝까지 이끄는 사람
Specialist: 특정 분야에 깊은 전문성을 가지는 사람
Coding Machine: 몇 명이 할 코딩문제를 혼자 해결하는 사람
Tech Lead: 전반적인 조직을 이끌어 가는 사람
Fixer: 깊은 도메인 기반의 지식을 통해서 문제를 해결해 나가는 사람
Product Hybrid: 복잡한 비지니스 문제를 제품과 엔지니어링 관점을 가지고 해결해나가는 사람.

진짜 엄청난 코딩 실력으로 문제를 해결하는 Coding Machine 같은 타입의 엔지니어는 매니지먼트 관련 업무를 주지 않는 것이 바람직 할 것이다. 리눅스 토발즈나 제프 딘등과 같은 사람들은 혼자 일 하고 아웃풋을 내는 것이 효과적이다. 하지만 다른 종류들은 일반적으로 인간 상호작용 속에서 문제를 해결하는 것이 대부분 필요하다. 그리고 우아한 형제의 대표님이 EO채널에서 인터뷰를 한 영상이 기억이 난다. 프로그래머는 단순히 코딩을 하는 사람이 아니고, 비지니스 문제를 해결하는 사람이라고 설명을 하였다.

대체할 수 없는 개발자

대체할 수 없는 개발자가 되기 위해서 어떻게 해야 할까?

엔니지어링 문제 해결 능력

기본적으로 계속 학습하는 것을 게을리 하지 말아야겠다. 엔지니어링 영역에서의 문제들을 해결하기 위해서는 기술적인 지식이 필요하다. 예전에 샌드버드에서 온라인 세미나에서 여러가지 엔니어링 문제를 해결한 사례들을 들려주었다. 파이썬을 사용하는 관계로 이제 Global Interpreter Lock 때문에 서버의 multi-core를 충분히 활용하기가 어렵다. 그래서 기본적으로 multi-process로 구성하고 있는데, DB connection pool을 적절하게 유지하기 위해서 개별 Process별로 pool을 가지지 않고, database proxy를 로컬에서 띄어서 공유하도록 하였다. 그리고 인터넷이 느린 해외 상황에서 처음 connection을 맺는 시간이 오래 걸리는 문제가 있었다. 이것을 해결하기 위해서 인증서의 사이즈가 적은 것으로 변경도 하고, TLS1.3등을 도입해서 handshake과정에서 발생하는 시간을 줄이려는 노력도 하였다. 또한 Database sharding을 위해서 Vitress 오픈소스를 적용하고 있다라고 했다.

과거 회사에서 이렇게 다양한 엔지니어링 문제들을 해결하는 동료가 있었다. Zabbix를 사용했고 다양한 지표들을 수집하였다. 스크립트로 돌려서 외부 metric들을 가져오고 있었는데, 이부분들의 부하가 커지기 시작했다. 그래서 서버에서 Redis를 로컬환경에서 돌리고 수집하는 python script도 AsyncIO로 비동기적으로 구성하여 로드를 줄이려고 했다. Spinnaker에서는 Template등을 통해서 찍어내고 싶었는데, Spinnaker에서 지원하는 기능은 한계가 있어서 S3에 담겨 있는 Spinnaker 템플릿 형식을 copy해서 집어 넣는 식으로 해결을 했다. 그리고 그것들을 Django Admin 페이지에서 설정해서 관리할 수 있도록 하였다. 개발자들이 사용할 수 있는 Command Tool을 Python으로 개발하기도 하였다. 또한 Bottlerocket os에서 필요한 기능을 추가하여 PR을 올리거나, Gp3 storage type이 나왔을 때 Kuberentes CSI에서 사용할 수 있도록 PR를 올리는 등 오슨소스에 기여하는 것들도 보았다. 작업한 것들을 봤을 때는 그렇게 어렵게 보이지 않았지만, 내가 문제들을 직접 해결해야 할 때는 빠르게 생각해내거나 시도하지 못 했을 것이다.

주니어 개발자 때도 회사에서 다양한 툴을 가지고 빠르게 문제 해결을 하는 동료가 있었다. 그 동료가 나의 롤 모델이었고, 나도 빠르게 문제를 해결하고 싶어서 해커톤에도 나가면서 다양한 시도를 했었다. 하지만 어느 순간 이러한 노력들을 더 이상 하지 않았던 것 같다. 생각해보면 나는 창의적으로 문제 해결을 하는 것에 어려움을 느꼈다. 군대 갔다 와서 과에서 성적 장학금을 여러 번 받을 정도로 성적을 잘 받기도 했었다. 하지만 연구실에 들어가서 연구 보조원으로 논문을 쓸 때는 대상포진에 걸릴 정도로 힘들어했다. 과 시험은 정해진 답이 명확하게 정해져 있는 문제들지만, 실험실에서 해결해 나가야 하는 문제들은 열린 문제였다. 그 답을 찾는 과정도 내가 주도적으로 고민을 하면서 찾아야 했다. 그래도 나는 성장 마인드셋을 가지고 계속해서 도전하고 있다. 다양한 도전을 통해서 Comfort zone을 나올려고 노력해왔다. 이번에 이렇게 생각을 정리하면서 다시 한번 문제를 해결할 수 있는 능력을 개발해야겠다는 생각을 한다.

어떻게 개발 할 수 있을까? 기본적으로 많은 창의적인 학습에서는 어떠한 문제가 있으면 바로 해답을 보는 것이 아니라 다양한 방법을 숙고해보는 것을 연습한다. "몰입" 저자인 황농문 교수님은 과거에 주입식 교육으로 훈련된 인재들이 빠르게 선진국을 따라가면서 성장하는데 큰 기여를 했다고 한다. 하지만 어느정도 우리가 선진국으로 들어왔을 때는 교육도 그것에 맞춰서 좀더 창의적으로 해결할 수 있는 능력들을 키우는데 집중했어야 한다고 말한다. 그리고 그러한 창의성을 키우는 방법으로 문제에 대해서 몰입하여 오랫동안 해결방안을 생각해보는 것을 제안한다. 수학문제를 풀때 쉽게 바로 해답을 보는 것이 아니라, 오랫동안 집중해서 고민을 해본다는 것이다. 컴퓨터 사이언스 기본역량을 다시 한번 점검하면서, 다양한 문제에서 나라면 어떻게 해결했을지 상상하고 고민하는 시간을 가지도록 노력해보자.

과감한 도전

그리고 개발자라면 실리콘 밸리에서 일하는 것을 꿈꿔 봤을 것 같다. "실리콘밸리는 무엇을 기획하고 어떻게 개발하는가" 책에서는 실리콘 밸리는 과감한 도전을 하는 혁신가 마인드를 존중하고, 실패를 포용하는 문화가 있다고 설명한다. 구글에서 HR역할로 일했던 분이 인터뷰에서 왜 한중일 삼국의 인재들은 실리콘 밸리에서 높은 자리에 올라가지 못하는지 연구했다고 한다. 연구를 통해서 다음과 같은 세 가지의 공통점을 찾았다.

권위에 복종하는 문화
관계형성
체면문화

한중일 삼국의 인재들은 목표를 정해주면 열심히 달려가 달성하는 것을 잘하고, 누군가의 자랑이 되기 위해서 일한다고 말한다. 그리고 체면문화는 이제 안전한 것만 하려고 하고, 실패하지 않을려고 하게 만든다.

실리콘밸리의 일류 IT기업에 다니는 사람들은 누구든지 원기 왕성하고 활력이 넘치게 일하고 있다. 실제로 나는 여기에서 그 어느 누구에게서도 “왜 이렇게 죽도록 일해? 우린 그냥 월급쟁이 아냐?”라는 소극적이고 수동적인 발언을 단 한 번도 들어본 적이 없다. 그 이유는 뭘까? 실리콘밸리의 대기업에 몸담고 있지만 모든 사람은 언젠가 이곳을 박차고 나가 자기만의 사업을 하고 싶다는 창업의 열망을 늘 품고 있기 때문이다. 사실 모든 우수한 프로젝트의 탄생 과정은 사람들 각자가 직접 창업하는 과정과 똑같다. 이 모든 과정을 실리콘밸리에서는 ‘부화hatching’라고 부른다. - 실리콘밸리는 무엇을 기획하고 어떻게 개발하는가 책 내용 중 -

기억하자

이펙티브 엔지니어

성장 마인드셋을 가지자. 자신의 지능과 기술을 노력으로 기르고 성장할 수 있다고 믿어라! 도전과 실패를 학습의 기회로 보자!
자신의 프로그래밍 실력이 부족하다고 느낀다면, 다른 활동에 드는 시간을 줄이고 코드를 만들고 작성하는 시간을 늘려라
자신이 사용하는 프로그래밍 언어를 코어 라이브러리도 활용할 수 있도록 마스터하자
시간 절약 도구에 투자하자
업무의 우선순위를 정하자
디버깅 과정 단출을 줄일 수 있도록 미리 생각하자
IDE를 능숙하게 다뤄라
올바른 추상화를 통해서 생산성을 높일 방법을 생각하자.
단순하게 운영하자

심플 소프트웨어

구현에 드는 수고보다 유지 보수에 드는 수고를 줄이는 게 더 중요하다.
유지 보수에 드는 수고는 시스템의 복잡성에 비례한다.
손쉽게 유지 보수할 수 있는 아름다운 구조의 시스템을 만들었다고 생각하는가?
프로그래밍 문제를 평범한 프로그래머가 상상할 수 없을 정도로 쉽게 헤쳐나가는가?
도움을 요청했을 때 모든 걸 명확하고 단순한 개념으로 설명하는가?

비폭력 대화

사실과 평가 구분하는 법 배우기
느낌을 깨닫고 표현하기
욕구를 표헌하고 이해하기
명확하게 요청하기

코드적으로 친절한 사람이 되자

읽는 사람을 위해서 코드를 짜면 Naming부터 구조까지 최대한 읽기 편한 코드로 작성할 것이고, 이것이 좋은 코드가 될 수 있다
초기 명명 관행은 지속적으로 영향을 미친다. 초기에 신중이 정하는 것을 제안한다.
코드에 대해 아무것도 모르는 상태에서 이름이 무엇을 의지하는지 명확한가?
변수 이름으로 도메인이나 프로그래밍 개념이나 이런것들의 정보를 나타낼수 있다.
일관성이 인지 부하가 적다
이름을 명명할 때 어휘사전이 있어서 거기에서 선택하는 것을 말했는데, DDD의 유비쿼터스 랭기쥐처럼 이런것들을 만들 수 있으면 좋겠다. 그래서 도메인 용어와 코딩하는 것이 일치 할 수 있게!

Data-driven

Data는 다양한 이해 관계가 있는 경우에도 합의에 이를 수 있는 좋은 기준이 된다.
얼마나 우리는 가설을 세우고, A/B 테스트를 통해서 입증을 하고 있을까?
우리의 아하 모멘트는 무엇인가? Toss 대표님이 PO session에서 말한 아하 모먼트가 대표님이 만든 용어인줄 알았다. 그런데 그스해킹에서 실제 사용되는 용어이구나!