소프트웨어개발, 코드를 넘어 비즈니스를 짓는 일에 대하여

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

CTO라는 직함을 달고 일하다 보면 가장 많이 받는 질문 중 하나가 "좋은 개발이란 무엇인가요?"입니다. 주니어 시절의 저는 이 질문에 대해 1초의 망설임도 없이 이렇게 대답했을 겁니다. "버그 없고, 빠르고, 우아한 코드를 짜는 것이요." 틀린 말은 아닙니다. 하지만 10년 넘게 조직을 이끌고 수많은 프로젝트의 성공과 실패를 목격한 지금, 저는 그 답이 절반만 맞았다는 것을 뼈저리게 느낍니다.

오늘은 단순히 코드를 잘 짜는 것을 넘어, 진짜 가치를 만드는 소프트웨어개발에 대해 이야기해보려 합니다. 기술적 완성도에 집착하다 정작 중요한 것을 놓쳤던 제 부끄러운 실패담과 함께 말이죠.

솔직히 고백하자면, 저도 한때는 '기술 지상주의'에 빠져 있었습니다. 새로운 프레임워크가 나오면 무조건 적용해보고 싶었고, 기존의 안정적인 레거시 코드를 보면 뜯어고치고 싶어 손이 근질거렸습니다. 과거 제가 리딩했던 한 프로젝트에서의 일입니다. 당시 저희 팀은 굉장히 트렌디한 마이크로서비스 아키텍처(MSA)를 도입하기로 결정했습니다. 트래픽은 아직 미미했지만, "나중에 커질 것을 대비해야 한다"는 명분 아래 모든 것을 잘게 쪼개고 복잡한 이벤트 버스를 깔았습니다.

결과는 어땠을까요? 처참했습니다. 기능 하나를 수정하려면 5개의 서비스를 동시에 배포해야 했고, 디버깅을 하려면 로그를 찾아 삼만 리를 떠나야 했습니다. 개발자들은 시스템의 복잡도에 허덕이느라 정작 고객이 원하는 기능을 출시하는 속도는 점점 느려졌습니다. 우리는 '우아한 아키텍처'라는 환상 속에 갇혀, 비즈니스의 본질인 '속도'와 '가치 전달'을 놓치고 있었던 겁니다.

그때 깨달았습니다. 소프트웨어개발은 예술 작품을 만드는 행위가 아니라, 현실의 문제를 해결하는 도구라는 사실을요. 아무리 정교한 코드라도 사용자의 문제를 해결해주지 못하거나, 비즈니스 타이밍을 놓치게 만든다면 그것은 죽은 코드나 다름없습니다.

그렇다면 비즈니스 가치를 만드는 개발은 어떻게 해야 할까요? 저는 풀링포레스트 팀원들에게 항상 'Why'에서 시작할 것을 주문합니다.

첫 번째는 '맥락(Context)의 이해'입니다. "이 기능을 왜 만들어야 하지?"라는 질문을 던져야 합니다. 단순히 기획서에 있는 대로 구현하는 코더(Coder)가 되어서는 안 됩니다. 이 기능이 우리 서비스의 어떤 지표를 움직일 것인지, 사용자의 어떤 불편함을 해소할 것인지 이해하고 개발하는 것과, 무작정 코드를 치는 것은 천지 차이입니다. 실제로 저희 팀에서는 개발자가 기획 단계부터 참여하여 "이 방식보다는 기술적으로 더 간단한 저 방식이 비용 대비 효과가 클 것 같다"고 역제안하는 문화가 자리 잡고 있습니다.

두 번째는 '적정 기술(Appropriate Technology)의 선택'입니다. 무조건 최신 기술, 무조건 대규모 아키텍처가 정답은 아닙니다. 현재 우리 팀의 규모, 서비스의 단계, 그리고 트래픽 상황에 딱 맞는 기술을 선택하는 것이 진짜 실력입니다. 스타트업 초기 단계라면 모놀리식 아키텍처로 빠르게 개발하고 배포하는 것이 훨씬 효율적일 수 있습니다. 기술 부채를 두려워하지 마세요. 감당할 수 있는 수준의 기술 부채는 성장을 위한 대출과도 같습니다. 중요한 건 언제 갚을지 알고 있는 것이죠.

세 번째는 '소통 비용의 최적화'입니다. 소프트웨어개발은 결국 사람이 하는 일입니다. 코드를 짜는 시간보다 동료와 대화하고, 스펙을 조율하고, 코드 리뷰를 하는 시간이 더 많을 때도 있습니다. 앞서 말씀드린 실패 사례에서도 가장 큰 문제는 팀원들 간의 소통 부재였습니다. 각자 맡은 서비스만 바라보느라 전체 시스템의 흐름을 놓쳤던 것이죠. 지금 풀링포레스트에서는 PR(Pull Request) 리뷰를 단순히 코드 스타일을 지적하는 자리가 아니라, 설계 의도를 공유하고 더 나은 비즈니스 로직을 고민하는 토론의 장으로 활용하고 있습니다.

개발자로서 성장하고 싶다면, 시야를 모니터 밖으로 넓혀야 합니다. 내가 작성한 코드가 서버에 올라가서 실제로 어떤 가치를 만들어내는지 상상해 보세요. 사용자가 버튼을 눌렀을 때 느끼는 쾌감, 데이터 처리가 빨라져서 운영팀이 절약하게 된 시간, 안정적인 서버 덕분에 안심하고 잠드는 경영진의 마음까지 헤아릴 줄 알아야 합니다.

물론, 기술적인 깊이를 포기하라는 말이 아닙니다. 탄탄한 기술력은 기본입니다. 다만 그 기술력이 '자기 만족'을 위한 것이 아니라, '문제 해결'을 향해 조준되어 있어야 한다는 뜻입니다.

지금 여러분이 작성하고 있는 그 코드는 어떤 문제를 해결하고 있나요? 혹시 미래에 올지 안 올지 모를 트래픽을 걱정하며 오버 엔지니어링을 하고 있지는 않은가요? 혹은 기획서의 문구 하나하나에 갇혀 더 좋은 해결책을 놓치고 있지는 않은가요?

소프트웨어개발은 혼자만의 고독한 싸움이 아닙니다. 비즈니스라는 거대한 숲을 함께 가꾸어 나가는 과정입니다. 기술이라는 강력한 도구를 손에 쥔 우리가, 그 도구를 어디에 어떻게 써야 할지 끊임없이 고민할 때 비로소 위대한 프로덕트가 탄생한다고 믿습니다.

오늘도 묵묵히 코드를 쌓아 올리며 자신만의 숲을 만들고 계신 모든 개발자분들을 응원합니다. 기술과 비즈니스의 경계에서, 우리 함께 더 나은 해답을 찾아 나갑시다.