현직 개발자 특강 3개를 듣고, 프로젝트 설명을 전부 다시 썼다

한눈에 요약 7월 10~11일 이틀간 서울청년정책박람회와 청년쓰리룸에서 현직 개발자 특강 3개를 들었다. 세 명이 각자 다른 자리에서 같은 결론을 말했다 — AI가 코드를 만들어도, 왜 그렇게 만들었는지 설명하고 책임지는 건 사람이다. 듣고 와서 내 쇼룸의 프로젝트 설명을 전부 다시 썼다.

가기 전날 밤, 솔직히 신청을 조금 후회했다.

나는 비전공자다. AI와 대화하며 코드를 만드는 바이브코딩으로 개발을 시작했다. 현직 개발자들 앞에 앉으면 "AI로 만든 게 개발이냐"는 시선을 받지 않을까. 그 두려움을 안고 이틀을 다녀왔고, 결론부터 말하면 두려움은 명확함으로 바뀌었다. 그리고 이 이야기는 개발을 몰라도 상관없는 이야기다. AI가 뭐든 해주는 시대에 결국 남는 사람이 누구인가에 대한 이야기라서.

특강 정보는 우연히 알게 된 게 아니다. 청년 정책 사이트 공고를 매번 들어가 보기 귀찮아서, 사이트별 API를 크롤링해 디스코드로 알림을 받는 시스템을 만들어 쓰고 있다. 이 특강 3개 전부 그 알림이 물어다 줬다.

금요일 낮 — 개발 특강인 줄 알았는데 보안이었다

DDP에서 열린 박람회 IT 멘토링. 테이블에 둘러앉는 형식이었는데, 전반부는 콘텐츠 크리에이터 두 분의 브랜딩 이야기였고 — "완벽하게 준비하지 말고 일단 시작해라"가 남았다 — 후반부에 개발자 멘토링인 줄 알고 앉은 자리의 주인공이 나타났다. IBM 보안 스페셜리스트. 예상이 빗나갔는데 오히려 흥미로워서 다른 테이블로 옮기지 않고 40분을 다 들었다.

이 분은 보안 일을 하기 전에 물류센터에서 일했다고 했다. 직무를 먼저 정한 게 아니라 "남을 도와주는 사람이 되고 싶다"를 먼저 정했고, 물건을 잘 포장해 보내면 받는 사람이 도움을 받듯 보안도 결국 누군가를 도와주는 일이라 선택했다고. 일의 형태만 다르지, 되고자 하는 사람은 같다 — 이틀간 들은 말 중 이게 제일 오래 남았다.

본인도 비전공자 출신이라고 했다. 취업 준비 때는 취약점 세 개를 골라 직접 공격해 보고, 막아 보고, 탐지 시스템까지 만들어 보는 과정을 포트폴리오로 묶었다고 한다. 첫 프로젝트가 Log4Shell — 2021년에 터진, 원격으로 서버를 장악할 수 있었던 유명 취약점이다. 마인크래프트가 자바로 만들어졌다는 점에 착안해 직접 게임 서버를 열고 공격이 되는지, 왜 되는지, 어떻게 막는지를 검증했다는 것. "내 지식이 여기까지고, 난 여기까지 검증해봤다"를 보여주는 게 목표였다고 했다. 자격증은 있으면 플러스지만 없다고 마이너스는 아니라고. 그보다 아는 걸 표현하는 능력과 "궁금해하는 자세"를 제일 강조했다 — 공격이 왜 발생했는지 궁금해하지 않고 처리만 하는 사람은 오래 못 한다고.

기술 쪽으로 제일 실용적이었던 조언은 이것. 1인 개발자라면 다 만들고 나서 몰아서 점검하지 말고, 기능 하나 페이지 하나 만들 때마다 점검해라. 코드를 짤 때부터 보안을 집어넣는 시큐어 코딩을 해라. 다 만들고 나서 보면 찾기가 너무 어렵다.

AI 시대의 보안 얘기도 현장감이 있었다. AI 에이전트가 개발자 본인도 입력하지 않은 명령 — 외부 파일 다운로드 같은 — 을 실행하는 사고가 현업에서 실제로 생기고 있다고 한다. 못 쓰게 할 수도, 안 쓸 수도 없어서 사람이 시킨 프롬프트와 AI가 실제 실행한 명령을 대조해 악의적인지 판단하는 방식을 도입 중이라고. AI 때문에 보안 일은 오히려 늘고 있고, AI의 분석과 사람의 분석을 비교해 진짜 공격인지 판단할 수 있는 사람이 더 필요해지고 있다는 것이다.

나도 질문 하나를 얹었다. 보안 기초 지식을 어떻게 넓히면 좋을지. 답은 명쾌했다 — 기초는 인프런이나 유튜브 강의로도 충분하다는 것.

행사장 앞 테이블이라 소음에 말이 자주 묻힌 건 아쉬웠다. 주최측이 다음엔 고쳐줬으면.

금요일 저녁 — 못 물어본 질문 하나

청년쓰리룸의 현직 개발자 특강. 참가자 15~20명 중 비전공자가 절반쯤이라 살짝 안심했다. 강사도 "꽤 많다"고 했다. 나만 이 길을 고민하는 게 아니구나 싶었다. AI 기업에서 제품 고도화를 담당하는 분이었는데, 면접관 입장에서 바이브코딩 프로젝트를 어떻게 보는지가 핵심이었다.

이력서 이야기부터 구체적이었다. 신입은 "무엇을 만들어봤는지"를 광고 헤드라인처럼 앞세우고, 기획부터 배포까지 직접 해본 경험과 디버깅 과정, Git(코드 변경 이력을 관리하는 협업 도구) 흔적으로 증거를 대야 한다고 했다. 회원가입 수나 로딩 시간 개선처럼 작은 수치도 충분하다고. 경력은 반대로 어떤 책임을 맡아 비즈니스에 어떤 영향을 줬는지가 핵심이라, 신입과 경력의 이력서는 완전히 다른 문서라는 것이다.

개발자 실무에서 코드 작성은 일부라는 얘기도 인상 깊었다. 요구사항 확인, 회의, 설계, 리뷰, 배포, 장애 대응이 대부분이고 — 로그인 기능 하나도 이메일·소셜 로그인, 비밀번호 찾기, 암호화, 실패 메시지, 악의적인 입력 처리까지 쪼개서 설계해야 한다. 바이브코딩 프로젝트에서 면접관이 보는 것도 결국 같았다. 문제를 작게 쪼개는 능력, 그리고 AI가 만든 코드에 대한 이해와 검증. 면접관은 "왜 이 코드와 구조를 선택했는지"를 계속 묻는다. "AI가 그러던데요"는 무책임한 답이다.

AI 도입 이후 채용이 어떻게 바뀌는지도 진단했다. 반복적인 코드 작성과 테스트가 자동화되면서 신입 채용은 줄고, AI와 협업하며 전체 흐름을 이해하는 "경력 같은 신입"의 수요가 커졌다고. 포트폴리오도 기술 나열이 아니라 증상 → 원인 → 시도 → 해결 → 수치화된 결과 → 회고 순서의 문제 해결 기록이어야 한다고 했다.

질의응답 때 어떤 분이 웹 서비스를 Vercel과 Supabase로 배포하려 한다고 하자 강사가 "그건 비추"라고 했다. 정확히 내가 쓰는 조합이라 심장이 내려앉았는데, 그 순간 손을 못 들었다. 왜 비추인지는 특강이 끝나고서야 궁금해졌다.

그래서 집에 와서 직접 팠다. 결론은 네 줄로 정리됐다. 첫째, 강의에서는 이 조합이 구체적으로 왜 부적절한지 근거가 제시되지 않았다 — 화자의 선호로 기록하는 게 맞다. 둘째, 실제 사고 대부분은 플랫폼이 아니라 설정에서 난다. 데이터 접근 규칙(RLS — 데이터베이스에서 누가 어떤 데이터 줄을 볼 수 있는지 막는 규칙) 누락, 관리자 키를 브라우저에 노출, 입력값 검증 생략. 셋째, AWS는 자동으로 더 안전한 선택이 아니다. 더 많은 통제권과 함께 더 많은 보안 책임이 따라오는 선택이고, 잘못 설정하면 오히려 더 위험하다. 넷째, 그래서 나는 학습·MVP 단계에서는 지금 조합을 안전하게 설정해 유지하고, 민감정보·결제·규제가 생기는 시점에 전문가 검토와 함께 재평가하기로 했다.

현장에서 못 물어본 질문 하나가 검증 문서 하나가 됐고, 돌아보면 이게 이 특강의 최대 수확이었다.

토요일 — 손을 들었다

마지막은 메타코드의 AI 현직자 특강. 대기업 데이터 엔지니어를 거쳐 지금은 가상자산 분야에서 일하는 현직 소프트웨어 엔지니어의 1시간 강연이었고, 이틀 중 제일 좋았다. 좋은 엔지니어는 코드를 빨리 짜는 사람이 아니라 만들고, 출시하고, 모니터링과 장애 대응으로 운영하고, 지표를 보며 개선하는 — 끝까지 책임지는 사람이라는 이야기.

AI 시대에도 변하지 않는 역량으로 네 가지를 꼽았다. CS 지식과 논리적 사고(알아야 AI 결과를 검증할 수 있다), 문제 정의와 분해(본질을 설명하고 작게 쪼개서 푼다), 검증과 책임(이해 못 하면 오류도 못 찾는다 — 내보낸 결과는 사람이 책임진다), 그리고 소통("AI가 그러던데요"가 아니라 근거로 설명하고 토론한다). AI 활용법도 세 단어로 정리했다. 컨텍스트, 디렉션, 검증 — AI에게 프로젝트의 맥락을 주고, 기획자처럼 명확한 방향을 제시하고, 결과를 검증한다.

제일 뼈아팠던 건 이 말이다. AI는 학습 가속기이자 인간 용량의 거울이라는 것. AI 덕에 배우는 속도는 빨라지지만, 오래 쓰다 보면 사람이 그 출력을 이해하고 검증하는 용량이 병목이 된다. 독서와 공부로 자기 처리 능력을 키워야 한다는 얘기였다. 실전 학습 경로도 단계로 제시했다 — 기존 서비스 따라 만들기에서 시작해, 내 서비스의 명세를 직접 쓰고 구현하고, 팀 프로젝트를 거쳐, 유저 모집·배포·트래픽·장애 대응까지 실제 운영을 해보라는 것. 포트폴리오도 "React·TypeScript를 안다"가 아니라 목표 → 설계와 기술 선택 이유 → 실제 문제와 장애 → 원인 탐색과 해결 → 운영 결과와 지표 → 다음 개선의 서사여야 한다고 했다.

전날까지의 나였으면 조용히 나왔을 텐데, 마지막 질의응답에서 손을 들었다. AI로 개발을 시작해서 기본기 습득이 어렵다는 것, 보안이 제일 중요하다고 생각하는데 AWS 비용이 감당 안 된다는 것. 내 고민을 그대로 꺼냈다.

답은 담백했다. "이미 문제를 충분히 얘기하신 것 같다. 그 문제들을 키워드로 나눠서 하나씩 해보면 좋겠다. 좀만 하시면 금방 잘하실 것 같다."

대단한 비법이 아니었는데 그게 좋았다. 내 문제는 무서워할 대상이 아니라, 쪼개서 하나씩 풀 목록이었다. 비전공자 바이브코더라고 무시당할까 봐 두려워하던 게 이틀 전인데, 현직자 앞에서 고민을 꺼내고 실행 가능한 답을 받아 나왔다.

집에 와서 한 일

솔직히 일단 잤다. 머리가 복잡해서. 자고 일어나서 한 일이 세 가지다.

• 요한 스튜디오 쇼룸의 프로젝트 설명을 전부 다시 썼다. 무엇을 만들었는지가 아니라 왜 만들었고 왜 이 기술을 골랐는지가 보이게.
• 못 물어본 Vercel·Supabase 질문을 파서 검증 문서로 만들었고, "기능 단위로 점검하라"는 조언은 내 검증 도구의 보안 설계에 반영했다. 지금 실제로 돌아가는 건 코드를 올릴 때마다 자동으로 시크릿 유출을 검사해 병합을 차단하는 게이트까지이고, 기능 단위 보안 게이트 구조는 설계를 잡아 넓혀가는 중이다.
• AI 쓰는 습관을 고치기 시작했다. AI가 좋아질수록 알아서 다 해버려서 그냥 넘어가게 되는데, 프롬프트를 구체적으로 쓰고 모르는 부분은 짚고 넘어가기로 했다.

세 명은 서로 다른 자리에서 같은 파도를 다른 각도로 보고 있었다. 보안 담당자에게 AI는 새로운 사고를 만드는 존재였고, 개발자에게는 검증해야 할 코드를 쏟아내는 존재였고, 엔지니어에게는 방향을 줘야 움직이는 존재였다. 셋을 겹치면 한 문장이 남는다. AI가 다 해주는 시대에 남는 건, 왜 이걸 했는지 설명하고 책임지는 사람이다.

특강별 원자료(현장 기록·키워드 사전 포함)는 러닝 로그에서 바로 볼 수 있다 — 박람회 IT 멘토링 편, 청년쓰리룸 편, 메타코드 편. 예전엔 노션 링크로 내보냈지만, 이제 노션에 쓰면 이 사이트에서 바로 읽힌다. 그 연동 과정도 곧 글로 남긴다.

두려움을 안고 가서 할 일 목록을 들고 왔으면, 남는 장사다.

이전 글: AI에게 이틀을 맡겼다 — 무인 작업 12건, 코드 변경 34건의 기록