프론트 제가 한번 세팅해봤는데요 (← 프론트 1도 모르는 백엔드 개발자)

이 글의 탄생 배경 

혼자서 뚝딱거려 만든 프론트엔드 작은 토이 프로젝트가 있었습니다. 처음에는 그저 제 컴퓨터에서 돌아가기만 하면 만족이었죠. 하지만 이 프로젝트를 더 이상 혼자가 아닌, 다른 팀원과 함께 키워나가야 할 시점이 왔습니다. 그때부터 문제는 시작되었습니다.

 

"제 PC에서는 되는데, 팀원 PC에서는 왜 안될까?"
"분명 같은 코드인데 왜 다른 결과가 나오지?"

 

이런 비효율적인 상황을 막기 위해, 백엔드 개발자인 제가 프론트엔드 '협업 환경'이라는 낯선 땅에 직접 발을 들이기로 결심했습니다. 이 글은 npm install조차 모르던 제가 수많은 에러와 질문을 거쳐, 팀을 위한 개발 환경의 기준을 세워나가기까지의 여정을 담은 기록입니다.

---

1단계: 눈앞의 불부터 끄기

처음 제 목표는 단순했습니다. 'Vercel에 배포하기'. 기존에 GitHub Pages로 운영되던 프로젝트를 더 전문적인 환경으로 옮기고 싶었죠. 그래서 AI에게 첫 질문을 던졌습니다.

"현재 github에서 렌더링 중인 페이지가 있는 프론트엔드만 있는 상황이거든요? 이거 vercel로 옮기고 싶은데 어떤 특징 및 고려할 사항, 그리고 구체적인 스텝 알려주세요."

AI가 알려준 단계를 따라 배포를 시도했지만, 현실은 냉혹했습니다. 하얀 화면과 함께 콘솔에 찍힌 에러 메시지. 이때부터 저의 진짜 협업이 시작되었습니다.

"같은 브랜치인데 github page에서는 보이는데, vercel로 배포하니깐 이런 에러가 나는데요. 그럴 수 있는 건가요?
Uncaught SyntaxError: Unexpected token '<' (at main.33b74d87.js:1:1)"

구글링으로는 파편적인 정보만 나올 뿐, 제 상황에 딱 맞는 답을 찾기는 어려웠습니다. 문제가 터지면 일단 AI에게 다급하게 물어보는, 그야말로 '불 끄기'의 연속이었습니다.

 

"IntelliJ에서 src 파일이 갑자기 사라졌어요. 어떻게 된 거죠?"
"그냥 a798a603 커밋으로 롤백해주세요."

 

이 시기의 제 질문들은 대부분 반응적이었습니다. 문제가 터지면 해결을 요청하고, 막히면 이전 상태로 되돌리는 식이었죠. AI는 제 옆자리 사수처럼 침착하게 IDE의 캐시 문제, Git 명령어 등을 알려주며 급한 불을 꺼주었습니다.

 

---

2단계: '왜?'라고 묻기 시작하다

어느 정도 에러를 잡고 나니, 근본적인 의문이 들기 시작했습니다. '이 프로젝트, 지금 이대로 괜찮은 걸까?'

 

단순히 에러 메시지를 해결하는 것을 넘어, 프로젝트의 건강 상태를 진단하고 싶어졌습니다.

"현재 컴퓨터와 프로젝트에서 react, ts, node 각각 버전을 어떻게 쓰고 있는지, 현재 시점에 베스트프랙티스가 맞는지 확인해주세요."

이 질문을 시작으로, 저는 더 이상 'How(어떻게)'가 아닌 'Why(왜)'를 묻기 시작했습니다.

"React 19 써도 괜찮을까요? 리액트 19 자체는 안정적이지만 라이브러리가 그렇지 못하다는 얘기들이 있어서요."

"node는 22 버전 유지하고, ts는 최신화 한다고 했을 때 react 19를 쓰는게 맞나요 18을 쓰는게 맞나요? 가급적이면 19를 쓰면 좋겠는데, 그렇게 했을 때 현재 전체 프로젝트를 탐색해서 크게 문제될 부분이 있을지 다시 한번 확인해주세요."

AI는 제 프로젝트의 package.json을 분석하며 React 19와 react-scripts@5.0.1의 호환성 문제, 그리고 @types/react@18 버전과의 충돌 가능성을 조목조목 짚어주었습니다. 단순히 "18 버전을 쓰세요"가 아니라, 왜 그래야 하는지에 대한 명확한 근거를 제시해 주었죠.

 

이 순간, 저는 흩어져 있던 문제의 점들이 '버전 비호환'이라는 하나의 선으로 연결되는 것을 느꼈습니다.

---

 

3단계: '우리'를 위한 기준 세우기

이제는 제대로 된 발판을 다져야 할 때라는 생각이 들었습니다. 저 혼자만의 성공이 아닌, 팀원 모두가 같은 출발선에서 안정적으로 도약할 수 있는 환경을 만드는 것이 진짜 목표였으니까요. '제 PC에서는 되는데, 왜 다른 사람 PC에서는 안될까?'라는 질문은 더 이상 피할 수 없는, 가장 먼저 해결해야 할 과제였습니다.

 

이때부터 제 질문의 결이 바뀌기 시작했습니다. 가장 먼저 눈에 들어온 것은 프로젝트의 일관성 문제였습니다.

"현재 이 프로젝트는 npm과 yarn이 공존하는거 같은데요. 이게 일반적인 상황인가요?"

 

AI의 답변을 통해 이는 잠재적인 의존성 충돌의 원인이 될 수 있음을 알게 되었고, 곧바로 기준을 세웠습니다.

"실제 프로젝트에서 그럼 yarn을 사용하지 않게 수정해주세요."

 

패키지 매니저를 통일하고 나니, 이제는 코드 자체가 눈에 들어왔습니다. 파일마다 다른 따옴표, 제각각인 세미콜론... 이대로는 안 되겠다는 생각이 들었죠.

"Linter와 Prettier가 뭔가요?"
"이런거를 IDE가 아니라 소스 차원에 설치를 하는 건가요? React와 TS를 사용하는 프로젝트이거든요."

 

프론트엔드 개발자에게는 너무나 당연할 수 있는 이 질문들을 통해, 저는 코드 스타일을 강제하고 잠재적 버그를 잡는 도구의 필요성을 깨달았습니다. 그리고 곧바로 실행을 요청했습니다.

"eslint와 Prettier를 사용하도록 설치해주고, 관련 내용도 DEPENDENCIES 문서랑 README.md 문서에 업데이트 해주세요."

 

마지막으로, 이 모든 노력이 다른 팀원에게 온전히 전달되도록 하는 것이 중요했습니다.

"팀원들이 다른 Node 버전을 쓰는 것을 방지하고 싶어요. .nvmrc를 작성해두면 좋을까요?"
"지금까지의 내용에 따라 README로 문서화해주세요. 어떤 사람이 어떤 컴퓨터에서 이 프로젝트를 켜도 문제 없이 작동하도록 도와주어야 합니다."

 

.nvmrc 이라는 파일의 존재조차도 실은 AI가 이전에 알려주었던 것입니다. AI는 .nvmrc 파일 생성을 빠르게 만들어주었고, README에는 단순한 설치법을 넘어 이 프로젝트가 겪었던 이슈들과 버전 선택의 이유까지 상세히 담아주었습니다.

 

---

개발자 == 오케스트레이터 ? 

솔직히 고백하자면, 저는 프론트엔드 지식이 거의 전무합니다. 그럼에도 단 2시간 안에 제가 상상하던 수준의 협업 환경을 구축할 수 있었습니다.

 

불과 몇개월 전만 해도 프론트엔드 개발을 할 때 바쁘게 복사해 붙여넣기를 해서 가까스로 완성하는 수준이었습니다. 아래의 글을 쓴 게 작년 10월이네요. 

 

 

GPT 복붙만으로 프로그램을 만들 수 있을까? (feat. AI 시대의 개발자, 기묘한 질문들, 그리고 낯설

 

몇개월 만에 촌극이 되어버렸습니다. 이제는 AI 에이전트가 소스코드 전체를 이해합니다. 순전한 자연어만으로 상상하는 대부분은 쉽게 구현이 가능합니다. 

 

이 과정에서 저는 코드를 짜는 사람이기보다, 거대한 오케스트라를 지휘하는 '오케스트레이터'에 가깝다는 생각이 듭니다. 제 역할은 명확한 '목적'과 '방향'을 제시하는 것일 뿐입니다.

 

이런 질문이 들 수도 있겠습니다. "AI가 다 해주는데, 인간 개발자가 왜 필요한가? 경험과 지식은 더 이상 중요하지 않은가?" 어떤 의미에서는 맞습니다. 인간은 이제 모든 것을 알 필요 없이, 목적지를 설정하는 역할만 해도 될지 모릅니다.

 

하지만 경험 없는 초보자가 가질 수 있는 가장 강력한 무기는 바로 '모른다는 사실을 아는 것'입니다.

 

만약 제가 시니어 프론트엔드 개발자였다면, 처음부터 버전 호환성을 확인하고 Linter 설정을 점검했을 겁니다. 하지만 저는 그 영역을 모르기에, "내가 뭘 모르는지"부터 알아야 했습니다. 그래서 제 질문은 대부분 이런 식이었습니다.

"제가 지금 잘하고 있는 게 맞나요? 놓친 건 없나요?"
"이 상황의 베스트 프랙티스는 무엇인가요? 리서치해서 알려주세요."

 

핵심은 내가 모르는 것을 어떻게 알 것인가, 즉, 무지의 지를 어떻게 획득할 것인가가 아닐까 합니다. 

 

질문을 잘 할 필요도 없는 거죠. 막연하게라도, 이런 걸 하고 싶은데 뭘 알아야 할까요? 어떻게 질문해야 할까요? 가 치트키입니다. 

 

이런 의미에서 AI 시대의 개발자는 오케스트레이터에 가까워보입니다. 한 스쿼드의 장, 한 팀의 팀장, 1인 기업의 CTO와 비슷해보입니다.  그리고 이 여정의 시작은 언제나 "제가 뭘 모르는지부터 알려주세요"라는, 가장 솔직한 질문이 아닐까 하는 생각이 듭니다.