웹개발, 이제는 '만드는 것'보다 '조립하고 연결하는 것'이 핵심입니다

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

개발자 채용 면접을 보다 보면 흥미로운 변화를 목격합니다. 불과 몇 년 전만 해도 지원자들의 포트폴리오에는 "게시판을 처음부터 끝까지 구현했다"는 내용이 주를 이뤘습니다. 하지만 최근에는 "AI API를 연동해 자동화 기능을 만들었다"거나, "서버리스 아키텍처로 인프라 비용을 줄였다"는 이야기가 훨씬 더 많이 들립니다. 웹 개발의 패러다임이 근본적으로 바뀌고 있다는 증거입니다.

솔직히 고백하자면, 저 역시 처음에는 이런 변화가 낯설었습니다. 과거의 저는 모든 코드를 한 땀 한 땀 직접 작성하는 장인 정신이 개발자의 미덕이라고 믿었습니다. 프레임워크가 다 해주는 개발은 왠지 모르게 '진짜'가 아니라고 생각했던 시절도 있었죠. 하지만 풀링포레스트에서 AI 기반의 프로덕트를 만들고, 급변하는 기술 트렌드 속에서 팀을 이끌다 보니 제 생각이 얼마나 낡은 것이었는지 깨닫게 되었습니다.

우리가 흔히 말하는 웹개발의 정의가 달라졌습니다. 과거에는 HTML, CSS, JavaScript로 화면을 그리고 백엔드 로직을 짜는 행위 자체가 목적이었다면, 지금은 이 모든 기술이 비즈니스 가치를 전달하기 위한 '수단'으로 전락했습니다. 아니, 더 정확히 말하면 수단으로서의 가치가 극대화되었습니다.

저희 팀에서 겪었던 시행착오를 공유하고 싶습니다. 프로젝트 초기에 우리는 자체적인 데이터 처리 파이프라인을 구축하려고 했습니다. "우리 데이터는 특별하니까, 우리가 직접 짜야 가장 효율적일 거야"라는 오만함이 있었던 것 같습니다. 팀원들은 몇 주 동안 밤을 새워가며 훌륭한 코드를 작성했습니다. 하지만 결과는 참담했습니다. 유지보수 비용은 눈덩이처럼 불어났고, 새로운 AI 모델이 나올 때마다 전체 아키텍처를 뜯어고쳐야 했습니다.

그때 뼈저리게 느꼈습니다. '바퀴를 다시 발명하지 말라'는 격언은 단순히 기존 라이브러리를 쓰라는 뜻이 아니라, 비즈니스의 핵심이 아닌 곳에 에너지를 낭비하지 말라는 경영학적 조언이었다는 것을요.

우리는 전략을 전면 수정했습니다. 핵심 코어가 아닌 부분은 과감하게 외부 SaaS와 API에 의존하기로 했습니다. 인증은 Auth0나 Supabase 같은 솔루션에 맡기고, 결제는 스트라이프(Stripe)나 국내 PG사 모듈을 최대한 가볍게 연동했습니다. 대신 우리가 확보한 리소스는 오로지 고객이 우리 서비스에서만 느낄 수 있는 'AI 경험'을 고도화하는 데 쏟아부었습니다.

이 과정에서 웹개발 역량의 정의도 다시 내려야 했습니다. 이제 개발자에게 필요한 능력은 복잡한 알고리즘을 암기해서 구현하는 것이 아닙니다. 수많은 도구와 서비스 중에서 우리 상황에 딱 맞는 '레고 블록'을 찾아내고, 그 블록들을 견고하게 연결하는 '설계 능력'이 훨씬 중요해졌습니다.

특히 주니어 개발자분들께 꼭 드리고 싶은 말씀이 있습니다. "기본기가 중요하다"는 말에 갇혀 너무 로우 레벨(Low-level)의 구현에만 매몰되지 않으셨으면 좋겠습니다. 물론 HTTP 프로토콜의 원리나 자료구조의 기초는 중요합니다. 하지만 그것을 직접 구현하는 것과, 그 원리를 이해하고 도구를 잘 쓰는 것은 별개의 문제입니다.

현재 풀링포레스트 개발팀은 다음과 같은 기준으로 기술 스택을 결정합니다. 여러분도 실무에서 적용해 보시면 도움이 될 것입니다.

1. 직접 만들었을 때 얻는 경쟁 우위가 무엇인가? 단순히 "우리가 할 수 있어서"가 아니라, "이걸 직접 만들어야만 고객 경험이 획기적으로 좋아지는가?"를 자문합니다.

2. 대체 불가능한 SaaS가 존재하는가? 이미 시장에서 검증된, 월 몇 달러로 해결 가능한 솔루션이 있다면 과감하게 결제합니다. 개발자의 인건비가 SaaS 비용보다 훨씬 비싸기 때문입니다.

3. 연결의 복잡성을 관리할 수 있는가? 외부 의존성이 늘어날수록 시스템의 복잡도는 증가합니다. 이를 모니터링하고 제어할 수 있는 관제 시스템(Observability) 구축에 더 많은 공을 들입니다.

최근 등장한 Cursor나 GitHub Copilot 같은 AI 코딩 도구들은 이런 변화를 가속화하고 있습니다. 이제 코드를 짜는 속도는 중요하지 않습니다. AI가 짠 코드를 검증하고, 전체 아키텍처 속에서 이 코드가 어떤 역할을 하는지 판단하는 '눈'이 중요합니다.

저는 이것을 '아키텍트형 개발자'로의 진화라고 부르고 싶습니다. 단순히 기능을 구현하는 '구현자'에서, 시스템 전체를 조망하고 최적의 솔루션을 조합하는 '설계자'가 되어야 합니다. 풀링포레스트가 추구하는 인재상 또한 그렇습니다.

변화는 두렵습니다. 내가 힘들게 배운 기술이 쓸모없어지는 것 같은 허탈감이 들 수도 있습니다. 하지만 관점을 바꾸면 이것은 엄청난 기회입니다. 예전에는 수십 명의 개발자가 필요했던 서비스를 이제는 서너 명의 영리한 개발자가 만들어낼 수 있는 시대가 되었습니다. 여러분이 그 영리한 개발자가 되지 못할 이유는 없습니다.

오늘부터 여러분의 웹개발 학습 리스트에 '구현'뿐만 아니라 '통합'과 '설계'라는 키워드를 추가해 보시는 건 어떨까요? 코딩은 더 쉬워지고, 여러분이 만들 수 있는 가치는 더 커질 것입니다. 저와 풀링포레스트도 그 길을 먼저 걷으며, 겪은 시행착오와 배움을 계속 나누겠습니다.

개발자로서의 성장이 기술의 깊이를 넘어, 문제를 해결하는 시야의 확장으로 이어지기를 응원합니다.