웹개발, 코딩이 아니라 문제 해결입니다: 주니어 시절 내가 놓쳤던 것들

솔직히 고백하자면, CTO라는 직함을 달고 있는 지금도 가끔은 등골이 서늘해질 때가 있습니다. 새벽 2시, 갑자기 울리는 슬랙 알림 소리에 심장이 덜컥 내려앉는 경험을 해보신 분이라면 제 말을 이해하실 겁니다. 화려한 기술 스택이나 복잡한 아키텍처 다이어그램 뒤에는 항상 '이게 정말 비즈니스 문제를 해결하고 있는가?'라는 본질적인 질문이 숨어 있기 때문이죠. 오늘은 제가 주니어 시절, 기술 그 자체에 매몰되어 정작 중요한 것을 놓쳤던 부끄러운 기억을 꺼내보려 합니다. 그리고 그 과정에서 깨달은 웹개발의 진짜 의미에 대해 이야기하고 싶습니다.

제가 처음 커리어를 시작했을 때, 저는 소위 말하는 '기술 덕후'였습니다. 리액트(React)의 새로운 훅(Hook)이 나오면 당장 적용해봐야 직성이 풀렸고, 백엔드에서는 아직 검증되지 않은 최신 프레임워크를 도입하자고 팀장님을 조르곤 했습니다. 당시 제 머릿속의 웹개발은 '최신 기술을 사용해 코드를 짜는 행위' 그 이상도 이하도 아니었죠.

그러던 어느 날, 잊을 수 없는 사건이 터졌습니다. 당시 우리 팀은 이커머스 서비스의 결제 페이지 개편을 맡고 있었습니다. 저는 성능 최적화라는 명목하에 프론트엔드 상태 관리 라이브러리를 전면 교체하고, 백엔드 API 구조를 제가 감명 깊게 읽은 해외 아티클 스타일로 뜯어고쳤습니다. 코드는 정말 우아했습니다. 변수명은 완벽했고, 컴포넌트 구조는 예술에 가까웠죠. 배포 버튼을 누르며 저는 속으로 쾌재를 불렀습니다.

하지만 배포 30분 후, 고객센터 전화기에 불이 나기 시작했습니다. "결제 버튼을 눌렀는데 반응이 없어요", "주문 내역이 안 보여요". 원인은 제가 도입한 화려한 상태 관리 로직이 특정 구형 브라우저에서 예외 처리가 제대로 되지 않아 발생한 문제였습니다. 더 심각한 건, 제가 바꾼 API 구조 때문에 데이터베이스 조회 쿼리가 비효율적으로 변경되어 트래픽이 몰리자 타임아웃이 발생하고 있었던 겁니다.

정말 뼈저리게 느꼈습니다. '내 코드가 예쁜 쓰레기였구나.' 회사의 매출에 직접적인 타격을 입히고 나서야 저는 기술 너머를 보기 시작했습니다. 웹개발은 단순히 브라우저에 무언가를 띄우는 작업이 아니었습니다. 사용자가 겪고 있는 문제를 기술이라는 도구로 해결해주는 과정, 그게 본질이었습니다. 아무리 최신 기술이라도 사용자의 결제를 방해한다면 그것은 잘못된 기술 선택입니다.

이 사건 이후 저는 개발을 대하는 태도를 완전히 바꿨습니다. "어떻게 구현할까(How)"를 고민하기 전에 "왜 이 기능을 만들어야 하는가(Why)"와 "이것이 사용자에게 어떤 가치를 주는가(What)"를 먼저 묻기 시작했습니다.

그렇다면 구체적으로 어떻게 일하는 방식을 바꿔야 할까요? 제가 팀원들에게, 그리고 과거의 저에게 해주고 싶은 조언은 다음과 같습니다.

• 비즈니스 도메인을 집요하게 파고드세요. 개발자는 코드를 짜는 사람이기 전에 비즈니스의 동반자입니다. 물류 시스템을 만든다면 물류 창고에서 박스가 어떻게 이동하는지 알아야 하고, 핀테크 서비스를 만든다면 돈의 흐름을 이해해야 합니다. 도메인 지식이 없는 상태에서 작성된 코드는 겉돌 수밖에 없습니다. 기획서에 적힌 기능 명세만 보지 말고, 기획자와 운영팀에게 "이 기능이 왜 필요한가요?"라고 귀찮을 정도로 물어보세요.

• 기술 부채를 두려워하되, 과도한 엔지니어링도 경계하세요. 주니어 시절의 저는 모든 코드를 완벽하게 짜려고 했습니다. 하지만 스타트업 환경에서는 '지금 당장 작동하는 코드'가 '3년 뒤에도 완벽할 코드'보다 중요할 때가 많습니다. 물론 스파게티 코드를 양산하라는 뜻은 아닙니다. 적정 기술(Appropriate Technology)을 찾는 안목을 길러야 합니다. 트래픽이 하루 100명인 서비스에 쿠버네티스와 마이크로서비스 아키텍처(MSA)를 도입하는 건 오버 엔지니어링일 확률이 높습니다. 현재 상황에 맞는 최선의 도구를 선택하는 것이 진정한 실력입니다.

• 커뮤니케이션 비용을 줄이는 코드를 작성하세요. 여기서 말하는 코드는 실제 소스 코드뿐만 아니라 문서화, 커밋 메시지, PR(Pull Request) 설명을 모두 포함합니다. 나 혼자 알아보는 천재적인 코드는 팀 전체의 생산성을 떨어뜨립니다. 동료가 내 코드를 이해하기 위해 내 자리에 찾아와 질문해야 한다면, 그건 실패한 구현입니다. 최근에는 Cursor나 Claude 같은 AI 도구를 활용해 주석을 달거나 복잡한 로직을 설명하는 문서를 자동으로 생성하는 것도 좋은 방법입니다. 저 역시 복잡한 레거시 코드를 분석할 때는 AI의 도움을 적극적으로 받고 있습니다.

마지막으로 강조하고 싶은 것은 '책임감'입니다. 내가 짠 코드가 실제 사용자에게 도달했을 때 발생할 수 있는 모든 시나리오를 상상해봐야 합니다. 엣지 케이스(Edge Case)는 상상력의 영역입니다. "설마 사용자가 이렇게 쓰겠어?"라는 안일한 생각이 시스템을 망가뜨립니다. 로그를 심고, 모니터링 대시보드를 구축해 내 코드가 라이브 환경에서 어떻게 숨 쉬고 있는지 지켜보는 것까지가 웹개발의 영역입니다.

지금 이 순간에도 수많은 기술이 쏟아져 나옵니다. Next.js의 새로운 버전이 나오고, AI가 코드를 대신 짜주는 시대가 되었습니다. 하지만 변하지 않는 사실은, 결국 그 기술을 선택하고 조합하여 현실의 문제를 해결하는 주체는 '사람'인 여러분이라는 점입니다.

화려한 기술 스택보다 중요한 것은 사용자의 불편함을 해소하려는 진심, 그리고 팀원들과 함께 더 나은 서비스를 만들어가려는 태도입니다. 오늘 작성하는 코드 한 줄이 누군가의 문제를 해결하고 있다는 자부심을 가지세요. 그것이 진짜 엔지니어링이고, 진짜 웹개발입니다. 저도 여러분과 같은 고민을 하며 오늘도 키보드 위에 손을 올립니다. 우리 모두, 코딩 기술자가 아니라 문제 해결사로 성장합시다.