AI x Front-End: 코딩의 미래를 묻다 밋업 후기

date

Sep 1, 2025

slug

naver-ai-frontend-meetup

author

status

Public

1. AI 도구로 2배 속도 내는 프론트 개발팀 만들기 (장기효 님)

“AI로 동료의 칼퇴를 지켜주세요.” 🤖

반복되는 업무 자동화 하기

팀 리소스는 그대로인데, 업무량은 점점 늘어나는 상황.

장기효 님은 이 문제를 해결하기 위해 반복 업무 자동화에 집중했다고 합니다.

실무를 하다 보면 기술적 성장과 직접 연결되지는 않지만 매번 반복해야 하는 업무들이 있습니다.

예를 들어,

PR 생성

배포 담당자 공유

배포 체크리스트 정리

e2e 테스트 실행

등과 같은 반복적인 작업들이 이에 해당합니다.

이러한 업무들을 자동화한 경험을 공유하며, AI의 발전으로 이 작업에 대한 부담이 크게 낮아졌다고 강조했습니다.

예전에는 GitHub Actions와 Open API 문서를 일일이 찾아보며 스크립트를 작성하고,

오류가 발생하면 수정하고, 유지보수에도 많은 리소스가 들었습니다.

하지만 지금은 👉 플로우 설계 → 프롬프트 작성 → 결과 점검

이 세 단계만으로 대부분의 작업을 처리할 수 있게 되었고,

진입 장벽과 유지보수 부담도 크게 낮아졌다고 했습니다.

여기서 얻은 프롬프트 작성 팁은 다음과 같습니다.

자동화하려는 흐름을 구체적으로 설명하고

필요한 코드나 파일을 함께 제공하며

에러가 날 경우에는 최신 코드와 에러 메시지를 같이 주고

조건이 추가된다면 조건 역시 명확히 서술하는 것

이런 방식으로 작성한 프롬프트는 AI가 맥락을 더 잘 이해하고, 원하는 결과를 빠르게 도출하는 데 도움이 된다고 합니다.

PR 리뷰에 들이는 리소스 줄이기

장기효 님은 “사실 이 이야기를 하려고 나왔다”고 말하며, 이 주제를 특히 강조했습니다.

PR 작성과 컨벤션 코멘트 같은 반복적인 작업을 줄이면 팀 리소스를 절감할 수 있지 않을까?

이 고민에서 출발해 다음과 같은 자동화 흐름을 구축했다고 합니다.


flowchart LR
    A([PR 생성]) --> B([GitHub Actions 트리거])
    B --> C([Open API call])
    C --> D([GPT 실행<br/>Diff 기반 요약])
    D --> E([PR 본문 갱신])

    %% 스타일 정의
    classDef step fill:#f0f9ff,stroke:#0ea5e9,stroke-width:2px,color:#0c4a6e,font-weight:bold;
    classDef highlight fill:#fff7ed,stroke:#f97316,stroke-width:2px,color:#7c2d12,font-weight:bold;

    class A,B,C,E step;
    class D highlight;

PR 생성

개발자가 새로운 PR을 생성하면 워크플로우가 시작됩니다.

GitHub Actions 트리거

PR 이벤트를 감지해 GitHub Actions가 자동 실행됩니다.

Open API 호출 → GPT 실행

Actions 단계에서 Open API를 통해 GPT를 호출하고, PR의 diff 내용을 기반으로 주요 변경점, 코드 요약, 주의사항 등을 정리합니다.

GPT에게는 “FE 팀의 PR을 요약하는 전문가”라는 역할을 부여하고, 팀의 리포지토리 구조, 기술 스택, 코딩 컨벤션 문서까지 학습시켜 맥락을 반영한 응답이 가능하도록 설정합니다.

PR 본문 자동 갱신

GPT가 작성한 요약 결과는 다시 GitHub API를 통해 PR 본문에 반영됩니다.

결과적으로 이 흐름은 단순한 자동화를 넘어, 팀의 문화와 개발 컨벤션을 반영한 ‘맞춤형 도구’로 발전했습니다.

코드만 요약하는 것이 아니라, 팀의 맥락에 맞춘 내용을 제공한다는 점에서

“우리 팀에 적용한다면 어디부터 자동화할 수 있을까?”를 자연스럽게 고민하게 만들었습니다.

발표를 들으며 기억에 남은 메시지는 “자동화도 결국, 명세 작성 능력에 달려 있다”.

AI가 도와줄 수는 있지만, 문제를 정의하고 맥락을 명확히 잡아내는 일은 결국 인간의 몫입니다.

코드보다도 ‘문제 정의’가 더 중요해지는 시대라는 말이 실감 났습니다.

이 세션이 ‘실무 중심의 자동화 사례’를 다룬 발표였다면, 다음 세션에서는 시야를 한층 넓혀

AI 시대, 개발자의 역할은 어떻게 변화할까? 라는 질문으로 이어졌습니다.

2. 우리가 알고 있는 프로그래밍의 종말: 현실적 AI / 박재성님

박재성 님의 발표는 “AI가 개발자를 대체할까?”라는 도발적인 질문으로 시작됐습니다.

하지만 곧 이야기는 개발자의 미래 역할이라는 더 깊은 주제로 이어졌습니다.

AI가 코드를 작성하는 시대가 도래하면서, 개발자의 직업 자체가 흔들리는 듯 보일 수도 있습니다.

그러나 발표를 듣다 보니, 더 중요한 건 “변화가 불가피하다면, 우리는 어떻게 적응할 것인가?”에 대한 고민이라는 생각이 들었습니다.

AI를 접목한 기술 조직의 두 가지 패턴

AI를 잘 활용하는 기술 조직은 크게 두 가지 유형으로 나뉜다고 합니다.

부트스트래퍼 (Bootstrapper)

아이디어를 빠르게 프로토타입으로 구현

예전 같으면 몇 주 걸릴 작업이 몇 시간 내에 끝나기도 함

이터레이터 (Iterator)

기존 코드를 계속 다듬고 개선

리팩토링, 테스트, 보완을 반복하며 품질을 높이는 방식

공통점은 명확합니다. 👉 AI가 ‘돌아가는 코드’를 빠르게 만들어낸다는 것.

하지만 정말 그 코드가 곧바로 확장 가능하고 안정적인 제품이 될 수 있을까요?

그건 또 다른 이야기입니다.

AI의 한계와 생산성의 역설

이 지점에서 박재성 님은 시니어와 주니어 개발자가 AI를 대하는 방식의 차이도 언급했습니다.

시니어 개발자는 AI의 출력을 비판적으로 바라보고, 필요한 보완을 스스로 판단할 수 있습니다.

오랜 경험을 통해 "무엇이 이상한지", "어디를 고쳐야 하는지"를 빠르게 파악하죠.

반면, 주니어 개발자는 AI의 결과를 그대로 수용하는 경향이 있습니다.

디버깅이나 로직 추론을 뒷받침할 멘탈 모델이 부족하기 때문에,

문제의 원인을 직접 분석하기보다는 AI가 제시한 답에 의존하게 되는 경우가 많습니다.

이처럼 AI를 잘 활용하려면, 그 결과를 검토하고 해석할 수 있는 능력이 중요합니다.

이 대목에서 아래 문장을 인용하셨는데요.

“AI는 70%까지 데려다주지만, 남은 30%는 인간의 몫이다.”
— Roblox의 Peter Yang

이 70%와 30%는 각각 무엇을 의미할까요?

70%

빠르게 프로토타입을 만들고 MVP를 띄우는 단계
‘돌아가는 코드’를 빠르게 확보하는 수준

30%

엣지 케이스 처리, 예외 상황 대응
코드 품질과 일관성, 팀 기준에 맞는 구현
즉, 전문 개발자의 개입이 필요한 영역

예를 들어 Cursor AI 사용 사례에서, IDE 내부 에이전트가 “완료됨”으로 표시한 작업이 실제로는 전혀 의도와 맞지 않았던 경험을 언급했습니다.

이처럼 AI가 내놓은 결과물이 '겉보기엔 완성된 것처럼 보여도', 실제로는 그렇지 않은 경우가 많습니다.

이런 경험은 아마 많은 개발자분들이 공감하실 수 있을 겁니다.

이에 대한 내용은 다음과 같은 데이터로도 확인할 수 있습니다.

State of AI 2025 보고서

코딩 어시스턴트를 사용하는 개발자들이 꼽은 가장 큰 Pain Point 1위는 바로 "환각(Hallucination)과 코드 퀄리티”였습니다.

결국 많은 개발자들이 느끼는 건 비슷합니다.

AI는 분명 개발 속도를 높여주지만,

그만큼 늘어난 코드가 '신뢰할 수 있는 코드'인지에 대한 확신은 낮다는 것이죠.

이 지점에서 앞서 언급한 Peter Yang의 말이 다시 떠오릅니다.

"AI는 70%까지 데려다주지만, 남은 30%는 인간의 몫이다."

이 남은 30%는 단순한 마무리 작업이 아닙니다.

바로 코드의 품질을 책임지고, 자동화된 결과가 실제로 동작하며 가치를 만들어내는지를 검증하는 과정이죠.

비슷한 맥락에서 제가 인상 깊게 본 영상도 하나 있었습니다.

최근 Vercel에서 Cursor AI로 이직한 엔지니어 Lee Robinson은 이렇게 말했습니다.

"Vibe 코딩은 개인 토이 프로젝트에는 좋지만, 팀 프로젝트나 프로덕션 앱에는 맞지 않는다."

- (관련 영상 보기)

결국 필요한 것은 균형 있는 시선 아닐까?

그렇다면, 단순히 생산성 향상이 전부일까요?

다양한 리포트를 보면 오히려 속도가 품질을 압도하고 있는 현실이 보입니다.

Fortune 100 기업 소속 개발자 100명 대상 실험

→ PR 생성량 26% 증가, 빌드 횟수 38% 향상

GitHub 저장소들을 모니터링하는 Git Clear의 리포트

AI 도입 후, 신규 코드량은 증가했지만 리팩토링 비율은 감소

AI Paradox Report 2025

코드는 더 빨라졌지만 PR 리뷰 시간은 늘어남

즉, 코드를 더 빨리 더 많이 쓰게 되었지만,

그에 따른 팀 차원의 품질 유지 비용은 오히려 높아지고 있는 상황입니다.

결국 중요한 건 "AI를 쓰는 사람"

지금 우리가 마주한 질문은 단순히 "AI가 코드를 잘 짜는가?"가 아닙니다.

“AI가 만들어낸 코드에 대해, 우리는 어떤 기준과 책임을 가져야 하는가?”입니다.

AI의 시대에, 개발자는 단순히 코드를 입/출력 후 값을 확인하는 사람이 아니라

그 출력의 품질과 방향성을 판단하고 조정하는 큐레이터가 되어야 하지 않을까요?

AI로 개발자들은 사라질까요? 글쎄요, 역할이 바뀌는 중 아닐까요?

O'Reilly팀은 이 현상을 “우리가 알고 있는 프로그래밍의 종말”이라고 표현했습니다.

기술 발전은 생산성만 높이는 게 아니라, 새로운 수요와 역할의 탄생을 동반합니다. (→ 제본스의 역설 )

실제로 전통적인 개발 워크플로우에서 '코드 작성'이 차지하는 비중은 전체의 10~20%에 불과합니다.

이제는 자연어로 명확한 명세를 구조화할 수 있는 능력이 더 중요해지고 있습니다.

“앞으로는 코드를 잘 짜는 사람이 아니라, 문제를 잘 설명하는 사람이 개발자가 될지도 모른다.”

실용 팁: 지금 당장 적용해볼 수 있는 것들

AI 모델은 너무 고민하지 말고, 가장 많이 쓰는 모델부터 시작하세요.

짧은 컨텍스트, 새 대화 중심의 프롬프트 작성이 효과적입니다.

팀 차원에서 도구별로 지침 파일(AGENTS.md)을 만들어두는 것도 추천합니다.

음성 기반 명령 도구(Super Whisper, VS Code Speech, Wisper 등)도 주목할 만합니다.

비용 이슈가 있다면 OpenRouter, Cline, Live LLM 같은 종량제 기반 대안들을 고려해보세요.

3. Code Wars: The Last Coder: AI가 코드를 쓰는 세상, 개발자의 역할은 어떻게 바뀌는가? / 차성원

한 달에 10만 건이 넘는 AI 요청을 실제 업무에 적용한 경험을 공유해주셨습니다.

단순한 데모가 아니라, 실제 조직과 제품에서 AI를 어떻게 활용하고 있는지에 대한 생생한 이야기였습니다.

광고 소재 템플릿 엔진 개선

이미지 내 텍스트가 잘리지 않고 이미지와 자연스럽게 배치되도록,

폴리곤을 추출해 가이드 영역을 만들고 텍스트를 유연하게 배치하는 자동화 기능을 구축했다고 합니다.

이 과정에서 AI가 clipper-lib, line-simplification 같은 라이브러리를 추천해주었고,

빠른 실험 → 결과 검증 → 반복 개선이 가능한 워크플로우를 만들 수 있었습니다.

Blockly AST 해석 도구 개발

기획자가 만든 Blockly 기반의 블록 코드를 AST로 받아, 내부 DSL 수준의 작업을 자동 변환하는 해석 도구를 개발했습니다. 사람이 하자면 반복 작업과 리소스 소모가 많을 수밖에 없는 부분을 AI를 활용해 처리한 사례였습니다.

특히 비개발자와 협업하는 상황에서 의미 있는 자동화 사례로 인상 깊었습니다.

대규모 광고 CMS 통합

두 개의 광고 플랫폼(검색 광고: A 기술 스택 / 성과형 디스플레이 광고: B 기술 스택)을

하나의 통합된 광고주 센터로 전환하는 대형 프로젝트였습니다.

A 기술 스택: 화면 90개 + 모달 110개

B 기술 스택: 화면 70개 + 모달 60개

총 300개 가까운 화면을 AI를 통해 분석하여 컴포넌트 유형을 정리하고 마이그레이션 룰을 만들고

다양한 size, variants, className을 수용할 수 있는 통합 전략을 수립했습니다.

이 과정에서 A→B 기술로 전반 전환하기 위한 명세도 함께 작성 중이며,

규칙 설계는 사람이, 검색·리서치·코드 변환 등 반복 가능한 작업은 AI가 보조하는 구조로 진행 중이라고 합니다.

AWS Kiro IDE에 대한 간단한 소개

Kiro는 vibe 모드와 spec 모드, 두 가지 방식을 제공하는 AI 기반 IDE입니다.

vibe: 자유롭게 코딩하며 아이디어를 빠르게 실험할 수 있는 모드

spec: 더 높은 비용이 들지만, 명확한 요구사항을 바탕으로 더 정확한 코드를 생성하는 모드

특히 spec 모드를 살펴보며 인상 깊었던 점은,

좋은 결과물을 얻기 위해서는 반드시 좋은 명세가 필요하다는 사실이었습니다.

마무리하며

이번 글은 지난 네이버 프론트엔드 개발자 밋업에서 들었던 발표들을 바탕으로,

AI 시대 개발자로서 우리가 고민해야 할 방향과 역할에 대해 정리한 글입니다.

실제 업무 환경에서 AI를 어떻게 팀워크와 생산성에 녹여낼 수 있는지,

그 구체적인 사례와 원칙을 배울 수 있었던 의미 있는 시간이었고,

저 역시 많은 인사이트를 얻을 수 있었습니다.

개인적으로 가장 와닿았던 메시지는 이 한 문장이었습니다.

개발자는 더 이상 코드를 짜는 사람만은 아니다.

AI는 분명 개발 속도를 비약적으로 끌어올려 줍니다.

하지만 그 속도를 품질로 전환하는 능력은 여전히 개발자에게 달려 있습니다.

속도는 누구나 낼 수 있습니다.

그러나 ‘어떤 방향으로’ 속도를 낼 것인가는 전혀 다른 이야기입니다.

결국, 빠른 속도를 좋은 결과로 연결 지을 수 있는 사람—

그게 바로 지금 시대가 원하는 개발자의 모습이 아닐까… 저는 그렇게 생각합니다.

📝 이 글은 발표 내용을 기반으로 개인적인 해석과 정리를 덧붙여 작성한 후기입니다.

중간중간 들어간 생각은 어디까지나 제 개인적인 의견이니, 가볍게 참고해 주시면 감사하겠습니다.