이번에 알게된 지인분이 카톡을 보내왔다.
이전에 같이 일했던 개발자분이 세미나를 많이 다녀오시기도 했고, 새싹에서 팀을 했던 분도 컨퍼런스 스태프로도 다녀오셔서
나도 개발자 행사에 관심을 가지고 있던 찰나에,
참여형 세미나라고 해서 긴장을 좀했지만 바로 신청을했다.
요즘 개발자에게 AI란 프로젝트 처음부터 끝까지 함께하는 동반자이자, 어쩌면 경쟁자이다.
프론트엔드 개발자가 되고싶었는데 프론트단은 AI가 거의 완전히 대체될 수 있다고 하지말라는 말을 들어서 고민하던 차에
다른 사람들의 생각도 듣고싶어졌다.
선착순이라고 했는데 신청한 지 몇시간 채 지나지 않아 연락이 왔다.
문자로 온 사전 질문들을 노션에 정리해갔다.
사전발제
Q.지난 1년을 돌아 봤을 때 1년뒤, 그리고 3년뒤 우리는 어떻게 일하고 있을까요 ?
3년 뒤에는 단순한 기능 구현이나 반복적인 코드 작성은 AI가 완벽하게 대체한다고 봐도 무방할 것입니다.이에 따라 개발자의 주된 업무는 코드를 직접 타이핑하는 것에서 점차 벗어나게 될 것입니다. 대신 비즈니스 요구사항을 정확히 분석하고, AI가 생성한 코드 블록들을 유기적으로 조립하여 최적의 시스템 아키텍처와 사용자 경험을 '기획하고 설계'하는 방향으로 업무의 무게중심이 이동할 것이라 생각합니다.
Q.지난 한 달, 코딩 작업 중, AI에게 위임한 비중(%)과 그 결과물을 직접 검증한 비율(%)은 각각 얼마나 되었나요 ?
전체 코딩 작업의 약 75%를 AI에게 위임했습니다. 주로 단순한 웹 구조 퍼블리싱이나, 복잡한 전처리 과정이 필요 없는 기본적인 CRUD 데이터 로직 등 패턴이 정형화된 작업들을 AI에게 맡겼습니다.
결과물 검증에 있어서는 다중 AI를 활용해 교차 검증(Cross-validation)을 했습니다.구체적으로는 일차적인 구동 테스트 후, Claude가 작성한 1차 코드를 Gemini와 ChatGPT 양쪽 모두에게 전달하여 코드 리뷰를 요청했습니다. 두 AI의 리뷰 의견이 일치할 경우에만 코드를 수정했으며, 의견이 엇갈릴 경우 두 AI의 의견이 합치될 때까지 지속해서 교차 검증을 진행했습니다.
Q. ‘코드를 짜는 사람’이 아니라 ‘설계를 결정하는 사람’이 되기 위해 키워야 할 능력은 무엇이라고 생각되나요?
가장 기본적이고 필수적인 역량은 '탄탄한 기본기'입니다. AI가 내놓은 결과물을 비판적으로 이해하고, 필요하다면 본인이 직접 코드를 작성할 수 있는 수준의 기본기가 갖춰져 있다는 가정하에서만 올바른 설계가 출발할 수 있기 때문입니다. 이 기본기를 바탕으로 다음 두 가지 능력을 키워야 한다고 생각합니다.
첫째로 전체 시스템을 아우르는 시야입니다. 단순히 눈에 보이는 UI 컴포넌트를 넘어, 클라이언트에서 서버와 데이터베이스까지 데이터가 어떻게 흘러가는지 전체적인 구조를 이해해야 최적의 아키텍처를 결정할 수 있습니다.
둘째로, 트레이드오프(Trade-off) 판단력입니다.AI가 제시하는 여러 구현 방식 중, 현재 비즈니스 상황과 성능, 유지보수성을 종합적으로 고려하여 어떤 방식이 가장 적합한지 논리적으로 선택하고 책임지는 의사결정 능력이 필요합니다.
사실 다 발표시키거나 토론시키는 줄 알고.. 아예 대본을 써갔다ㅋㅋㅋ
참석했더니 샌드위치와 간식들을 챙겨주셨다. 쿠키가 정말 맛있어서 궁금하다!!!
근데 앞에 불이 너무 밝아서 스크린 화면이 잘 안보였다... 나름 명당자리였는데도불구하고
1부. 한 줄도 안 적혀 있던 폴더에서 운영 서비스까지 - Vibe Coding 풀사이클 20분
1부에서는 빈 폴더에서 시작해 실제 운영 가능한 서비스까지 만드는 Vibe Coding의 흐름을 다루었다.
핵심은 AI에게 단순히 “코드를 만들어줘”라고 요청하는 것이 아니라, 먼저 스펙을 정리하고 작은 단위로 개발을 진행해야 한다는 점이었다. AI는 빠르게 코드를 생성할 수 있지만, 누락된 컬럼이나 감사용 히스토리 테이블, 버전 관리처럼 운영에서 중요한 부분을 놓칠 수 있다. 그래서 AI가 만든 결과물을 그대로 믿기보다, 사람이 설계와 검증을 책임져야 한다는 점이 강조되었다.
또한 백엔드는 작은 단위로 나누어 항상 실행 가능한 상태를 유지하고, 프론트엔드는 디자인 시스템과 규칙을 먼저 제공해야 일관된 결과물을 얻을 수 있다고 설명했다. Docker Compose 역시 개발 첫날부터 구성해야 운영 환경과 가까운 구조를 만들 수 있다는 점이 인상적이었다.
결국 Vibe Coding은 단순히 AI에게 코딩을 맡기는 것이 아니라, 사람이 전체 구조를 설계하고 AI를 활용해 구현 속도를 높이는 방식에 가깝다. 앞으로 개발자는 코드를 직접 많이 치는 사람보다, 무엇을 만들지 정의하고 어떻게 설계할지 결정하는 사람이 되어야 한다는 메시지가 핵심이었다.
2부. Copilot 등장부터 지금까지 - AI 시대 속 개발자의 생존법
2부에서는 GitHub Copilot 등장 이후 AI 개발 도구가 어떻게 변화했는지, 그리고 AI 시대에 개발자가 어떤 방향으로 나아가야 하는지를 다루었다.
처음에는 Copilot처럼 코드 일부를 자동완성해주는 수준이었다면, 이후 ChatGPT, Copilot Chat, Cursor, Claude Code 같은 도구들이 등장하면서 이제는 AI가 코드베이스 전체를 이해하고 작업을 수행하는 단계까지 발전했다. 강연자는 이 변화로 인해 개발자들이 단순히 “더 효율적으로 개발하는 법”이 아니라 “앞으로 어떻게 생존할 것인가”를 고민하게 되었다고 말했다.
특히 코드 생성 비용이 낮아지면서, 이제는 코드 자체보다 문서와 명세가 더 중요해졌다는 점이 강조되었다. AI에게 좋은 결과물을 얻기 위해서는 먼저 문제를 잘 정의하고, 스펙을 명확히 작성해야 한다. 반대로 명세가 부정확하면 그 오류가 개발 계획과 코드 전체로 커질 수 있다.
AI는 웹 서비스, 백오피스, 프로토타입, 유틸리티 작성처럼 빠르게 검증 가능한 작업에는 강하지만, 최신 정보나 상식적 판단, 도메인 맥락 이해에는 여전히 약점이 있다. 따라서 AI의 결과물을 인턴이나 신입의 작업물처럼 검토하고, 반복적으로 검증하는 과정이 필요하다고 설명했다.
2부에서 가장 크게 느낀 점은 AI가 개발자의 일을 완전히 없애는 것이 아니라, 개발자의 역할을 바꾸고 있다는 점이었다. 앞으로는 코드를 많이 작성하는 능력보다 문제 정의, 문서화, 검증, 도메인 이해, 협업 방식에 대한 고민이 더 중요해질 것 같다.
전체적으로 느낀점...
나는 아직도 개발할 때 ChatGPT 같은 대화형 AI를 주로 사용한다. 궁금한 점을 물어보고, 오류를 해결하고, 필요한 코드를 요청하는 방식이다. 강연을 듣기 전까지 내가 AI 없이 개발을 하지 못한다면, 단순히 AI가 시키는 대로만 만드는 사람이라면 과연 개발자라고 할 수 있을까?라는 생각을 가지고 있었다.
그런데 연사님이 실제로 사용하는 문서와 작업 방식을 보여주셨을 때 생각이 조금 바뀌었다. 단순히 AI에게 코드를 만들어 달라고 요청하는 것이 아니라, 무엇을 만들 것인지 명확하게 정의하고, 요구사항과 구조를 구체적으로 설계한 뒤 AI를 활용하고 있었다. 특히 프롬프트의 수준 자체가 내가 사용하던 방식과는 많이 달랐다. 결국 중요한 것은 AI를 쓰느냐 안 쓰느냐가 아니라, AI를 얼마나 잘 활용할 수 있도록 문제를 정의하고 설계할 수 있느냐라는 생각이 들었다.
또 하나 인상 깊었던 것은 참석자 대상 설문조사였다.
- 구글 검색을 하면서 IDE에서 직접 개발: 0명
- ChatGPT, Copilot과 채팅하며 개발: 약 10%
- Claude Code, Codex 활용: 약 80%
- 문서만 작성하고 개발은 대부분 자동화: 소수
솔직히 결과를 보고 조금 충격을 받았다. 내가 생각했던 것보다 훨씬 많은 개발자들이 이미 에이전트 기반 개발 환경을 적극적으로 활용하고 있었기 때문이다. 아직도 주로 대화형 AI를 사용하는 내 입장에서는 '내가 생각보다 뒤처지고 있는 건 아닐까?'라는 생각도 들었다.
하지만 동시에 이번 세미나를 통해 중요한 것은 특정 도구를 사용하는 것이 아니라, AI와 함께 일하는 방식을 배우는 것이라는 점도 느꼈다. 앞으로는 코드를 얼마나 빠르게 작성하느냐보다 문제를 정의하고, 설계하고, 검증하는 능력이 더 중요해질 것 같다.
이번 세미나는 AI 시대에 개발자가 어떤 방향으로 성장해야 하는지 진지하게 고민해 볼 수 있었던 시간이었다. 시리즈 형태로 후속 세미나도 예정되어 있다고 하는데, 다음 강연도 꼭 들어보고 싶다.