복잡한 기능 요구를 분해해서 설계한 경험
팀 프로젝트에서 '알림 기능을 만들어 달라'는 요청을 처음 받았을 때 어디서 시작해야 할지 몰랐습니다. 요청 자체가 너무 넓어서 그냥 코드부터 짜기 시작하다가 중간에 설계를 전부 바꾼 경험이 있습니다.
그 이후로는 기능 요청을 받으면 먼저 '어떤 사용자가', '어떤 상황에서', '무엇을 원하는지'를 분해하는 습관을 들였습니다. 알림 기능을 다시 설계할 때는 알림 트리거 조건, 수신 대상 필터링, 발송 채널(앱 내·이메일)을 별도 컴포넌트로 분리하였고, 각각 독립적으로 테스트하였습니다.
처음보다 코드가 3배 길어졌지만, 이후 수정이 필요할 때 한 부분만 바꾸면 되었습니다.
복잡한 문제는 분해하지 않으면 어디가 문제인지 알 수 없다는 것을 그 경험에서 배웠습니다. 전체를 한꺼번에 다루려 하면 오히려 더 복잡해진다는 것도요. 지금은 설계를 먼저 도식으로 그려보고 코드를 시작하는 것을 기본으로 삼고 있습니다. 그 실패가 설계 방식을 바꾸는 계기가 되었습니다.