웹개발, 코드를 넘어 비즈니스를 그리는 여정
10년 차 CTO가 전하는 웹개발의 본질. 단순한 코드 구현을 넘어 비즈니스 가치를 창출하는 개발자로 성장하기 위한 3가지 원칙과 실질적인 조언을 공유합니다.
송찬영
CTO
솔직히 고백하자면, 처음 개발을 시작했을 때 저는 화면에 무언가 그려지는 그 즉각적인 피드백에 매료되어 있었습니다. 버튼을 누르면 색이 바뀌고, 데이터를 입력하면 리스트가 채워지는 과정 자체가 마법 같았거든요. 당시 저에게 웹개발은 단순히 '기능을 구현하는 기술'에 불과했습니다. 하지만 10년이 넘는 시간 동안 크고 작은 조직을 거치며 CTO라는 자리에 오기까지, 저는 개발에 대한 관점이 완전히 깨지는 순간들을 숱하게 겪어야 했습니다. 오늘은 그중에서도 가장 뼈아팠던 실패와 깨달음, 그리고 지금의 제가 주니어 개발자들에게 꼭 해주고 싶은 이야기를 나눠보려 합니다.
주니어 시절, 저는 이른바 '기술 덕후'였습니다. 새로운 프레임워크가 나오면 밤을 새워 공부하고, 남들이 잘 쓰지 않는 최신 라이브러리를 프로젝트에 도입하는 걸 즐겼죠. 당시 팀에서 맡았던 커머스 플랫폼 리뉴얼 프로젝트가 기억납니다. 저는 성능 최적화라는 명목하에 당시 유행하던 복잡한 상태 관리 라이브러리와 마이크로 프런트엔드 아키텍처를 섣불리 도입했습니다. "이게 요즘 트렌드고, 확장성에 좋아요"라는 말로 동료들을 설득했죠.
문제는 배포 직전에 터졌습니다. 화려한 기술 스택으로 무장한 코드는 정작 비즈니스 로직의 예외 케이스를 제대로 처리하지 못했고, 운영팀에서 급하게 요청한 프로모션 배너 하나를 수정하는 데에도 반나절이 걸리는 기형적인 구조가 되어버렸습니다. 코드는 우아했을지 몰라도, 비즈니스의 속도를 기술이 발목 잡는 최악의 상황이었습니다. 당시 팀장님이 해주셨던 말씀이 아직도 귓가에 맴돕니다. "찬영 님, 우리가 만드는 건 예술 작품이 아니라 고객이 쓸 제품이에요."
그때 저는 머리를 한 대 맞은 것 같았습니다. 웹개발이라는 것이 단순히 브라우저에 무언가를 띄우는 일이 아니라, '고객의 문제를 기술로 해결하는 과정'이라는 본질을 놓치고 있었던 겁니다. 기술적 난이도에 심취해 정작 중요한 '왜(Why)'를 잊었던 거죠.
이후 저는 개발을 바라보는 시각을 완전히 바꿨습니다. '어떻게 구현할까(How)'보다 '무엇을 위해 만드는가(What & Why)'에 집중하기 시작했습니다. 기술 부채를 두려워하기보다, 비즈니스의 불확실성을 줄이는 도구로 기술을 활용하려 노력했습니다. 이 과정에서 얻은 몇 가지 중요한 원칙들이 있습니다.
첫째, '오버 엔지니어링'을 경계해야 합니다. 많은 개발자가 미래의 확장성을 고려한다는 핑계로 당장 필요하지 않은 복잡한 추상화 계층을 만듭니다. 하지만 스타트업 환경에서 비즈니스 요구사항은 매일 바뀝니다. 오늘 짠 완벽한 구조가 내일은 걸림돌이 될 수 있습니다. YAGNI(You Aren't Gonna Need It) 원칙은 단순히 코드를 적게 짜라는 말이 아닙니다. 현재의 문제에 가장 적합한, 가장 단순한 해결책을 찾으라는 뜻입니다.
둘째, 개발자는 '번역가'가 되어야 합니다. 기획자나 디자이너가 말하는 요구사항을 코드로 그대로 옮기는 건 누구나 할 수 있습니다. 진짜 실력 있는 개발자는 그 요구사항 이면에 있는 의도를 파악하고, 기술적인 관점에서 더 나은 대안을 제시할 줄 알아야 합니다. "이 기능은 구현이 어려워요"라고 말하기보다, "이 기능을 구현하려면 리소스가 많이 드는데, 현재 목표인 유저 확보를 위해선 이런 방식이 더 효율적일 것 같습니다"라고 말할 수 있어야 합니다. 이것이 바로 시니어와 주니어의 차이를 만드는 결정적인 태도입니다.
셋째, AI 도구를 적극적으로 활용하되 의존하지 않아야 합니다. 최근 저는 팀원들에게 Cursor나 Claude 같은 AI 도구 사용을 적극 권장합니다. 단순 반복적인 코드 작성이나 보일러플레이트 생성은 AI에게 맡기고, 개발자는 전체 아키텍처를 설계하고 비즈니스 로직의 정합성을 검증하는 데 시간을 써야 합니다. AI 시대에 웹개발자의 역할은 '코더(Coder)'에서 '아키텍트(Architect)'이자 '프로덕트 메이커(Product Maker)'로 진화하고 있습니다. AI가 작성한 코드가 왜 그렇게 동작하는지, 보안 이슈는 없는지 검증할 수 있는 눈을 기르는 것이 그 어느 때보다 중요해졌습니다.
이제 막 웹개발의 세계에 뛰어든 분들이나, 성장의 정체기를 겪고 있는 분들이라면 다음 체크리스트를 한번 점검해 보셨으면 합니다.
내가 작성한 코드가 비즈니스 목표 달성에 기여하고 있는가? 아니면 자기만족을 위한 코드인가?
기획서에 적힌 대로만 구현하고 있는가? 아니면 기획 의도를 파악하고 더 나은 제안을 하고 있는가?
새로운 기술을 도입할 때, 그 기술이 해결해 줄 문제와 도입 비용을 명확히 설명할 수 있는가?
운영팀이나 CS팀이 겪는 반복적인 문제를 기술로 해결해 주려고 시도해 본 적이 있는가?
기술은 결국 도구일 뿐입니다. 하지만 그 도구를 어떻게 쓰느냐에 따라 비즈니스의 운명이 바뀝니다. 화려한 기술 스택보다 중요한 건, 동료들과 소통하며 문제를 해결해 나가는 태도입니다. 저 또한 여전히 실수를 하고, 새로운 기술 앞에서 막막함을 느끼곤 합니다. 하지만 이제는 그 막막함이 두렵지 않습니다. 기술 너머에 있는 사람과 비즈니스를 볼 수 있게 되었으니까요.
여러분이 작성하는 한 줄의 코드가 누군가의 불편함을 해소하고, 세상에 작은 가치를 더하는 과정임을 잊지 마세요. 훌륭한 웹개발자가 된다는 건, 결국 훌륭한 문제 해결사가 된다는 뜻입니다. 오늘도 모니터 앞에서 고군분투하고 있을 여러분을 진심으로 응원합니다.
