소프트웨어개발의 본질은 코드를 쌓는 것이 아니라 문제를 지우는 것입니다

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

주니어 시절, 저에게 좋은 개발이란 '우아한 코드를 작성하는 것'이었습니다. 디자인 패턴을 완벽하게 적용하고, 중복을 극단적으로 제거하며, 최신 프레임워크를 도입하는 것에 집착했죠. 코드가 아름다우면 프로덕트도 훌륭할 것이라고 믿어 의심치 않았습니다. 하지만 CTO로서 수많은 프로젝트를 리딩하고 실패를 맛본 지금, 저는 그 믿음이 반은 맞고 반은 틀렸다는 것을 알게 되었습니다. 오늘은 우리가 매일 하고 있는 '소프트웨어개발'이라는 행위의 진짜 목적에 대해 조금 깊은 이야기를 나눠보려 합니다.

화려한 기술 스택이 만든 텅 빈 결과물

몇 년 전, 꽤 야심 차게 시작했던 신규 프로젝트가 있었습니다. 당시 우리 팀은 업계에서 가장 핫하다는 기술들은 죄다 도입했습니다. 마이크로서비스 아키텍처(MSA)를 전면 도입하고, 프론트엔드부터 백엔드까지 모두 최신 버전의 언어와 프레임워크로 무장했죠. 개발자들은 신이 났습니다. 레거시가 없는 청정 구역에서 마음껏 기술적 기교를 부릴 수 있었으니까요.

하지만 프로젝트 시작 3개월 후, 우리는 심각한 위기에 봉착했습니다. 코드는 완벽에 가까웠지만, 정작 비즈니스 로직은 엉성했습니다. 배포 파이프라인은 복잡하기 그지없어 기능 하나를 수정하고 배포하는 데 한나절이 걸렸습니다. 무엇보다 치명적인 건, 우리가 만든 기능이 고객이 진짜로 원하는 기능이 아니었다는 사실이었습니다. 우리는 '어떻게(How)' 만들 것인가에 취해, '무엇을(What)' 그리고 '왜(Why)' 만들어야 하는지를 잊고 있었던 겁니다.

결국 그 프로젝트는 출시 일정을 두 번이나 미루고 나서야 겨우 세상에 나왔지만, 시장의 반응은 냉담했습니다. 화려한 기술 스택이 고객의 만족도를 보장해주지는 않는다는 것을 뼈저리게 느낀 순간이었습니다.

코드는 목적이 아니라 수단일 뿐입니다

이 실패를 통해 제가 얻은 가장 큰 깨달음은 단순합니다. 소프트웨어개발의 본질은 코드를 작성하는 것이 아니라, 현실의 문제를 해결하는 것이라는 점입니다.

우리가 작성하는 코드는 결국 비즈니스의 가치를 전달하기 위한 운송 수단에 불과합니다. 트럭이 아무리 멋지고 엔진 성능이 좋아도, 싣고 가야 할 짐을 목적지에 제시간에 배달하지 못하면 그 트럭은 쓸모가 없습니다. 개발자로서 성장하고 싶다면, 시야를 코드 에디터 너머로 확장해야 합니다.

풀링포레스트에서 우리는 엔지니어들에게 항상 이렇게 질문합니다. "지금 작성하고 있는 이 코드가 고객의 어떤 고통을 해결해주나요?" 만약 이 질문에 즉답하지 못한다면, 잠시 키보드에서 손을 떼고 기획자나 디자이너, 혹은 고객의 목소리를 다시 들어야 할 때입니다.

CTO가 제안하는 '진짜' 개발을 위한 체크리스트

그렇다면 우리는 어떻게 일해야 할까요? 단순히 기술 욕심을 버리라는 뜻은 아닙니다. 기술적 탁월함은 기본이되, 그 방향성이 비즈니스를 향해야 한다는 것입니다. 다음은 제가 우리 팀원들에게, 그리고 저 자신에게 항상 강조하는 세 가지 원칙입니다.

첫째, 기술 부채를 두려워하지 말고 '비즈니스 부채'를 경계하십시오. 코드가 조금 지저분하더라도 고객에게 가치를 빠르게 전달하고 피드백을 받을 수 있다면, 그것이 더 좋은 소프트웨어개발 방식일 수 있습니다. 완벽한 아키텍처를 설계하느라 2주를 쓰는 것보다, 조금 헐거운 구조라도 3일 만에 프로토타입을 내놓고 시장의 반응을 보는 것이 낫습니다. 기술 부채는 나중에 갚을 수 있지만, 타이밍을 놓쳐 생긴 비즈니스 부채는 회사를 문 닫게 만들 수도 있습니다.

둘째, '삭제하는 용기'를 가지십시오. 우리는 무언가를 더하는 것에 익숙합니다. 기능을 추가하고, 테이블을 늘리고, API를 새로 만듭니다. 하지만 최고의 코드는 '없는 코드'라는 말이 있습니다. 유지보수 비용이 0이기 때문이죠. 불필요한 기능을 걷어내고, 복잡도를 낮추는 작업은 새로운 기능을 만드는 것만큼이나 중요하고 어려운 일입니다. 문제를 해결하기 위해 코드를 짜는 것이 아니라, 코드를 짜지 않고도 문제를 해결할 방법은 없는지 먼저 고민해보세요.

셋째, 소통 비용을 아키텍처 비용보다 중요하게 여기십시오. MSA가 유행이라고 해서 무작정 도입하면, 네트워크 레이턴시보다 팀 간 커뮤니케이션 레이턴시가 더 큰 병목이 됩니다. 조직의 규모와 역량에 맞는 구조를 선택해야 합니다. 모놀리식 구조가 나쁜 것이 아닙니다. 우리 팀이 가장 빠르고 효율적으로 협업할 수 있는 구조가 최고의 아키텍처입니다.

결국은 사람을 향합니다

지금도 많은 개발자분들이 더 나은 코드를 위해 밤을 지새우고 계실 겁니다. 그 열정은 정말 소중합니다. 하지만 가끔은 고개를 들어 내가 지금 풀고 있는 문제가 진짜 문제인지 확인해보셨으면 좋겠습니다.

풀링포레스트는 AI를 통해 일하는 방식을 혁신하고 있지만, 그 기저에는 항상 '사람의 문제를 해결한다'는 철학이 깔려 있습니다. 기술은 계속 변합니다. 어제 썼던 프레임워크가 내일은 레거시가 될 수도 있습니다. 하지만 '문제를 해결하여 가치를 만든다'는 소프트웨어개발의 본질은 변하지 않습니다.

여러분이 작성하는 한 줄의 코드가 누군가의 시간을 아껴주고, 누군가의 불편함을 해소해주는 강력한 도구가 되기를 바랍니다. 기술적 성취감과 비즈니스 임팩트, 두 마리 토끼를 모두 잡는 현명한 엔지니어가 되시길 응원합니다.