6개월의 인턴을 마치고, 다시 기록을 시작하며

한동안 블로그에 글을 쓰지 못했다.

무신사에서 인턴으로 일하는 동안 새로운 환경과 업무에 적응하는 데 집중하다 보니, 출근 전과 퇴근 후에 공부한 내용을 정리하던 루틴도 자연스럽게 멈췄다.

블로그에 글을 쓰지 않았다고 해서 배우지 않은 것은 아니었다. 오히려 지난 6개월 동안 이전에는 알지 못했던 것들을 많이 보고 경험했다. 다만 하루하루 주어진 일을 잘 해내는 데 집중하다 보니, 그 경험을 내 언어로 정리할 여유가 없었다.

13명 남짓한 솔루션 회사에서 일하다가 국내에서 손꼽히는 패션 플랫폼인 무신사에서 일하게 되었을 때의 기대감이 아직도 기억난다. 특히 오프라인 스토어를 위한 시스템을 개발할 수 있다는 점과, 규모가 큰 회사에서는 일이 어떻게 진행되고 서비스가 어떻게 배포되는지를 가까이에서 배울 수 있다는 사실에 설렜다.

이번 글에서는 지난 6개월을 돌아보고, 그 시간 동안 무엇을 배웠으며 앞으로 무엇을 채워나갈지 정리해보려 한다.

결과를 마주하고

인턴 전환에 도전했지만 결과는 아쉽게도 탈락이었다.

매니저님과의 1 on 1에서 앞으로 함께하지 못하게 되었다는 이야기를 들었을 때는 잠시 멍해졌고 눈물이 핑 돌았다. 내가 부족했던 순간들이 먼저 떠올랐고, 그동안 들인 노력까지 모두 부정당한 것처럼 느껴지기도 했다.

결과를 들은 다음 날 바로 퇴사 절차를 진행해야 했다. 아쉬움을 충분히 정리할 시간도 없이 익숙해진 환경을 떠나야 한다는 사실과, 이제 서울에서 어떻게 해야 할지에 대한 막막함이 한꺼번에 밀려왔다.

조금 더 깊이 고민해볼걸, 배운 내용을 더 잘 기록해둘걸, 주어진 범위를 넘어 더 적극적으로 움직여볼걸 하는 아쉬움도 남았다.

하지만 조금 거리를 두고 지난 시간을 돌아보니, 전환 여부와 내가 그곳에서 배우고 경험한 것들은 서로 다른 문제라는 생각이 들었다. 결과가 기대와 달랐다고 해서 내가 했던 고민과 시도, 선배들에게 배운 것까지 사라지는 것은 아니었다.

지금 필요한 것은 결과 하나로 지난 경험 전체를 평가하는 일이 아니라, 그 안에서 내가 잘했던 것과 부족했던 것을 구체적으로 바라보는 일이었다.

AI Native 환경에서 달라진 개발자의 역할

개발자로 일하는 모습을 상상할 때는 직접 코드를 작성해 문제를 해결하고, 동료들과 코드를 주고받으며 리뷰하는 장면을 떠올렸다. 어려운 문제를 코드로 풀어내고 더 나은 구현을 고민하는 과정이 개발자로 일하는 가장 큰 재미라고 생각했다.

무신사에 입사한 뒤 Claude Max를 사용하며 처음으로 충분한 사용 한도를 가진 AI 에이전트와 업무 전반을 함께했다. 이전에도 Gemini Pro와 Claude Pro를 사용했지만, 사용량을 크게 의식하지 않고 실제 서비스의 코드를 AI와 함께 작성한 것은 처음이었다.

간단한 주석을 수정하는 경우를 제외하면 대부분의 구현 과정에서 AI의 도움을 받았다. 처음에는 실제 사용자가 이용하는 서비스의 코드를 AI에 이 정도까지 맡겨도 되는지 의심했다. 하지만 한 달, 두 달 함께 일하면서 반복적인 구현에 대한 신뢰는 점차 높아졌다. 계산기를 사용할 때 내부의 모든 계산 과정을 매번 확인하지 않는 것처럼, 구현을 AI에 맡기는 일이 점점 자연스러워졌다.

동시에 혼란도 있었다. 내가 기대했던 코드 리뷰와 달리 AI가 만든 많은 양의 코드를 AI가 먼저 리뷰하고, 그 피드백을 다시 AI가 반영하는 방식도 경험했다. 선배들과 이야기를 나눠보니 AI가 구현의 많은 부분을 대신하면서 직접 문제를 풀고 코드를 다듬는 재미가 예전보다 줄었다는 의견도 있었다. 나 역시 개발자로서 기대했던 재미가 달라지고 있다는 아쉬움을 느꼈다.

그럼에도 실제 업무는 이전보다 빠르게 진행되었고, 구현 자체가 프로젝트의 가장 큰 병목이 되는 일도 줄어들었다. 그 과정에서 AI Native는 단순히 코드를 더 빠르게 작성하는 방식이 아니라, 개발자가 집중해야 할 영역이 달라지는 변화라는 생각이 들었다.

AI가 만든 결과물을 검증하지 않게 된 것은 아니었다. 오히려 코드 한 줄 한 줄보다 데이터 모델이 적절한지, 애플리케이션 사이에서 데이터가 어떻게 흐르는지, 클래스와 패키지의 책임이 올바르게 나뉘었는지를 먼저 확인하게 되었다. 코드의 규모가 클 때는 AI에게 각 클래스의 역할과 관계를 HTML이나 Markdown으로 정리하도록 한 뒤 전체 구조를 파악하고, 중요한 로직과 테스트, 예외 상황을 중심으로 코드를 살펴보았다. 구현 전에 작성한 설계 문서를 AI와 검토하고, 그 설계를 바탕으로 구현과 리뷰를 이어가는 방식도 새로웠다.

AI가 산출물을 빠르게 만들어준다고 해서 그 결과에 대한 책임까지 가져가는 것은 아니다. 어떤 문제를 풀 것인지 정의하고, AI에 충분한 맥락을 제공하며, 만들어진 결과가 요구사항과 설계에 맞는지 검증하는 책임은 결국 개발자에게 남는다. 이제는 모든 코드를 직접 작성하는 능력만큼 AI와 함께 빠르게 결과물을 만들고, 그 결과를 설명하고 검증할 수 있는 능력이 중요하다고 느꼈다.

AI의 도움으로 구현 비용이 낮아지는 시대일수록 개발자는 CS 지식을 바탕으로 올바른 구조를 설계하고 업무의 맥락을 정확하게 이해해야 한다. 또한 이해한 내용을 관계자들과 공유하고 정리하며 일을 앞으로 움직이는 능력이 더욱 중요해진다. 이것이 이번 인턴 생활에서 경험한 AI Native의 모습이었고, 앞으로 개발자로서 계속 고민해야 할 새로운 일의 방식이라고 생각한다.

구현을 넘어 일을 앞으로 움직이는 것

인턴으로 일하며 가장 크게 배운 것은 개발자의 역할이 주어진 요구사항을 코드로 구현하는 데서 끝나지 않는다는 점이었다.

이전에는 기획 문서가 주어지면 그 내용을 정확하게 구현하는 것이 개발자의 주된 역할이라고 생각했다. 하지만 여러 팀이 함께 움직이는 환경에서는 문서만으로 모든 내용이 명확해지지 않았다. 담당자가 바뀌기도 하고, 프로젝트가 진행되는 도중 요구사항과 일정이 달라지기도 했다.

이런 상황에서는 누군가 정답을 정리해주기를 기다리기보다 필요한 사람들과 직접 소통하며 불확실한 부분을 하나씩 줄여나가야 했다.

처음으로 여러 팀과 함께한 프로젝트

영수증의 QR 코드를 통해 참여하는 이벤트 기능을 개발하며 처음으로 다른 팀의 PM과 개발자들과 직접 스펙을 맞춰보았다.

해당 프로젝트는 기존 담당자가 퇴사한 뒤 내가 인계받게 되었다. 처음에는 전달받은 문서를 바탕으로 개발만 마치면 된다고 생각했다. 하지만 일을 진행할수록 문서만으로는 명확하지 않은 부분과 추가로 결정해야 할 내용들이 보이기 시작했다.

돌이켜보면 프로젝트 초반에는 내가 맡은 기능을 완성하는 데만 집중했고, 프로젝트 전체를 바라보는 오너십은 부족했다. 이후 관계자들과 다시 소통하며 필요한 부분을 수정하고 QA를 지원했다. 정신없이 움직인 끝에 예정된 일정에 맞춰 프로젝트를 마칠 수 있었다.

이 경험을 통해 명확한 소통은 단순히 질문에 답을 받는 일이 아니라는 것을 배웠다. 서로 다르게 이해하고 있는 부분을 먼저 발견하고, 결정이 필요한 내용을 구체적인 질문으로 바꾸어 적절한 사람에게 전달하는 것까지가 나의 일이었다.

여러 시스템이 맞물린 불확실성 속에서

다음으로 맡은 일은 재고 시스템에 큰 변화가 생기는 과정에서 오프라인 매장 시스템에 새로운 재고 관련 기능을 개발하는 프로젝트였다.

판매 가능한 재고를 계산하는 시스템부터 물류와 상품 정보를 다루는 시스템까지 여러 팀의 작업이 맞물려 있었다. 프로젝트가 진행되는 동안 새로운 시스템과 조회 계층이 추가되었고, 각 시스템이 어떤 정보를 책임질지도 계속 조정되었다. 실제로 재고 수치는 한 시스템에서, SKU 이름과 같은 정보는 별도의 조회 계층에서 제공한다는 구분도 프로젝트 막바지에 이르러서야 구체화되었다.

데이터의 출처와 시스템 간 책임이 정해지지 않은 상태에서 오프라인 매장 시스템만 독립적으로 개발을 진행하기는 어려웠다. 그동안 손을 놓고 있었던 것은 아니다. 기존 코드를 분석해 위키에 정리하고 문서와 PRD를 살펴보며 준비했으며, 매니저님께 상황을 공유하고 도움을 요청하기도 했다. 이후 관련 팀들의 방향과 시스템 간 경계가 정리되면서 전체적인 그림이 보이기 시작했고, 그때부터 본격적으로 개발을 진행할 수 있었다.

다만 지금 다시 그때로 돌아간다면 분석하고 이해한 내용을 개인적인 문서에 정리하는 데서 그치지는 않을 것이다. 당시까지 확인된 내용과 아직 결정되지 않은 부분, 다른 시스템에 의존하는 지점을 한눈에 볼 수 있도록 정리해 관계자들에게 먼저 공유했을 것 같다. 또한 확정되지 않은 부분은 가정을 세워 화면이나 동작 흐름을 간단한 목업으로 만들고, 구체적인 선택지를 바탕으로 PM과 개발자들과 더 적극적으로 스펙을 맞춰나갔을 것이다.

여러 시스템의 방향을 내가 결정하거나 모든 문제를 해결할 수 있었던 것은 아니다. 하지만 복잡한 상황을 정리해 불확실성을 밖으로 드러내고, 관계자들이 판단할 수 있는 재료를 먼저 만드는 일은 충분히 가능했다.

이 경험을 통해 오너십은 모든 일을 혼자 책임지는 태도가 아니라, 일이 멈춰 있는 이유를 찾고 다음 단계로 나아가기 위해 내가 할 수 있는 행동을 먼저 시도하는 태도라는 것을 배웠다.

선배들에게 배운 협업 방식

여러 팀이 참여하는 회의에서 함께 개발한 시니어 개발자가 소통하는 모습을 보며 많이 배웠다.

회의에서 무엇을 결정해야 하는지 분명하게 짚고, 알고 있는 것과 모르는 것을 구분해서 이야기했다. 당장 답할 수 없는 내용은 솔직하게 모른다고 말한 뒤 확인해서 다시 공유했다. 회의가 끝날 때는 논의된 내용과 아직 결정되지 않은 부분, 각자가 해야 할 액션 아이템을 명확하게 나누었다.

전에는 일을 잘한다는 것을 주로 기술적인 문제를 빠르게 해결하는 능력으로 생각했다. 하지만 이번 경험을 통해 여러 사람이 같은 방향을 바라보도록 만들고, 복잡한 논의 속에서 다음 행동을 명확하게 정리하는 능력 역시 개발자에게 중요한 역량이라는 것을 알게 되었다.

기술적으로도 멱등성, 메시지 유실을 방지하기 위한 아웃박스 패턴, 쿼리 개선을 통한 성능 최적화, 모니터링 도구를 활용해 운영 상황을 살펴보는 방법 등을 경험했다. 아직 완전히 내 것으로 만들었다고 말하기에는 부족하기에, 이 내용들은 다시 공부하며 하나씩 별도의 글로 정리해볼 생각이다.

다시 기록하려는 이유

예전부터 블로그는 공부한 내용을 복습하고 내 것으로 만들기 위한 공간이었다. 글을 쓰기 위해 내용을 다시 확인하고, 다른 사람이 읽을 수 있는 문장으로 정리하는 과정에서 내가 무엇을 알고 무엇을 모르는지 확인할 수 있었다.

이번 경험도 마찬가지라고 생각한다. 기록하지 않으면 아쉬운 결과만 기억에 남고, 그 과정에서 얻은 배움은 점차 흐려질 것 같았다.

그래서 잠시 멈춰 있던 블로그를 다시 시작해보려 한다. 누군가에게 내가 열심히 살았다는 것을 증명하기 위해서라기보다, 이번 경험에서 얻은 것들을 내 것으로 남기고 다음 경험을 더 잘 맞이하기 위해서다.

당분간은 인턴 기간 동안 달라진 생각과 기술적으로 공부한 내용을 하나씩 정리할 예정이다. 회사의 내부 이야기가 아니라, 한 명의 주니어 개발자로서 무엇을 보고 배웠고 어떤 점이 부족했는지를 기록해보려고 한다.

이번 인턴 생활은 내가 부족하다는 사실만 확인한 시간이 아니었다. 앞으로 어떤 방식으로 일하는 개발자가 되어야 하는지 구체적으로 알게 된 시간이었다.

결과는 아쉬웠지만, 이 경험까지 아쉬운 기억으로만 남기고 싶지는 않다.

다시 천천히 기록해보자. 화이팅!!!