AI시대에 개발자로서 살아남는 방법

프롤로그

어느덧 개발 실무 경력이 5년 차에 접어들며, 시니어의 단계로 나아가고 있다.

우리 팀 PL(Project Leader)님이 긴 휴가로 자리를 비우게 되면서, 그 공백을 채우기 위해 나에게 '부 PL'이라는 역할이 부여되었다.

솔직히 부담이 컸다. 기존의 개발 업무를 병행하면서 회의를 정리하고, 발생하는 이슈들을 파악해 팀원들에게 적절히 분배하는 리딩 업무까지 수행해야 했기 때문이다. 개발에만 몰입하던 때와 달리 프로젝트 전반에 대한 이해도를 높여야 했고, 팀원들과의 커뮤니케이션 등 고려해야 할 요소가 훨씬 많아졌다.

(부족한 부분을 많은 분들이 도와주셨지만) 그렇게 일주일 정도를 온전히 PL의 역할로 보냈다. 이제는 다시 보조하는 역할로 돌아가겠지만, 이번 경험은 나에게 큰 자극이 되었다. 언젠가 정말 PL로서 팀을 책임져야 하는 순간이 왔을 때 더 잘 해내고 싶다는 욕심이 생겼고, 동시에 앞으로의 개발자 생존 전략에 대해서도 깊이 고민하게 되었다.

복잡한 상황 속에서도 본질적인 가치를 찾아내고 효율성을 극대화하는 법을 배우고 싶었다. 그런 고민 끝에 마주한 이 책은, AI 시대에 개발자가 지향해야 할 미니멀리즘의 원칙을 담고 있었다. 급변하는 환경 속에서 개발자로서의 생존 전략을 어떻게 구축해야 할지, 그 실마리를 《미니멀리즘 프로그래머》 를 통해 찾아보려 한다.

이 책에서는 여러 가지 실천법을 소개하지만 모든 상황이 다르기 때문에 체계화된 규칙을 제시할 수 없다고 전한다. 그래서 글쓴이의 경험을 바탕으로 설명하기에 만능 해결책이 아니며 자신만의 길을 찾아가는 과정의 예시로 삼아달라고 한다.

모든 내용을 기술할 수는 없기에 나에게 필요한 부분만을 정리 할 예정이다.

일하는 방식 단순화 하기

의존성 줄이기

의존성을 추가하면 애플리케이션의 통제권 일부를 포기한다는 뜻이다.

간단한 경우에는 라이브러리를 찾기보다 코드를 작성하는 편이 빠를 수도 있다. 코드의 일부를 라이브러리 작성자에게 위임하면서 당장의 문제는 해결될지라도 동시에 이 코드를 유지보수할 미래의 나에게는 위험과 유지보수 측면에서 복합적 복잡성이 더해진다.

만약 필요한 경우 오픈소스이고 라이브러리가 허용된다면, 해당 라이브러리의 소스를 프로젝트 요구사항에 맞게 수정해서 넣는 방법도 있다.

의존성 격리

광범위하게 사용되는 경우 갑자기 API가 변경이 되면 여러 파일에 걸쳐 코드를 수정해야 할 수 있다.

어떤 의존성을 프로젝트 전반에서 많이 사용한다면, 간단한 래퍼 함수로 감싸서 사용하는 방법으로 API가 변경이 되더라도 래퍼 함수만 업데이트하는 식으로 대응할 수 있다.

필요 주도 개발

기능을 줄여 필요한 것만 더 빨리 제공할 수 있다. 기능은 나중에 언제든지 추가할 수 있으니까 아무도 요청하지 않은 코드는 작성하지 말자.

회의 줄이기

회의는 대게 불공평하고 방해요소이다. 직급이 높거나 지식이 풍부한 참석자에게 쉽게 지배당한다. 또한, 회의에 참석하려면 하던 일을 모두 멈춰야한다. 회의가 끝난 뒤 하던 일의 맥락을 다시 파악하고 흐름을 복구해야하는 속도는 보통 15~30분이다.

회의시간을 절반으로만 줄여도 개발자 한 명 근무 시간의 80%에 해당하는 여유 시간이 생긴다. 꼭 필요한 사람만 참여하는 최소한의 회의를 해야 한다.

회의를 단순화하는 가장 좋은 방법은 자료를 미리 공유하고 참석자를 정교하게 거르는 것이다. 준비 과정에서 스스로의 오해를 바로잡아 불필요한 모임을 방지할 수 있을 뿐만 아니라, 꼭 필요한 소수 인원만 모였을 때 비로소 깊이 있는 토론과 빠른 의사결정이 가능해지기 때문이다.