AI 시대, 개발자는 어떻게 일해야 할까 — 테오의 스프린트 후기

최근 테오의 스프린트에 참여했다.

사진을 많이 찍지는 못했지만, 장소는 지난해 말 참여했던 테오콘과 같은 앨리스 성수였다. 같은 장소를 다시 방문하니 자연스럽게 당시의 기억도 떠올랐다.

이번 스프린트에 참여하면서 거창하게 기대한 것은 없었다. 현재의 프론트엔드 개발자들은 어떻게 움직이고 있는지, 그리고 AI가 IT 업계와 개발자의 일하는 방식에 어떤 영향을 주고 있는지를 직접 확인해보고 싶었다.

지인 몇 명에게도 함께 가자고 권유했지만, 모두 회사 업무가 바빠 참여하지 못했다. 결국 나와 여자친구가 함께 스프린트에 참석했다.

이전과는 달라진 업계의 분위기

테오는 강연할 때마다 욕심이 많다.

짧은 시간 안에 참가자들에게 최대한 많은 것을 전달하려고 한다. 그 과정에서 나오는 테오의 외침과 에너지는 항상 사람들의 마음을 움직인다.

하지만 이번 스프린트에서 만난 테오는 지난 테오콘 때와는 조금 다른 위치에 서 있는 것처럼 보였다.

이제는 AI가 사람보다 코드를 훨씬 잘 구성하는 시대가 와버렸다.

테오가 던진 이 문장은 현재 개발자들이 마주하고 있는 변화를 압축해서 보여주는 말처럼 느껴졌다.

물론 테오콘과 테오의 스프린트를 단순히 비교하기는 어렵다. 테오콘은 컨퍼런스의 성격이 강하고, 스프린트는 제한된 시간 안에 아이디어를 검증하고 결과물을 만들어보는 체험형 프로그램에 가깝기 때문이다.

그 차이를 고려하더라도 이번 행사에는 내가 예상했던 것보다 사람이 적었다.

이것은 테오의 스프린트가 유익하지 않았다는 의미가 아니다. 다만 강의실 문을 열었을 때, 이전과는 달라진 IT 업계의 분위기와 좁아진 취업 시장을 개인적으로 체감했다.

첫째 날: 아이디어를 검증하고 팀을 구성하다

행사장에는 조금 늦게 도착했다.

마을버스가 있다는 사실을 몰라 한참을 걸었고, 땀을 뻘뻘 흘린 채 도착했다. 다행히 아직 프로그램 초반이어서 참가자들이 간단하게 자신을 소개하고, 스프린트에서 무엇을 진행하는지 설명을 듣고 있었다.

첫날의 진행 방식은 대학교에서 들었던 기획 수업과 어느 정도 비슷했다.

이 자리는 개발자만 모인 행사가 아니었다. 디자이너와 기획자, 현업 종사자, 앞으로 IT 업계에서 일하고 싶은 사람들이 함께 참여했다.

따라서 개발 기술 자체를 전문적으로 다루기보다는 좋은 프로덕트를 어떻게 발견하고, 아이디어를 어떻게 검증하며, 실제 결과물로 어떻게 발전시킬 것인지에 초점이 맞춰져 있었다.

참가자들은 자신이 생각한 아이디어를 AI와 함께 간단하게 정리하고 검증한 뒤, 다른 사람들 앞에서 짧은 기획 발표를 진행했다.

내가 제안한 아이디어도 마지막 여섯 개 후보 안에 들었다. 하지만 함께 개발해보겠다는 사람이 나오지 않아 최종 프로젝트로 선정되지는 못했다.

아쉬움은 있었지만 아이디어 자체를 포기한 것은 아니다. 이번에 선택받지 못한 아이디어는 이후에 직접 프로덕트로 만들어볼 생각이다.

아이디어 검증이 끝난 뒤에는 팀을 구성하고 자기소개를 했다.

우리 팀은 백엔드 개발자 한 명과 나를 포함한 프론트엔드 개발자 네 명으로 구성됐다. 같은 프론트엔드 개발자라고 하더라도 각자가 경험한 분야와 경력은 조금씩 달랐다.

아이디어를 제안한 러너 님이 자연스럽게 팀의 리더이자 진행자 역할을 맡았다. 백엔드 개발자를 제외한 나머지 팀원들은 각자 잘할 수 있는 프론트엔드 영역을 중심으로 개발에 참여했다.

첫날을 마치고 나서 한 가지 아쉬움이 남았다.

테오는 AI 시대의 역할을 프로토타이퍼, 빌더, 스위퍼, 그로퍼, 메인테이너라는 다섯 가지 직무로 설명했다. 하지만 우리 팀은 이 역할에 맞춰 업무를 나누지 못했다.

우리에게는 그런 방식으로 협업해본 경험이 없었고, 현장에서 반드시 다섯 가지 역할로 나누라는 지시도 없었다. 결국 평소 회사에서 일하던 것처럼 백엔드, 프론트엔드, 디자인, 기획이라는 익숙한 기준으로 역할을 구분했다.

행사가 끝난 뒤에야 새로운 협업 방식을 실험할 기회를 충분히 활용하지 못했다는 사실을 깨달았다.

둘째 날: AI와 함께 ‘장금이’를 구체화하다

둘째 날에는 늦지 않게 도착했다.

커피를 한잔 마시며 팀원들과 이야기를 나눈 뒤 본격적으로 프로젝트를 발전시키기 시작했다. 어떤 사람들이 서비스를 사용할지, UI와 UX는 어떻게 구성할지, 서비스의 전체적인 콘셉트는 무엇인지 하나씩 정리했다.

우리 팀의 프로젝트 이름은 장금이였다.

장금이는 자취생이나 초보 주부처럼 식자재 관리와 냉장고 정리에 어려움을 겪는 사람들을 위한 서비스였다. 단순히 냉장고에 무엇이 들어 있는지 기록하는 데 그치지 않고, 식자재를 어떻게 구매하고 보관하며 소비할 것인지 도와주는 플랫폼을 목표로 했다.

우리는 서비스의 목적과 타깃, 핵심 가치, 고객 로드맵을 정리했다. 사용자가 겪는 페인 포인트와 서비스를 통해 느끼게 될 와우 포인트를 정의하고, 관련 키워드를 워드클라우드 형태로 정리했다.

모든 프로덕트는 고객을 직접 만나 문제를 검증하고, 작은 단위로 빠르게 발전시키는 과정이 중요하다.

다만 이번 스프린트에서 우리 팀이 가장 중요하게 생각한 것은 완성도 높은 MVP를 만드는 것만은 아니었다. AI를 활용해 팀 내부의 업무 속도와 커뮤니케이션 효율을 얼마나 높일 수 있는지 실험하는 것도 중요한 목표였다.

사람들의 의견을 수집한 뒤에는 AI를 활용해 초기 화면을 스케치했다.

각자가 떠올린 아이디어도 먼저 AI를 통해 정리했다. 정돈된 내용을 바탕으로 필요한 페이지를 나누고, 팀원들이 자신이 맡고 싶은 화면을 선택해 작업했다.

이 과정에서 AI는 결과물을 대신 만들어주는 도구라기보다, 흩어진 생각을 정돈하고 빠르게 초안을 만드는 도구에 가까웠다.

아이디어를 말로만 주고받을 때보다 짧은 시간 안에 구체적인 화면과 문장으로 확인할 수 있다는 점은 분명히 효율적이었다.

하지만 이 시점부터 우리 팀 안에는 보이지 않는 갈등 아닌 갈등도 생겼다.

각자가 생각하는 서비스의 모습이 조금씩 달랐고, 자신의 아이디어를 이야기하는 데 집중하다 보니 여러 의견이 하나의 방향으로 잘 모이지 않는 느낌이 들었다.

러너 님이 중간중간 의견을 정리해주었지만, 팀 대부분이 개발자이고 전문 기획자나 디자이너가 없는 상태에서 서비스의 방향과 화면을 동시에 결정하는 것은 쉽지 않았다.

각자 직장과 개인 업무가 있는 상황에서 참여한 프로젝트였기 때문에 모든 사람이 서비스에 깊이 몰입하기도 어려웠다.

그럼에도 우리는 이번 프로젝트의 중요한 기준을 놓치지 않으려고 했다.

완벽한 서비스를 만드는 것보다, AI를 어떻게 하면 기존 업무보다 더 깊고 효율적으로 활용할 수 있는지 실험하는 것이었다.

셋째 날: 결과물을 발표하고 서로의 차이를 확인하다

마지막 날에는 지금까지 만든 프로젝트를 정리하고 발표하는 시간을 가졌다.

각 팀은 제한된 시간 동안 발전시킨 아이디어와 결과물을 소개했고, 그중 한 팀을 선정해 앨리스랩에서 준비한 상품을 전달했다.

1등은 ‘관계도감’ 프로젝트가 차지했다.

관계도감은 누가 보더라도 디자인의 완성도가 높았고, 아이디어를 실제 화면으로 표현한 구현력도 상당히 뛰어났다. 짧은 시간 동안 만들어진 결과물이라는 점을 고려하면 더욱 인상적이었다.

우리 팀의 결과물도 나쁘지 않았다고 생각한다.

다만 냉장고와 식자재를 다루는 서비스임에도 사용자의 개인 정보와 실제 냉장고 상태를 반영하는 개인화 요소가 상대적으로 부족했다.

사용자마다 보유한 식자재와 소비 습관이 다른데, 이 차이를 결과물에 충분히 표현하지 못한 점이 최종 평가에서 약점으로 작용하지 않았을까 생각한다.

발표를 보면서 단순히 디자인이나 개발 속도의 차이만 확인한 것은 아니었다.

같은 시간과 비슷한 도구가 주어지더라도, 팀이 하나의 문제를 얼마나 명확하게 정의했는지에 따라 결과물의 밀도가 크게 달라진다는 점을 느꼈다.

AI가 작업 속도를 높여주더라도 팀의 방향까지 자동으로 정리해주는 것은 아니었다.

스프린트를 통해 얻은 것

이번 스프린트에 참여하기 전에는 AI가 개발자의 코드를 얼마나 대신 작성할 수 있는지가 가장 궁금했다.

하지만 행사가 끝난 뒤에는 질문이 조금 달라졌다.

앞으로 중요한 것은 AI가 코드를 얼마나 잘 작성하느냐보다, 사람이 AI를 활용해 문제를 얼마나 구체적으로 정의하고 팀의 생각을 얼마나 빠르게 정렬할 수 있느냐에 가까울지도 모른다.

AI는 분명히 초안을 만드는 속도를 높여준다. 아이디어를 정리하고, 문장을 다듬고, 초기 화면을 구성하는 데에도 도움이 된다.

하지만 서로 다른 사람의 생각을 하나로 모으고, 어떤 기능을 포기할지 결정하며, 우리가 해결하려는 문제가 무엇인지 합의하는 일은 여전히 사람의 몫이었다.

우리 팀이 겪었던 작은 혼란도 AI를 잘 사용하지 못해서 발생한 문제라기보다, AI를 사용하기 전에 팀의 기준을 충분히 맞추지 못했기 때문에 생긴 문제에 가까웠다.

다시 참여하게 된다면 개발에 들어가기 전에 다음 세 가지부터 명확하게 정해보고 싶다.

첫 번째는 우리가 해결하려는 문제를 한 문장으로 합의하는 것이다.

두 번째는 AI 시대의 역할에 맞게 팀원의 업무를 새롭게 나누는 것이다.

세 번째는 각각의 AI 결과물을 누가 검토하고, 어떤 기준으로 하나의 결과물에 반영할지 결정하는 것이다.

이번 경험을 통해 다른 회사와 다른 직군의 사람들이 어떤 방식으로 의견을 나누고 일하는지도 확인할 수 있었다.

현재 회사에서도 기획 내용을 정리하거나 화면 구조를 검토할 때 바로 개발부터 시작하기보다, 먼저 문제와 목표를 문장으로 정리하려고 노력하고 있다.

AI에게도 막연하게 결과물을 만들어달라고 요청하기보다 현재 상황과 해결해야 할 문제, 결과물의 기준을 구체적으로 전달하려고 한다.

스프린트에서 배운 방식이 완전히 새로운 업무 프로세스로 자리 잡은 것은 아니다. 하지만 이전보다 AI를 단순한 코드 생성 도구가 아니라, 생각을 구조화하고 팀의 논의를 빠르게 시각화하는 도구로 바라보게 됐다.

프론트엔드 4년 차로서 받아들인 변화

프론트엔드 개발자로 일한 지 4년 정도 된 시점에서 이번 스프린트의 경험은 조금 복잡하게 다가왔다.

처음 개발을 시작했을 때는 HTML과 CSS, JavaScript를 얼마나 잘 다루는지, 프레임워크의 사용법을 얼마나 깊이 이해하는지가 개발자의 주요 경쟁력이라고 생각했다.

실제 업무에서도 요구사항에 맞는 화면을 빠르게 구현하고, 상태를 관리하고, 발생한 오류를 해결하는 능력이 중요했다. 지금까지 나 역시 이런 구현 능력을 높이기 위해 많은 시간을 사용했다.

하지만 이제 AI는 컴포넌트의 초안을 만들고, 타입을 정의하고, API 연동 코드를 작성하며, 테스트 코드까지 만들어준다.

과거에는 개발자가 직접 검색하고 여러 번의 시행착오를 거쳐야 했던 작업들이 훨씬 짧은 시간 안에 완성되기도 한다.

테오가 말한 “AI가 사람보다 코드를 훨씬 잘 구성하는 시대”라는 문장이 가볍게 들리지 않았던 이유도 여기에 있었다.

그렇다고 이 말을 개발자가 더 이상 필요하지 않다는 의미로 받아들이지는 않았다.

AI는 요구사항이 명확하고 작업 범위가 제한적일수록 빠르고 그럴듯한 결과물을 만들어낸다. 하지만 어떤 기능이 정말 필요한지, 현재 프로젝트 구조에 적합한 방식인지, 이후 유지보수 과정에서 어떤 문제가 발생할지는 여전히 개발자가 판단해야 한다.

특히 프론트엔드 개발은 단순히 화면에 컴포넌트를 배치하는 일만은 아니다.

사용자가 어떤 흐름으로 서비스를 이용할지 이해해야 하고, 기획과 디자인의 의도를 실제 인터페이스로 옮겨야 한다. 백엔드와 데이터를 주고받는 방식뿐만 아니라 성능과 접근성, 예외 상황, 브라우저 환경, 기존 코드와의 일관성도 함께 고려해야 한다.

이번 스프린트에서도 AI를 활용하면 각자의 아이디어를 빠르게 정리하고 화면으로 표현할 수 있었다. 하지만 팀원들이 서로 다른 방향을 바라보고 있을 때 AI가 그 차이까지 해결해주지는 못했다.

오히려 공통된 기준이 없는 상황에서 각자가 AI를 사용하면, 서로 다른 방향의 결과물이 더 빠르게 쌓일 수도 있다는 사실을 확인했다.

결국 AI가 코드 작성 속도를 높여줄수록 개발자가 해야 하는 일이 사라지는 것이 아니라, 개발자에게 요구되는 역할이 조금씩 달라지는 것에 가까웠다.

코드를 직접 작성하는 능력뿐만 아니라 문제를 정의하고, AI가 만든 결과물을 검토하고, 여러 선택지 중 프로젝트에 적합한 방식을 결정하는 능력이 더욱 중요해질 것이라고 느꼈다.

프론트엔드 4년 차인 내가 앞으로 중요하게 가져가야 할 역량도 조금 선명해졌다.

첫 번째는 문제를 구체적으로 정의하는 능력이다.

AI에게 화면이나 코드를 만들어달라고 요청하기 전에 누구의 어떤 문제를 해결하려는지 설명할 수 있어야 한다. 해결하려는 문제가 불분명하면 AI가 만든 결과물 역시 겉으로만 그럴듯한 기능에 머무를 가능성이 크다.

두 번째는 AI가 만든 코드를 검토하는 능력이다.

코드가 실행된다는 이유만으로 바로 사용할 수는 없다. 현재 프로젝트 구조와 맞는지, 불필요하게 복잡하지 않은지, 중복된 로직은 없는지, 예외 상황을 제대로 처리하는지 판단해야 한다.

이를 위해서는 오히려 JavaScript와 브라우저, 렌더링 과정, 네트워크, 상태 관리와 같은 기본 원리를 이전보다 더 정확하게 이해해야 한다고 생각한다.

기본기를 모르면 AI가 만든 코드가 왜 잘못됐는지조차 발견하기 어렵기 때문이다.

세 번째는 팀의 기준을 만드는 능력이다.

프로젝트 구조와 컴포넌트 설계 방식, 상태 관리, 네이밍, 테스트 범위에 대한 기준이 명확해야 AI가 생성한 결과물도 하나의 코드베이스 안에서 일관성을 가질 수 있다.

AI를 사용하는 사람이 많아질수록 코드가 만들어지는 속도는 빨라진다. 하지만 팀의 기준이 없다면 중복 코드와 서로 다른 구현 방식 역시 더 빠르게 늘어날 수 있다.

앞으로는 코드를 얼마나 많이 만들어내는가보다 어떤 코드를 받아들이고, 수정하고, 버릴 것인지 판단하는 능력이 더 중요해질 수 있다.

네 번째는 다른 사람의 생각을 하나의 방향으로 모으는 능력이다.

이번 스프린트에서 가장 어려웠던 부분도 개발 그 자체보다는 여러 사람의 아이디어를 하나의 방향으로 정리하는 일이었다.

현업에서는 기획자와 디자이너, 백엔드 개발자, 운영 담당자가 서로 다른 관점으로 서비스를 바라본다. AI가 작업을 빠르게 만들어줄수록 무엇을 만들 것인지 합의하는 과정의 중요성은 오히려 더 커질 것이다.

4년 차는 단순히 코드를 작성하는 방법을 배우는 단계에서는 어느 정도 벗어났지만, 모든 기술적 판단을 자신 있게 내릴 수 있는 단계라고 말하기도 어렵다.

그래서 AI의 발전이 전혀 부담스럽지 않다고 할 수는 없다. 여러 해 동안 익혀온 구현 능력의 일부를 AI가 빠르게 대신하는 모습을 보면 앞으로 어떤 경쟁력을 가져야 할지 고민하게 된다.

하지만 반대로 생각하면 그동안 반복적인 구현에 사용했던 시간을 더 중요한 문제에 사용할 수 있는 기회이기도 하다.

화면을 하나 더 빠르게 만드는 것에서 그치지 않고, 사용자가 왜 이 기능을 필요로 하는지 고민할 수 있다. 프로젝트의 구조적인 문제를 발견하거나, 팀이 반복해서 겪는 비효율을 개선하는 데 더 많은 시간을 쓸 수도 있다.

결국 내가 받아들인 AI 시대의 프론트엔드 개발자는 코드를 작성하지 않는 사람이 아니다.

AI가 만든 결과물을 이해하고 검증할 수 있을 만큼 기술적인 기본기를 갖추면서, 문제와 사용자를 이해하고 팀이 올바른 방향으로 움직일 수 있도록 기준을 만드는 사람에 가깝다.

앞으로도 코드를 직접 작성하는 연습은 계속할 생각이다.

다만 코드 작성 자체를 최종 목표로 두기보다는, 좋은 프로덕트를 만들기 위한 여러 수단 중 하나로 바라보려고 한다.

이번 스프린트는 AI를 얼마나 많이 사용했는지를 확인하는 자리가 아니라, AI를 사용하는 개발자에게 어떤 능력이 더 필요해질지를 생각해보는 자리였다.

함께한 사람들에게

짧은 시간이었지만 함께 장금이를 만들어준 팀원들에게 감사하다.

각자 다른 경험과 생각을 가지고 있었기 때문에 의견을 하나로 모으는 과정이 항상 매끄럽지는 않았다. 하지만 그 차이 덕분에 혼자 작업했다면 발견하지 못했을 문제와 가능성을 확인할 수 있었다.

팀의 여러 의견을 계속해서 정리하고 방향을 잡아준 러너 님에게도 감사하다.

그리고 많은 사람이 AI와 새로운 협업 방식을 직접 실험할 수 있는 자리를 마련해준 테오에게도 감사하다는 말을 전하고 싶다.

테오는 이번에도 짧은 시간 안에 정말 많은 것을 전달하려고 했다. 그 모든 내용을 완전히 이해하거나 우리 팀의 방식에 적용하지는 못했지만, 적어도 한 가지 질문은 확실하게 가지고 돌아왔다.

AI가 코드를 작성하는 시대에 나는 어떤 프론트엔드 개발자로 일해야 할까?

아직 명확한 답을 내리지는 못했다.

다만 코드를 빠르게 작성하는 능력만으로는 충분하지 않을 수 있다는 점은 알게 됐다.

문제를 발견하고, 사용자의 상황을 이해하고, 여러 사람의 생각을 연결해야 한다. 동시에 AI가 만든 결과물을 검증하고, 프로젝트가 올바른 방향으로 움직일 수 있도록 기준을 제시할 수 있어야 한다.

프론트엔드 4년 차인 지금, AI를 경쟁 상대로만 바라보기보다는 내가 더 넓은 문제를 해결할 수 있도록 도와주는 도구로 받아들이려고 한다.

이번 테오의 스프린트는 AI가 바꾸고 있는 개발 환경을 직접 확인하고, 앞으로 어떤 개발자로 성장해야 할지 고민해볼 수 있었던 시간이었다.