성공적인 프로그램 개발을 위해 시작 전 반드시 확인해야 할 체크리스트

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

"일단 만들고 생각하자."

스타트업이나 신규 프로젝트 팀에서 가장 많이 듣는 말이자, 가장 위험한 말이기도 합니다. 솔직히 고백하자면 저 역시 주니어 개발자 시절에는 이 말에 묘한 흥분을 느꼈습니다. 빈 화면에 코드를 채워 넣고 무언가 동작하는 걸 보는 그 즉각적인 보상이 좋았으니까요. 하지만 CTO로서 수많은 프로젝트의 흥망성쇠를 지켜본 지금, 저에게 이 말은 일종의 경보음처럼 들립니다.

코드를 짜는 시간보다, 코드를 짜기 전에 고민하는 시간이 프로젝트의 성패를 가릅니다. 오늘은 우리가 프로그램 개발을 시작하기 전에 반드시 짚고 넘어가야 할, 하지만 자주 간과하는 체크리스트에 대해 이야기해보려 합니다.

우리는 왜 '기술'부터 고민할까?

몇 년 전, 꽤 규모가 있는 신규 서비스 개발을 맡았을 때의 일입니다. 킥오프 미팅에서 팀원들의 눈은 반짝이고 있었습니다. 그리고 첫 회의의 주제는 자연스럽게 이런 것들로 흘러갔습니다.

"이번에는 MSA(Microservices Architecture)로 가야겠죠?" "언어는 요즘 핫한 Go를 써보는 게 어떨까요?" "DB는 NoSQL이 유연할 것 같습니다."

모두가 최신 기술 스택을 사용해 보고 싶어 했습니다. 저 또한 엔지니어로서 그 열정을 이해합니다. 하지만 정작 가장 중요한 질문은 빠져 있었습니다.

"우리가 해결하려는 문제가 정확히 무엇인가요?" "이 기술들이 지금 우리 비즈니스 규모에 꼭 필요한가요?"

결국 우리는 초반 3개월을 화려한 아키텍처를 구축하는 데 썼지만, 정작 고객이 원하는 핵심 기능은 제대로 구현하지 못했습니다. 복잡한 MSA 구조 때문에 배포 시간만 길어졌고, 팀원들은 낯선 언어를 배우느라 비즈니스 로직을 놓쳤습니다. 기술적 허영심이 빚어낸 참사였습니다. 뼈저리게 느꼈습니다. 프로그램 개발의 본질은 기술 과시가 아니라 문제 해결이라는 것을요.

코딩 전에 확인해야 할 3가지 질문 (Why, Who, What)

풀링포레스트에서는 새로운 프로젝트를 시작할 때, 아무리 급해도 이 세 가지 질문에 대한 답이 명확하지 않으면 IDE(통합 개발 환경)를 켜지 않습니다.

1. 왜 만드는가? (Why)

가장 근본적인 질문입니다. 이 프로그램이 해결하려는 문제는 무엇인가요? 단순히 "경쟁사가 하니까", "요즘 트렌드라서"라는 이유는 충분하지 않습니다.

예를 들어, 사내 정산 시스템을 만든다고 해봅시다. 단순히 '자동화'가 목표가 되어서는 안 됩니다. "매월 말일 재무팀이 야근하며 엑셀을 맞추는 시간을 3시간으로 줄이겠다"처럼 구체적인 고통(Pain Point)과 목표가 있어야 합니다. 목표가 명확해야 기술적 의사결정의 기준이 생깁니다. 재무팀의 시간 단축이 목표라면, 화려한 UI보다는 데이터의 정확성과 엑셀 호환성이 최우선 순위가 될 것입니다.

2. 누가 사용하는가? (Who)

사용자를 정의하는 것은 기술 스택 선정에 직접적인 영향을 줍니다. 주 사용자가 모바일 환경에 익숙한 20대인가요, 아니면 PC 환경에서 업무를 보는 50대 관리직인가요?

과거 한 프로젝트에서 현장직 근로자분들을 위한 앱을 개발한 적이 있습니다. 우리는 최신 트렌드에 맞춰 글씨를 작게 하고 여백을 많이 둔 세련된 UI를 만들었지만, 결과는 대실패였습니다. 현장에서는 장갑을 끼고 일하는 경우가 많아 작은 버튼을 누르기 힘들었고, 햇빛 아래에서는 흐릿한 폰트가 보이지 않았던 겁니다. 사용자의 환경(Context)을 이해하지 못한 개발은 아무리 코드가 깔끔해도 실패한 프로그램 개발입니다.

3. 무엇을 만들지 않을 것인가? (What Not to Do)

저는 이 질문이 가장 중요하다고 생각합니다. 개발자들은 욕심이 많습니다. 이것도 넣고 싶고, 저것도 넣고 싶죠. 기획자 역시 마찬가지입니다. 하지만 리소스는 언제나 한정적입니다.

MVP(Minimum Viable Product)를 정의할 때, '핵심 기능'을 정의하는 것보다 '이번 버전에 포함하지 않을 기능'을 명확히 하는 것이 훨씬 어렵고 중요합니다. "채팅 기능은 나중에", "관리자 대시보드는 일단 엑셀 다운로드로 대체"처럼 과감하게 덜어내는 용기가 필요합니다. 그래야만 핵심 가치에 집중할 수 있고, 일정 내에 안정적인 제품을 내놓을 수 있습니다.

기술적 체크리스트: 화려함보다 단단함을 위해

앞선 비즈니스적 질문들이 해결되었다면, 이제 기술적인 부분을 점검할 차례입니다. 여기서도 핵심은 '적정 기술'입니다.

• 데이터의 성격 파악하기: 데이터가 정형적인가요, 비정형적인가요? 트랜잭션의 무결성이 중요한 금융 데이터라면 RDBMS를, 유연한 구조가 필요한 로그 데이터라면 NoSQL을 고려해야 합니다. 무턱대고 유행하는 DB를 쓰지 마세요.

• 트래픽 예측과 확장성: 당장 100명이 쓸 서비스에 100만 명을 대비한 쿠버네티스 클러스터를 구축하는 것은 오버 엔지니어링입니다. 하지만 향후 확장이 필요할 때 코드를 전부 갈아엎지 않도록 모듈화는 신경 써야 합니다.

• 레거시와의 통합: 완전히 새로운 시스템은 드뭅니다. 기존 시스템과 어떻게 데이터를 주고받을지, 인증은 어떻게 통합할지 미리 고민해야 합니다. 개발 막바지에 API 연동 문제로 밤새우는 일을 막을 수 있는 유일한 방법입니다.

마치며: 결국은 소통의 문제입니다

오랫동안 CTO로 일하며 깨달은 것은, 프로그램 개발의 가장 큰 적은 기술적 난이도가 아니라 모호한 커뮤니케이션이라는 사실입니다. 개발 전에 나누는 치열한 토론과 합의는 낭비가 아닙니다. 오히려 가장 값싼 형태의 디버깅입니다. 코드를 다 짜고 나서 수정하는 비용보다, 기획 단계에서 말 한마디로 수정하는 비용이 훨씬 저렴하기 때문입니다.

지금 새로운 프로젝트를 앞두고 계신가요? 키보드에 손을 올리기 전에 잠시 멈추고, 팀원들과 커피 한 잔을 하며 물어보세요. "우리가 이걸 왜 만들고, 무엇을 버려야 할까요?" 그 대화 속에 성공적인 프로젝트의 열쇠가 숨어 있을 겁니다.

오늘도 풀리지 않는 문제와 씨름하는 모든 개발자분들을 응원합니다.