앞으로 나아갈 방향

1. AI 시대를 맞이하면서

AI라는 강력한 도구를 통해서 코드를 빠르게 작성할 수 있게 되었다. (코드를 ‘잘’ 작성할 수 있게 되었는가에 대해서는 아직 논쟁의 여지가 있긴하지만,,)

또, AI는 개발에 대해서 허들을 낮춰주는 도구로도 사용되고 있다. 바이브 코딩이라는 키워드는 비웃음거리에서 이제는 너무 당연해져가는 추세이며, 링크드인에서 바이브코딩만으로 짧은 시간안에 제품을 만들고 자동화를 했다는 글은 한 번 스크롤하면 다섯개씩은 찾을 수 있다.

내 밥그릇을 박살내는 중인 승완이

그럼 이제 난 어떻게 해야할까? 그냥 개발자를 접어야 하나? 그에 앞서서 해봐야 할 생각은, 개발자의 가치는 어디서 나올까? 라는 질문이다. 개발자의 가치는 코드 작성만으로 나오는게 아니다. 제품 본연으로 돌아가서 생각해보자.

제품의 가치

우선, 사용자는 코드에는 아무런 관심이 없다. 토스는 많은 사람에게 매력적인 경험을 제공하면서 사랑받았지만, 사용자들은 토스의 코드가 어떻게 작성되어 있는가에는 아무런 관심이 없다.

사용자라면 ‘어떤 기능이 있는가’가 1순위고, 그 다음이 ‘그 기능이 잘 동작하는가?’, 그리고 ‘기능이 쓰기 쉬운가’ 정도가 중요할 것이다. 즉, 제품의 가치도 여기서 나온다. 사용자가 중요하게 느끼는 것이 곧 제품의 가치다.

그렇다면 만드는 입장에서 이걸 바라보면 아래와 같이 생각할 수 있을 것 같다.

• 어떤 기능이 있는가? → 무엇을 만들까?
• 그 기능이 잘 동작하는가? → 어떻게 만들까?
• 기능이 쓰기 쉬운가? → UI/UX를 어떻게 만들까?

그렇다. 코드 작성 자체는 ‘어떻게 만들까’에서도 일부분에 불과하다. 그럼 제품의 가치는 그렇다 치고, 개발자의 가치는 어디서 나오는가?

개발자의 가치

개발자의 가치는 제품을 빠르게, 잘 만드는 것에서 나온다.

우선 직접적으로 제품을 만드는 사람이 개발자이니만큼, 잘 동작하는 제품을 만들 수 있어야 한다. 가능한 에러가 터지지 않아야하고, 터지더라도 사용자에게 불쾌함을 주지 않아야하며, 가능한 빠르게 복구되어야 한다. 또 비즈니스 측면을 고려하면 추후에 제품이 어떤 방향으로 나아갈지를 고려해서 수정이 쉽게 만들어야한다.

왜 수정이 쉬워야 하나? 모든 제품은 시간이 지나면 가치가 조금씩 사라진다. 10년 전, 토스의 간편송금은 사용하지 않고는 참을 수 없는 매력적인 기능이였다. 하지만 이제는 그냥 당연한 기능이다. 만약 지금 간편송금 서비스를 만든다면? 아무도 사용하지 않을 것이다.

10년 전 토스 로고,, 근데 기억이 안난다,,

그래서 제품은 끊임없이 변화하기 마련이다. 사용자들이 필요로 하는 가치를 제공하기 위해서. 이를 위해서는 제품이 빠르게 사용자들에게 도달할 수 있어야 하고, 수정이 쉬워져야 한다. 그것을 위해서 패턴과 아키텍처들이 존재한다.

또한 수정을 쉽게 만들면 자연스럽게 무엇을 만들지, UI/UX는 어떻게 할지도 빠르게 판단할 수 있다. 이번 사이드 프로젝트의 경우에는 내가 A부터 Z까지 모든 부분을 도맡았지만, 대다수의 회사에서는 디자인과 기획을 하는 사람이 따로 있는 경우가 많다. 그리고 이 사람들은 고민을 한다. ‘뭘 만들어야할까? 이게 사용자들이 원하는게 맞을까? 이렇게 만들면 사용자들이 편하게 사용할 수 있을까?'

하지만 문제는 아무리 고민해도 실제로 사용자들에게 전달되기 전에는 아무도 모른다는 것이다. 사용자들에게 전달되려면 실제로 기능이 동작해야하고, 결국 개발자들을 거쳐야한다. 이 과정에서 개발자들이 도와줄 수 있는 방안은 다음과 같다.

1. 실제 만들기의 일정을 산정한다. 만약 너무 길어진다면 적절하게 분리해서 꼭 필요한 기능만이라도 먼저 출시될 수 있어야 할 것이다.
2. 최대한 빠르게 문제를 해결할 방안을 궁리한다.
   • 예를 들어, B 기능을 새로 만들어서 테스트하고 싶은데 현재의 코드에서는 기존 A기능의 대폭 수정이 필요한 상황이라면, B 기능을 제품에 바로 구현하는 대신 별도로 배포해서 Iframe으로 삽입하고 토큰만 공유한다던가…
3. 작업속도를 올릴 수 있도록 노력한다.
   1. 코드 내적으로는 적절한 아키텍처와 디자인 패턴을 사용해서 코드를 수정이 쉽도록 작성한다.
   2. 코드 외적으로 생산성을 높일 방안을 궁리한다.
      1. 문서화를 잘 한다거나
      2. n8n이나 Lovable같은 제품을 사용해서 자동화를 하거나
      3. 테스트를 쉽게 도와준다거나.. 등등 여러 방법이 있을 것이다.

그러면 다시 돌아가서, 나는 뭘 해야할까?

2. 왜 프로덕트 엔지니어인가?

AI라는 강력한 도구가 나오면서 가장 좋아진 것은, 코드 작성의 가치가 낮아졌다는 것이다. 맨 위에서는 슬픈 소식이였지만 이제는 아니다. 개발자에게는 코드 작성이 전부가 아니라는 것을 알게 되었거든. 그럼 우리는 뭘 해야하는가? 프로덕트 엔지니어가 되면 된다.

코드 작성의 가치는 낮아졌지만, 제품을 빠르게 잘 만드는 것의 가치는 여전히 높다. 그리고 이것을 위해서는 비즈니스에 대한 이해도가 필수적이다. 비즈니스를 잘 이해하고 있으면 프론트엔드, 백엔드에 얽매이지 않고 코드를 작성할 수 있다. AI가 도와줄 거니까. 인프라도 AWS의 Q Developer처럼 AI가 침투해가고 있다.

이제 내가 선택할 수 있는 것은 두 가지이다.

1. AI가 잘 작성하지 못하는 높은 가치의 코드를 작성하는 코어 개발자가 된다.
2. 제품 전반을 아우르는 프로덕트 엔지니어가 된다.

여기서 나오는 것이 내 개인적인 성향이다. 나는 제품을 만드는 것을 좋아한다. 물론 아름다운 코드와 기술적으로 딥다이브 하는 것에 흥미가 없는 것은 아니다. 하지만 내가 개발자로 진로를 정한 이유만 봐도 알 수 있듯이, 나는 기본적으로 남에게 영향을 주는 것을 좋아하는 오지랖 넓은 사람이다.

물론 코어 개발자가 되어도 다른 개발자들에게 영향을 줄 수 있겠지만, 그것보다는 프로덕트 엔지니어가 되는 것이 훨씬 더 많은 사람들에게 영향을 줄 수 있지 않을까?

이런 생각으로 사이드 프로젝트를 요즘 진행중이다. AI 시대일수록 오히려 글쓰기와 글읽기 능력이 중요해질 것이라는 친구의 조언에서 아이디어를 얻어서 시작했다. 글을 읽고 요약한 다음, 그것을 AI에게서 피드백을 받으면서 읽기와 요약 능력을 키우는 서비스이다. 

요약의 정석: 요정

위에서 말한 것처럼 프론트엔드와 백엔드, DB, CI/CD, Infra, 그리고 디자인까지 모두 AI를 사용해서 만들어보고 있다. 물론 아직은 프론트엔드를 벗어나면 모자란 부분이 많기에, 하나씩 배워가며 성장하고 있다. 백엔드 아키텍처를 설계할 때도, 인프라를 구성할 때도, AI의 도움을 받으면서 '왜 이렇게 동작하는지'를 이해하려고 노력하고 있다.

물론 이걸 한다고 곧바로 프로덕트 엔지니어로 취업하기는 어려울 것이다. 하지만 AI가 대신해주는 건 코드 작성이지, 제품을 만드는 고민을 해주는 것은 아니다. 그 고민을 할 수 있는 사람이 결국 살아남을 것이고, 나는 그런 개발자가 되고 싶다.