'AI로 만들 것인가, 직접 짤 것인가.' 프론트엔드 개발자라면 이제 매 스프린트마다 이 질문을 마주한다. 그런데 흥미롭게도, 이 질문에 대한 가장 솔직한 대답은 거창한 벤치마크나 팀 도입 사례 보고서가 아니라—직접 만들어본 사람의 경험에서 나온다.
최근 dev.to에 올라온 두 편의 글이 바로 그 대답에 해당한다. 하나는 AI 도구에 크게 의지해 개인 포트폴리오 사이트를 만든 개발자의 회고이고, 다른 하나는 react-flow나 d3를 쓰지 않고 브라우저 기반 JSON 시각화 도구를 직접 설계한 개발자의 아키텍처 기록이다. 두 글은 서로 다른 선택을 했지만, 같은 질문 앞에 서 있다. 도구를 쓰는 것과 직접 이해하는 것 사이의 트레이드오프.
AI 협업의 명암: 속도를 얻고 창의성을 잃는 경험
Phillip Mogale는 'Animated Space'라는 테마로 개발자 포트폴리오를 만들면서 AI를 전면에 활용했다. 레이아웃 아이디어 생성, React 컴포넌트 보일러플레이트 작성, 버그 디버깅, 심지어 버튼 레이블 같은 마이크로카피까지—AI는 거의 모든 단계에서 '두 번째 개발자'처럼 옆에 있었다. 결과는 예상대로였다. 며칠이 걸렸을 작업이 몇 시간으로 줄었고, 빈 파일을 마주하는 불안감도 사라졌다.
그런데 그가 진짜 흥미롭다고 느낀 건 장점이 아니라 함정이었다. AI가 디자인을, 레이아웃을, 코드를 계속 제안하다 보니 스스로 처음부터 생각하는 능력이 서서히 줄어들었다. 제안을 너무 빨리 수락하고, 대안을 덜 탐색하게 되는 자신을 발견한 것이다. 개인 포트폴리오의 존재 이유가 '나다움'을 드러내는 것인데, AI가 생성한 결과물은 기능적으로 깔끔하지만 예측 가능하고 비슷비슷하다. 결국 차별화되어야 할 사이트가 제네릭해지는 역설이 생긴다.
그가 찾은 균형점은 명확하다. 보일러플레이트, 디버깅 힌트, 아이디어 발산—여기서 AI는 쓴다. 최종 디자인 결정, 핵심 로직 설계, 기초 학습—여기서는 쓰지 않는다. 그리고 가장 중요한 태도 전환: "give me"가 아니라 "why"를 묻는 습관. 결과물을 달라는 것이 아니라, 왜 그런 구조인지를 이해하는 방향으로 AI를 쓰는 것이다.
직접 짜기로 선택했을 때: 5kb로 150kb를 이기는 법
Yavuz Özgüven은 반대편에서 시작했다. 중첩된 API 응답을 반복해서 디버깅하다 지쳐 직접 JSON 시각화 도구(jsonbloom.com)를 만들기로 했는데, 여기서 그는 처음부터 react-flow와 d3-hierarchy를 검토하고 의도적으로 쓰지 않기로 결정했다. react-flow는 gzip 기준 약 150kb에, 노드 드래그·엣지 편집·미니맵 같은 기능을 제공하지만—JSON 뷰어에 실제로 필요한 건 그 중 아무것도 아니다.
그가 작성한 요구사항 목록은 단 다섯 가지였다: 객체와 배열을 박스로 렌더링, 부모-자식 엣지 그리기, 서브트리 접기/펼치기, 캔버스 팬과 줌, 리프 값 인라인 편집. 이 목록을 적어 내려가는 순간 결론은 자명해졌다. 정확히 이 다섯 가지만 하는 ~5kb짜리 커스텀 렌더러가, 훨씬 더 많은 일을 간접적으로 하는 150kb짜리 라이브러리보다 낫다.
아키텍처도 깔끔하다. Astro로 정적 셸을 구성하고, 에디터+그래프 워크스페이스만 React 아일랜드로 마운트했다. 마케팅 페이지에서 React가 로드되는 JS는 0이고, 인터랙티브 영역은 사용자가 히어로를 읽는 동안 병렬로 로드된다. 레이아웃 알고리즘도 직접 작성한 약 200줄의 재귀 함수다—d3도, 포스 시뮬레이션도 없이 결정론적이고 빠르게 동작한다.
물론 직접 짜는 선택이 공짜는 아니었다. 그가 '과소평가했다'고 고백하는 세 가지 어려움이 있다. 인라인 편집 시 에디터 상태(커서 위치, 언두 히스토리)와 그래프 뷰의 동기화 문제, 노드 접기 시 전체 리레이아웃으로 인한 깜빡임, 그리고 순환 참조 탐지. 특히 에디터-그래프 간 통신을 '전체 문서 재파싱'이 아닌 'JSON 포인터 기반 패치'로 설계한 것이 핵심 전환점이었다고 한다. 처음부터 프로토콜을 설계했더라면 훨씬 쉬웠을 것이라는 회고가 인상적이다.
두 경험이 교차하는 지점
두 사례는 표면적으로 다른 선택을 보여주지만, 같은 교훈을 다른 방향에서 확인하고 있다. 도구(AI든 라이브러리든)를 선택할 때 가장 먼저 해야 할 일은, 내가 실제로 필요한 것의 목록을 최대한 좁게 정의하는 것이다. Phillip은 AI를 쓰면서 그 목록 없이 제안을 수락했고, Yavuz는 그 목록을 먼저 적어 내려갔기 때문에 커스텀 구현이 합리적인 선택이 됐다.
또 하나의 공통점은 '이해'의 위치다. Phillip은 AI가 생성한 코드를 비판적으로 검토하지 않으면 이해하지 못한 버그를 그대로 배포하게 된다는 점을 경험했다. Yavuz는 라이브러리 없이 직접 구현하면서 레이아웃 알고리즘, 상태 동기화, 이벤트 흐름을 완전히 소유하게 됐다. 두 경험 모두 '이해 없는 속도'가 어디서 균열을 일으키는지를 다른 방식으로 보여준다.
시사점: 의사결정 프레임을 먼저 짜야 한다
실무에서 이 두 사례가 주는 시사점은 구체적이다. AI를 쓸 것인지, 라이브러리를 쓸 것인지, 직접 짤 것인지—이 결정은 코드를 치기 전에 이루어져야 한다. 그리고 그 결정의 기준은 '무엇이 더 편한가'가 아니라 '이 도구가 내 요구사항 목록과 얼마나 정확하게 겹치는가'여야 한다.
특히 AI 도구의 경우, 창의성과 학습이 핵심 목적인 영역(개인 포트폴리오의 디자인 방향, 핵심 알고리즘 설계)에서는 AI에 의존할수록 오히려 결과물의 독창성이 떨어진다는 점을 직시해야 한다. 반대로 반복적이고 패턴이 명확한 작업(보일러플레이트, 에러 메시지 해석, 마이크로카피 정리)에서는 AI가 투입 대비 효과가 극대화되는 구간이다.
전망: 선택의 근육을 키우는 시대
앞으로 AI 도구의 품질과 라이브러리 생태계 모두 계속 발전할 것이다. 하지만 그럴수록 오히려 '언제 쓰지 않을 것인가'를 판단하는 능력이 더 희소해진다. 두 개발자의 경험이 공통적으로 가리키는 프론트엔드 개발자의 핵심 역량은 결국 같다. 코드를 생성하는 능력이 아니라, 무엇을 만들어야 하는지 좁게 정의하고, 그 정의에 맞는 도구를 선택하며, 선택의 이유를 설명할 수 있는 능력. 이것은 AI가 대체하기 어려운—그리고 AI 시대일수록 더 값어치가 올라가는 의사결정 근육이다.