AI가 개발자를 대체하는 시대에 어떤 개발자가 되고 싶은가

서론

나는 어떤 개발자가 되고 싶은가?

 

개발 공부를 2~3년 해오면서, 부트캠프도 다니고 사이드 프로젝트도 여럿 진행했지만 정작 "나는 어떤 개발자인가"라는 질문엔 명확하게 답하지 못했다.
AI가 코드를 짜고, 혼자서도 서비스를 만들어내는 시대가 됐다. 개발자가 하던 일의 상당 부분을 AI가 대신하고 있다. 그 흐름을 보면서 질문이 더 선명해졌다. AI가 대체할 수 없는 개발자는 어떤 개발자인가. 나는 그런 개발자가 될 수 있는가. 그 생각을 정리해 글로 남긴다.

 

개발자가 되고 싶은 이유

사람들이 나로 인해 편해지는 것 자체가 좋았다.

 

개발을 시작한 계기는 순수하지 않았다. 학과 동아리 'CIA'에서 캡스톤 대회를 준비하게 됐고, 솔직히 말하면 대회 수상으로 졸업 시험을 면제받고 싶다는 생각이 컸다.

 

결과는 기대에 못 미쳤다. 하지만 과정에서 얻은 것이 훨씬 많았다.

첫 작품에서는 선배들의 도움을 받아 C++로 'IoT 스마트 신생아 침대'에 들어갈 음악 플레이어를 구현했다. 지금 생각하면 간단한 내용이지만, 코드를 처음 써보는 나에게는 막막한 일이었다. 그래도 해냈고, 두 번째 작품인 '근전도 센서를 이용한 스마트 IoT 전동 휠체어'에서는 모터 제어 파트를 직접 담당했다. 그 작품으로 시 대회에서 은상을 받았다.

규모는 작았고, 누군가에게는 사소한 경험일 수 있다. 그러나 나에게는 내 손으로 불편함을 편리함으로 바꾼 첫 경험이었다. 결과물이 실제로 작동하는 순간, 이게 누군가의 불편함을 없앨 수 있겠구나 싶었다. 그 보람이 개발자라는 직업을 선택하게 만든 진짜 이유다.

 

개발자가 되기 위한 노력

처음에는 개발만 열심히 하면 된다고 생각했다.

IoT 임베디드 개발을 공부하면서 한 가지 깨달은 것이 있었다. 아무리 좋은 도구를 만들어도, 사람들의 손에 닿지 않으면 쓸모가 없다는 것이다.

억만장자가 될 수 있는 도깨비 방망이를 만들어놨는데, 아무도 그걸 집어 들 수 없는 상황이랄까.

처음 그 생각이 들었을 때는 허무했다.

열심히 만들어도 도움이 안 된다면 왜 만드는 건지, 우물 안에서 세상을 정복하는 상상만 하는 기분이었다.
그때 눈에 들어온 것이 웹이었다. 컴퓨터 없는 집이 드물고, 인터넷은 공공 와이파이가 생길 만큼 어디서든 쓸 수 있는 시대였다. 웹이라면 내가 만든 것을 실제로 사람들에게 전달할 수 있겠다 싶었다. 

그 생각 하나로 웹 개발로 방향을 틀었다. 제어계측공학과였지만 컴퓨터공학과 전공인 Java, SQL 수업을 직접 신청했고, 인프런과 유튜브로 HTML, CSS, JavaScript를 독학했다. 그 과정에서 친구 회사의 웹 페이지 개선 작업을 맡기도 했다.

 

이후 운 좋게 SSAFY(삼성 청년 SW 아카데미)에 합류했다. 

Python 백엔드, JavaScript 프론트엔드, 자료구조와 알고리즘까지 개발의 기초를 본격적으로 쌓기 시작했다. 그리고는 백엔드 개발자가 되고싶다는 생각을 생각했다. 하지만 나는 대부분의 프로젝트에서 프론트엔드를 맡았다.

프론트엔드를 처음 맡게 된 이유는 사실 단순했다. 모두가 백엔드를 원했고, 팀에 프론트엔드를 할 사람이 없었다. 나보다 백엔드를 잘하는 사람이 많았기에 자연스럽게 그쪽으로 흘러갔다.

그렇게 시작한 프론트엔드였지만, 프로젝트를 거칠수록 점점 익숙해졌다. Flutter로 화상 인증 알람 앱 '모여람'을 만들며 WebRTC를 공부했고, 이어서 React 기반 AI 중고책 가격 예측 서비스 '쳌책'에서 프론트엔드를 맡았다. 마지막 프로젝트인 실시간 수어 통역 앱 '손톡'에서는 on-device AI 구현을 위해 ML 파트까지 담당했다. 그 프로젝트로 전국 부문 최우수상을 받았다.

그러니 당연히 취업도 될 거라 생각했다. 코로나 시절 개발자 붐이 한창이었고, 주변에서 취업이 잘 되는 모습을 보며 나도 당연히 될 거라 여겼다.

그런데 취업은 되지 않았다. 이유는 단순했다. 취업 준비를 하지 않았기 때문이다.

취업이 안 됐을 때 처음엔 당황했다. 하지만 원인이 명확했기에 흔들리지는 않았다. 기술의 깊이가 부족하다고 느꼈고, 그 부분을 채우기로 했다.

그리곤 기초를 다지고 싶어 부트캠프에 들어가 팀 프로젝트를 이어갔다. 부트캠프 기간에도 외부 스터디를 병행했는데, 그때 모던 리액트 딥다이브를 함께 공부하던 분이 뜻밖의 제안을 해주셨다.

운이 좋았던 첫 취업

좋은 팀과 좋은 직장이었지만, 나는 다른 곳을 바라보고 있었다.

모던 리액트 딥다이브 스터디를 함께했던 분이 부트캠프 조교 역할을 추천해주셨다. 직무 내용은 프론트엔드 부트캠프 수강생들을 돕는 일이었다. 

내가 목표했던 개발 직무는 아니었지만, 운영 프로세스를 개선하고 수강생의 문제를 해결하면서 스스로도 성장할 수 있을 거라는 기대감으로 입사했다.
조교로 일하면서 불편한 점이 보이면 바로 손댔다. 스프레드시트에 Apps Script를 적용해 반복 업무를 자동화했고, 수기로 작성하던 휴가 신청서를 웹 페이지로 전환해 처리 과정을 줄였다.

 

이런 노력을 인정받아 정규 러닝코치직을 제안받았다. 처음엔 잠깐 고민했지만, 더 많은 걸 개선할 수 있다는 생각에 수락했다.

이후에도 쪽지시험, 스탬프 제도 등 곳곳에 흩어진 데이터를 한데 모아 자동화했고, 이를 바탕으로 운영 프로그램을 구성했다. 동료분들과 타 팀에서도 "큰 도움이 된다"는 말을 자주 들었는데, 그 말 한마디가 계속 일할 수 있는 힘이 됐다. 물론 코치 업무도 소홀히 하지 않았다. 질의응답, 강사 관리, 학습 자료 제작까지 병행했다. 그러다 보니 야근이 잦아졌다.

어느 날 문득 거울을 봤는데, 초췌하고 지친 얼굴이 보였다. 이게 내가 원하던 일인가. 개발 업무를 하고 싶어서 코치 역할을 등한시하고 있는 건 아닌가. 스스로에게 질문이 많아지면서 이직을 결심했다.
막상 준비해보니 생각보다 훨씬 어려웠다. JavaScript 스터디를 직접 만들어 운영하고, 퇴근 후에는 이력서를 쓰고 면접을 다녔지만, 잦은 야근과 병행하기에는 체력이 버텨주지 않았다.

결국 퇴사를 결심했다. 감사하게도 동료분들은 아쉬워하며 응원해주셨다.

 

---

현재의 나

개발을 하고싶던 아이에게 개발이라는 벽이 생겼다.

 

퇴사하고 나서 처음 며칠은 오히려 멍했다. 그토록 원하던 시간이 생겼는데, 막상 무엇부터 해야 할지 몰랐다. 야근에 치여 미뤄뒀던 이력서를 다시 펼치고, 오랜만에 코드를 마주했다.
솔직히 말하면 불안하다. 취업이 안 되면 어쩌지라는 생각도 든다. AI가 코드를 대신 짜주는 시대에, 신입 개발자가 설 자리가 있을까라는 생각도 따라온다. 하지만 동시에, 이게 처음으로 내가 진짜 원하는 것을 제대로 들여다보는 시간이라는 걸 느낀다. 지금껏 늘 무언가에 쫓기듯 공부하고, 프로젝트하고, 일했다. 그러면서 정작 "나는 어떤 개발자가 되고 싶은가"라는 질문은 계속 뒤로 미뤄왔다. 지금은 그 질문 앞에 제대로 서있는 중이다.
천천히 이전 개발들을 돌아봤다. 내가 아쉬웠던 순간들에는 패턴이 있었다. 글자 줄바꿈 같은 사용자 경험의 디테일, 규모에 맞지 않는 아키텍처, 일관성 없는 코드. 이것들이 "당연히 챙겨야 하는 것"임은 알고 있었다. 하지만 시간 압박이 오면 코드 품질을 먼저 포기했다. 그 선택 자체가 틀렸다고 생각하지는 않는다. 하지만 이유의 절반은 어떻게 챙겨야 할지 몰랐기 때문이기도 했다. 확장성 있는 코드가 어떤 형태인지, 읽기 좋은 코드가 무엇인지, 내 안에 기준이 없었던 것이다.
지금의 나는 사용자가 불편함 없이 쓸 수 있는 것을 최우선으로 두는 개발자다. 코드 품질의 중요성은 알지만, 그 기준이 아직 내재화되지 않아 시간 압박이 오면 후순위가 된다. 그게 지금 내가 가진 한계다.

어떤 개발자가 되고 싶은가?

좋은 개발자 vs 개발을 잘하는 개발자

 

좋은 개발자와 개발을 잘하는 개발자, 이 두 개념이 오랫동안 머릿속에서 뒤섞여 있었다. 그래서 다시 정리해봤다.

 

"개발을 잘한다"는 기술의 영역이다.

읽기 좋은 코드, 적절한 구조 선택, 빠른 디버깅. 측정 가능하고 비교 가능하다.

 

반면 "좋은 개발자"는 그 위에 방향과 판단이 더해진다.

무엇을 만들지, 왜 만드는지, 그게 실제로 의미 있는지를 스스로 따질 수 있는 것.

 

실력 없는 좋은 개발자는 없다.

하지만 실력만 있다고 좋은 개발자가 되는 것도 아니다.

 

흥미로운 건, AI가 잘하는 영역이 정확히 전자라는 것이다. 코드를 빠르게 생성하고, 버그를 찾고, 반복적인 구현을 처리하는 것. 하지만 무엇을 만들지, 이 구조가 지금 이 상황에 맞는지, 이 코드가 나중에 어떤 문제를 만들지를 판단하는 건 여전히 사람의 몫이다.

 

첫 직장을 돌아보면 이 차이가 선명하게 보인다. 내가 팀에 가장 큰 도움이 됐던 순간은 정교한 코드를 짤 때가 아니었다. 스프레드시트 자동화, 휴가 신청 웹 페이지. 기술적으로 대단하지 않은 것들이었지만, 동료들의 하루를 실제로 편하게 만들었다. 무엇이 필요한지를 파악하고, 그걸 만들기로 판단한 것. 그게 "좋은 개발자"의 모습에 가까웠을 것이다.

 

그런데 정작 나는 그게 만족스럽지 않았다. "개발을 잘하는 개발자"가 되고 싶었기 때문이다.

결국 나는 둘 다 원했던 것이다.

 

그래서 나는 설계를 잘하는 개발자가 되고싶다.

거창하게 들릴 수 있지만, 내가 말하는 설계는 폴더구조, 컴포넌트 구조와 같은 내용만이 아니다.

함수 하나를 짜더라도 의도가 명확하고 누가 봐도 읽히는 코드, 데이터 흐름이 자연스럽고 기능이 늘어났을 때 구조가 버텨주는 코드.

그런 코드를 짜는 사람이 되고 싶다. 이건 AI가 대신해줄 수 없는 영역이다. AI는 코드를 생성할 수 있지만, 이 코드가 지금 이 맥락에서 옳은 구조인지를 판단하는 건 설계자의 몫이다.

 

이 생각은 내가 짠 코드가 나중에 문제가 돼서 고생한 경험에서 왔다. 당시엔 돌아가는 코드를 만드는 데 급급했다.

시간이 지나 그 코드를 다시 마주했을 때, 왜 이렇게 짰는지 내가 기억하지 못했다. 코드가 의도를 명확히 들어내고 있지 않았으니까.

그때 처음으로 "돌아가는 코드"와 "읽히는 코드"가 다르다는 걸 몸으로 느꼈다.

 

사용자 경험을 지키는 것과 설계를 잘하는 것은 결국 같은 방향을 가리킨다. 사용자가 불편함 없이 쓸 수 있으려면, 그 기반이 되는 코드가 흔들리지 않아야 한다. 환경이 바뀌어도, 팀이 바뀌어도, "나는 이렇게 짠다"는 기준이 뚜렷한 개발자.

 

그리고 그 기준의 출발점은 처음과 같다. 사람들이 나로 인해 편해지는 것.

앞으로

기준은 경험 속에서 생긴다. 지금 내가 할 수 있는 건, 그 경험을 의도적으로 만드는 것이다.

 

코드 품질의 기준을 내재화하는 방법은 하나다. 

내가 짠 코드가 나중에 어떻게 문제가 되는지를 몸으로 느끼는 것. 좋은 코드를 읽는 것보다, 나쁜 코드를 직접 고쳐보는 경험이 훨씬 빠르다고 생각한다.

 

예전에 짰던 코드 중 관심사가 섞여있다고 느꼈던 것들을 하나씩 꺼내서 분리해볼 생각이다. 의도가 없어서 나중에 내가 읽지 못했던 그 코드들을. 

정답을 찾는 게 아니라 "이전보다 더 읽히는가, 이전보다 더 버티는가"를 기준으로. AI가 생성한 코드도 마찬가지다. 그 코드가 지금 이 맥락에 맞는지, 나중에 어떤 문제를 만들지를 판단하는 건 결국 내 몫이다. 그 판단력을 키우는 것이 지금 내가 할 수 있는 가장 중요한 일이다.

 

설계는 한 번에 잘하게 되는 게 아니라는 걸 안다. 기준은 경험 속에서 생기고, 경험은 의도적으로 만들어야 한다.
처음 아두이노 결과물이 작동했을 때 느꼈던 그 보람을, 더 많은 사람에게 더 오래 전달하고 싶다. 

그러려면 그 결과물을 떠받치는 코드가 단단해야 한다. AI가 많은 것을 대신해주는 시대일수록, 무엇을 어떻게 만들지를 판단하는 사람이 더 중요해진다.

그게 지금 내가 개발을 공부하는 이유다.