문제를 쪼개지 못하는 개발자에게

by 그릿 | GROWTH_ESSAY | 2026-07-30

멘토링을 진행하다 보면 복잡한 기능 구현 과제 앞에서 시작조차 못 하고 화면만 바라보는 주니어를 자주 만납니다. 3년 차 백엔드 개발자 A씨도 마찬가지였습니다. "결제 실패 시 재시도와 알림 발송 시스템 구축"이라는 과제를 받고 일주일 동안 코드 한 줄도 제대로 쓰지 못했습니다.

왜 일주일 동안 손도 대지 못했을까요? 모듈이나 기술 스택이 어려워서가 아닙니다. 거대한 문제를 다룰 수 있는 작은 단위로 쪼개지 않았기 때문입니다.

문제의 크기에 압도당하는 사람들의 특징

실력 발휘를 못 하는 주니어의 공통점은 구현 목표를 통째로 삼키려 한다는 점입니다. 결제 실패, 재시도 큐, 알림 메커니즘, 예외 처리를 한 번에 머릿속에 담고 코딩을 시작하려 합니다. 머리가 복잡해지니 어디서부터 손대야 할지 막막해집니다.

실무에서 만난 일 잘하는 개발자들은 다릅니다. 그들은 아무리 큰 요구사항도 가장 쉬운 단위 기능 하나로 먼저 잘라냅니다. "결제 실패 로그를 DB에 저장한다" 하나만 떼어내어 실행 가능한 최소 코드부터 만듭니다.

쪼개지 않은 코드는 테스트할 수 없다

문제를 쪼개지 못하면 테스트도 불가능합니다. 전체 로직이 다 만들어져야만 작동을 확인하려 하니, 버그가 터졌을 때 원인을 찾는 데 3일씩 걸립니다. 모듈 5개가 얽혀서 어디서 터졌는지 파악하기 힘들어지기 때문입니다.

하나의 메서드가 3가지 일을 한꺼번에 하고 있다면 이미 실패한 설계입니다. 알림 발송 로직과 실패 처리 로직을 완전히 분리하고, 각각 따로 작동하는지 확인해야 합니다. 200명이 넘는 개발자를 멘토링하면서 본 성장의 핵심은 단 하나였습니다. 문제 분해 능력이 코드 품질을 결정합니다.

오늘 당장 종이와 펜을 드세요

키보드에 손을 올리기 전에 요구사항을 문장 3개로 쪼개어 적어보세요. 각 문장이 독립적으로 테스트 가능한 단위인지 확인해야 합니다.

거대한 시스템을 한 번에 만드는 천재는 없습니다. 복잡한 문제를 쉬운 문제 여러 개로 나눌 수 있는 사람만이 끝까지 구현을 마칩니다.