다시 취준 개발자로 돌아오며
1년도 안 되는 기간 동안 주니어 개발자로 실무를 경험했다.
길게 일했다고 말하기에는 애매한 시간이다. 그렇다고 아무것도 남지 않은 시간은 아니었다. 실제 서비스 코드를 보고, 기능을 만들고, 코드 리뷰를 받고, 일정 안에서 선택해야 하는 상황을 경험했다.
그리고 이제 다시 취준 개발자의 자리로 돌아왔다.
처음에는 아쉬운 생각이 많이 들었다. 좀 더 일해볼걸 그랬나, 좀 더 잘할 수 있지 않았을까 같은 생각이 계속 들었다. 그런데 계속 그렇게만 생각하고 있으면 앞으로 무엇을 해야 하는지 정리되지 않았다.
아직 잘 정리된 것은 아니지만, 지금 내가 주니어 개발자로서 느끼고 있는 생각을 솔직하게 적어보고 싶었다.
내가 생각하는 Junior 답게는 부족함을 합리화하는 말이 아니다. 오히려 반대에 가깝다. 아직 모르는 것이 많다는 사실을 인정하고, 그렇기 때문에 더 작게 나누고, 더 많이 확인하고, 더 깊게 탐구하려는 태도에 가깝다.
AI가 코드를 쓰는 시대
요즘 개발 환경은 정말 빠르게 바뀌고 있다.
이전에는 개발자가 직접 코드를 작성하는 시간이 개발 업무의 큰 비중을 차지했다. 하지만 이제는 AI가 코드 작성의 많은 부분을 대신한다. 간단한 자동완성을 넘어, 요구사항을 설명하면 여러 파일을 수정하고, 테스트를 제안하고, 기능 단위의 구현까지 진행한다.
물론 모든 회사와 모든 프로젝트가 같은 속도로 변하고 있다고 단정할 수는 없다. 하지만 적어도 내가 체감하는 개발 문화에서는 코드를 얼마나 직접 많이 작성하는가보다 AI에게 무엇을 맡기고, 결과를 어떻게 검증하는가가 더 중요해지고 있다.
어쩌면 개발자가 코드 스크립트를 단 1줄도 직접 작성하지 않아도 되는 시대가 오고 있는 것일 수도 있다.
이 흐름은 분명 편리하다. 하지만 주니어 개발자 입장에서는 꽤 큰 불안으로 다가온다.
주니어가 느끼는 벽
시니어 개발자는 AI를 사용할 때 이미 많은 배경지식을 가지고 있다.
수많은 코드베이스를 봤고, 장애를 겪었고, 설계가 무너지는 경험도 해봤을 것이다. 그래서 AI가 만든 코드를 봤을 때 무엇이 위험한지, 어떤 부분을 의심해야 하는지, 이 구조가 나중에 어떤 문제를 만들 수 있는지 비교적 빠르게 판단할 수 있다.
반면 주니어는 그렇지 않다.
AI가 빠르게 코드를 만들어도 그 코드가 좋은 코드인지 판단하기 어렵다. 동작은 하지만 왜 동작하는지 모를 수 있고, 테스트는 통과하지만 설계상 위험한 지점을 놓칠 수도 있다. 여러 파일이 한 번에 바뀌면 변경 이유를 따라가는 것조차 쉽지 않다.
여기서 벽이 느껴진다.
실무에서는 속도와 효율이 중요하다. 회사는 결과를 만들어야 하고, 개발자는 주어진 일정 안에서 기능을 완성해야 한다. 그런데 AI가 속도와 효율을 크게 끌어올릴수록, 경험이 부족한 주니어는 그 기준을 바로 따라가기 어렵다.
단순히 "AI를 잘 쓰면 된다"로 해결되는 문제가 아니다.
AI를 잘 쓰기 위해서도 결국 문제를 이해하는 힘이 필요하다. 코드를 읽는 힘이 필요하다. 결과를 검증하는 힘이 필요하다. 그리고 이 힘은 단기간에 생기지 않는다.
그래서 주니어는 이런 질문을 하게 된다.
AI가 대부분의 코드를 작성하는 시대에, 나는 어떤 가치를 만들 수 있을까?
시니어와 같은 방식으로 AI를 쓰면 안 되는 이유
나는 주니어가 시니어와 같은 방식으로 에이전틱 코딩을 하려고 하면 오히려 더 위험해질 수 있다고 생각한다.
시니어는 큰 단위의 작업을 AI에게 맡길 수 있다. 이미 머릿속에 전체 구조가 있고, 변경 범위와 위험 지점을 어느 정도 예상할 수 있기 때문이다. AI가 여러 파일을 한 번에 수정해도 어떤 의도로 바뀌었는지, 무엇을 다시 확인해야 하는지 파악할 가능성이 높다.
하지만 주니어에게 같은 방식은 부담이 크다.
여러 파일이 한 번에 바뀌면 변경 흐름을 놓치기 쉽다. 코드가 동작하더라도 어떤 판단이 들어갔는지 이해하지 못할 수 있다. 모르는 기술 스택과 익숙하지 않은 코드 스타일이 섞이면, 어느 순간 AI가 만든 결과를 이해하기보다 그냥 받아들이게 된다.
이게 가장 위험하다고 생각한다.
AI를 활용했지만 내가 성장하지 못하는 상황이다. 결과물은 있는데 내 판단 기준은 남지 않는 상황이다.
그러면 다음에 비슷한 문제가 왔을 때 다시 AI에게 크게 맡기는 수밖에 없다. 문제를 해결한 것 같지만, 실제로는 문제를 이해하는 능력이 쌓이지 않은 것이다.
주니어에게 필요한 에이전틱 코딩 방식
내가 생각하는 주니어의 에이전틱 코딩은 병렬로 많이 만들기보다 작게 나누고 깊게 확인하기에 가깝다.
AI 도구는 여러 작업을 동시에 처리할 수 있다. 여러 에이전트에게 각각 다른 파일을 맡기고, 기능을 병렬로 구현하게 할 수도 있다. 숙련된 개발자에게는 이 방식이 큰 생산성으로 이어질 수 있다.
하지만 주니어에게는 항상 좋은 방식이 아닐 수 있다.
병렬로 많은 코드가 생성되면 검증해야 할 양도 같이 늘어난다. 이해하지 못한 변경이 쌓이면 나중에는 어디서 문제가 생겼는지 찾기 어려워진다. 특히 실무 코드베이스에서는 작은 변경 하나가 상태 관리, API 계약, UI 동작, 테스트, 배포 환경까지 영향을 줄 수 있다.
그리고 개발자는 영향을 줄 수 있는 부분들을 판단하고 검증을 해야한다. 그리고 주니어에게는 사실상 이러한 검증이 불가능에 가깝다.
그래서 주니어에게는 오히려 고전적인 분할-정복과 같이 작게 나누고 다시 병합하는 과정이 더 중요하다고 생각한다. 이 방식은 빠르지 않을 수 있다.
하지만 주니어에게는 이 느린 과정이 필요하다. AI가 코드를 대신 작성해 주는 시대일수록, 주니어는 코드 작성량보다 이해의 밀도를 높여야 한다. 내가 무엇을 바꿨는지, 왜 바꿨는지, 어떤 위험이 남았는지를 설명할 수 있어야 한다.
그렇지 않으면 AI가 만든 결과는 내 실력이 아니라 지나간 출력값에 가까워진다.
경험 기반으로 많이 시도하기
주니어에게는 경험의 양도 필요하다.
이론적으로 좋은 구조를 아는 것과 실제 코드베이스에서 그 구조를 적용하는 것은 다르다. 개인 프로젝트에서 잘 동작하던 방식이 실무에서는 맞지 않을 수 있고, 반대로 처음에는 이상해 보였던 회사의 코드 구조가 나름의 이유를 가지고 있을 수도 있다.
그래서 주니어는 많은 코드, 많은 스택, 많은 케이스를 직접 탐구해야 한다고 생각한다.
다만 여기서 중요한 것은 무작정 많이 만드는 것이 아니다. 하나를 만들더라도 다음 질문을 남겨야 한다.
왜 이 구조를 선택했는가?
다른 방식은 왜 선택하지 않았는가?
이 코드는 어떤 상황에서 깨질 수 있는가?
AI가 제안한 코드 중 내가 이해하지 못한 부분은 무엇인가?
다음에 같은 문제를 만나면 어떤 순서로 확인할 것인가?이런 질문이 남아야 경험이 쌓인다.
단순히 AI에게 기능을 만들게 하고, 동작하면 넘어가는 방식은 당장은 빠를 수 있다. 하지만 주니어에게 필요한 성장으로 이어지기는 어렵다. 결국 중요한 것은 많이 만드는 것이 아니라, 많이 판단해보는 것이다.
앞으로 지키고 싶은 기준
다시 취준 개발자로 돌아온 지금, 나는 앞으로의 성장을 조금 다르게 바라보려고 한다.
이전에는 더 많은 기술을 알고, 더 많은 기능을 만들어야 한다고 생각했다. 물론 지금도 필요하다. 하지만 이제는 그보다 먼저 내가 어떤 방식으로 문제를 바라보고 있는지 확인하고 싶다.
AI가 코드를 만들어 주는 시대에도 개발자의 판단은 사라지지 않는다. 오히려 더 중요해질 수 있다. 무엇을 만들지, 왜 그렇게 나눌지, 어떤 결과를 믿을지, 어디까지 검증할지를 결정하는 일은 여전히 개발자의 몫이기 때문이다.
주니어는 시니어처럼 많은 경험을 가지고 있지 않다.
하지만 그렇기 때문에 더 많이 질문할 수 있고, 더 작은 단위로 파고들 수 있고, 실패를 경험으로 바꾸는 훈련을 할 수 있다. AI가 개발의 기본 도구가 된 시대라면, 주니어에게 필요한 것은 AI를 무작정 빠르게 쓰는 능력이 아니라 AI와 함께 더 정확히 배우는 능력일지도 모른다.
앞으로 다시 개발자로 성장해 가는 과정에서 이 기준을 계속 확인해보려고 한다.
