20년쯤 전, 네이버에서 어떤 에세이 작가가 글을 잘 쓰는 방법에 대해 이야기하는 걸 본 적이 있다.
정확한 표현은 기억나지 않지만, 내 기억 속에는 두 가지 조언이 남아 있다.
좋은 펜과 비싼 종이를 써라.
그리고 주변에 또라이가 많아야 한다.
물론 그 작가가 정말 '또라이'라는 표현을 썼을 리는 없다. 20년이라는 시간 동안 내 기억 속에서 꽤 과격하게 각색된 것 같다.
하지만 그 의미만큼은 지금까지도 선명하다.
대학 시절 내 주변에는 유난히 독특한 친구들이 많았다. 학교 전체를 뒤져 가장 별난 사람 몇 명을 고르라고 한다면, 그 안에 내 친구들이 꼭 들어갈 것 같았다.
그때는 글이 정말 후두둑 쏟아졌다.
평범하게 지나칠 법한 사건도 그 친구들과 함께하면 이야깃거리가 됐다. 내가 생각하지 못했던 관점으로 세상을 바라보는 사람들이 주변에 있다는 것 자체가 끊임없는 영감이었다.
좋은 글을 쓰려면 세상을 다르게 바라볼 기회가 많아야 한다는 말이었을까.
첫 번째 조언도 묘하게 오래 남았다.
나는 수천 개의 글을 써두고도 마음에 들지 않으면 지워버리곤 했다. 이것도 별로고, 저것도 별로고. 그렇게 지우고 나서 몇 달 뒤에는 꼭 후회했다.
만약 값비싼 종이에 글을 썼다면 어땠을까.
내용이 마음에 들지 않더라도 쉽게 버리지는 않았을 것이다. 그리고 모르지. 그 안에 몇 년 뒤 싹을 틔울 씨앗 하나가 들어 있었을지도.
그렇게 생각하면 좋은 도구란 단순히 결과물을 잘 만들어주는 물건만은 아닌 것 같다. 내가 만든 것을 조금 더 신중하게 바라보고, 쉽게 버리지 않도록 만드는 환경이기도 하다.
20년이 지나, 전혀 다른 펜을 만났다
나는 지금 프리랜서 개발팀의 팀장으로 일하고 있다.
현재는 나까지 네 명이고, 프로젝트를 진행하며 함께했던 사람까지 포함하면 여섯 명 정도의 개발자와 일했다.
그리고 최근 1년 사이, 개발팀이 일하는 방식은 꽤 많이 달라졌다.
AI 때문이다.
과거에는 요구사항을 분석하고 설계를 마치면 개발자가 직접 코드를 작성하는 데 많은 시간을 썼다.
지금은 내가 프로젝트의 구조와 공통 규칙을 설계하고, 팀원들과 구현 방향을 논의한 뒤 AI를 적극적으로 활용해 코드를 작성한다.
린트와 자동화된 규칙으로 일차적인 문제를 걸러내고, 마지막에는 MR을 검토하면서 설계 의도와 구현 결과가 일치하는지 확인한다.
물론 AI가 작성했다고 해서 그대로 사용하는 것은 아니다. 잘못된 가정을 하기도 하고, 그럴듯하지만 실제 요구사항과 맞지 않는 코드를 만들기도 한다.
그래서 검증과 책임의 주체는 여전히 사람이다.
하지만 분명한 변화가 있다.
이제 좋은 결과를 만들어내기 위해 개발자가 반드시 모든 코드를 직접 작성해야 하는 것은 아니다.
처음에는 이 변화가 단순히 개발 속도를 높이는 일이라고 생각했다.
그런데 팀을 운영하다 보니 조금 다른 부분이 보이기 시작했다.
코드를 잘 쓰는 사람과 개발을 잘하는 사람
개발자가 코드를 잘 작성한다는 것은 오랫동안 중요한 능력이었다.
물론 지금도 중요하다. 다만 AI가 구현 과정의 상당 부분을 담당할 수 있다면, 개발자의 역량을 평가하는 기준도 조금씩 달라질 수밖에 없다.
같은 AI를 사용하더라도 결과물은 사람마다 다르다.
요구사항을 얼마나 정확하게 이해했는지, 어떤 구조를 선택했는지, 무엇을 검증해야 하는지에 따라 결과가 달라진다.
AI가 만들어낸 코드를 읽고 문제를 발견하는 능력도 필요하지만, 애초에 잘못된 방향으로 개발이 진행되지 않도록 판단하는 능력은 더 중요해질 수 있다.
팀장으로서도 비슷한 변화를 경험하고 있다.
예전에는 팀원이 기술적으로 어려운 문제를 해결할 수 있는지, 얼마나 안정적으로 구현할 수 있는지가 중요한 관심사였다.
지금은 그에 더해 문제를 어떻게 정의하는지, AI가 제안한 방법을 어떤 근거로 받아들이거나 거절하는지, 자신의 결과물을 얼마나 책임 있게 검증하는지를 보게 된다.
결국 내가 해야 할 일도 바뀌고 있다.
좋은 코드를 직접 작성하는 것만큼이나, 팀 전체가 반복해서 좋은 결과를 만들어낼 수 있는 구조를 설계하는 일이 중요해졌다.
개발자는 정말 사라질까
AI가 개발자를 대체할 것이라는 이야기를 자주 듣는다.
나는 이 질문을 조금 다르게 바라보고 있다.
회사가 개발자에게 비용을 지불하는 이유는 코드를 몇 줄 작성했기 때문이 아니다.
필요한 기능을 만들고, 문제를 해결하고, 안정적으로 서비스를 운영하기 위해서다.
그 결과를 만드는 과정에서 코드 작성에 필요한 시간이 줄어든다면, 개발자의 역할 역시 달라지는 것이 자연스럽다.
물론 그렇다고 고용 규모가 줄어들지 않을 것이라는 뜻은 아니다.
적은 인원으로 이전과 비슷하거나 더 많은 일을 할 수 있게 된다면, 기업이 인력을 운영하는 방식에도 변화가 생길 것이다.
당장은 기술이 변화하는 속도에 비해 조직과 계약 구조가 느리게 움직이고 있다. 여전히 사람 수를 기준으로 견적을 내고, 역할을 구분하고, 프로젝트를 운영하는 경우가 많다.
하지만 이런 구조도 언젠가는 달라질 것이다.
그때 개발자의 가치는 얼마나 많은 코드를 작성했는가보다, 얼마나 복잡한 문제를 해결할 수 있는가에 더 가까워지지 않을까.
내가 10년 동안 개발자로 일하며 쌓아온 경험 역시 단순히 코드를 작성하는 속도에만 있는 것은 아닐 것이다.
수많은 시행착오와 실패, 잘못된 설계를 바로잡았던 경험, 사람들과 의견을 조율하고 결과를 책임졌던 시간에 더 많은 가치가 있을지도 모른다.
AI가 구현을 도와줄수록 그런 경험을 어디에 활용할지 더 많이 생각하게 된다.
결국, 주변에 또라이가 많아야 한다
다시 20년 전 작가의 이야기로 돌아가 본다.
좋은 펜과 비싼 종이, 그리고 주변의 별난 사람들.
그때는 글을 잘 쓰기 위한 조언이라고 생각했다.
지금 생각해 보면 무언가를 만드는 사람에게도 꽤 잘 어울리는 이야기다.
우리는 이제 이전과 비교하기 어려울 만큼 뛰어난 도구를 손에 넣었다.
하지만 좋은 도구가 있다고 해서 누구나 같은 결과물을 만드는 것은 아니다.
무엇을 만들지 결정하려면 세상을 관찰해야 하고, 익숙한 방법을 의심할 줄도 알아야 한다. 때로는 나와 전혀 다르게 생각하는 사람을 만나야 새로운 문제를 발견할 수 있다.
지금 내가 일하는 현장에도 그런 장면이 많다.
AI가 예상보다 뛰어난 결과를 만들어내는 순간도 있고, 아주 단순한 문제에서 엉뚱한 답을 내놓는 순간도 있다.
오랫동안 당연하게 여겨졌던 개발 방식이 하루아침에 비효율적으로 보이기도 하고, 반대로 오래된 경험 하나가 AI의 잘못된 판단을 바로잡기도 한다.
이런 변화 속에서 팀을 이끌다 보니 내가 개발자로서 무엇을 더 잘해야 하는지도 조금씩 선명해진다.
코드를 작성하는 방법을 계속 익히는 것만으로는 충분하지 않다.
좋은 문제를 발견하고, 적절한 방향을 선택하고, 함께 일하는 사람들이 더 좋은 결과를 만들 수 있도록 돕는 능력이 필요하다.
20년 전에는 글을 잘 쓰고 싶어서 그 작가의 조언을 기억했다.
지금은 개발팀을 이끌면서 그 말을 다시 떠올린다.
좋은 도구를 사용하고, 서로 다른 생각을 가진 사람들과 일하고, 당연해 보이는 것에도 끊임없이 질문하는 것.
어쩌면 좋은 개발자로 남기 위해 필요한 것도 크게 다르지 않을 것이다.
