휴학을 하며 해보고 싶었던 것들 중 하나는 블로그를 쓰는 것이었다.
들어가며
1학년 때부터 수많은 프로젝트를 진행해오면서, 나는 한 가지를 믿어왔다.
코드는 처음부터 완벽하게 짜야 한다. 단일 책임 원칙을 지키고, 유지보수성이 뛰어나야 진짜 코드다. 일단 돌아가게 만드는 방식은 실무에서 절대 쓸 수 없다.
그렇게 생각하고 있었다.
그런데 회사에 들어오고 실무에서 이를 적용하려니 많은 생각이 들었다.
두 가지 방식
기획을 세우는 방식에 크게 두 가지가 있다고 생각한다.
방식 1 처음부터 완벽하게
- 단일 책임 원칙(SRP) 준수
- 기능별 완전한 분리
- 변경 가능성 미리 고려
- 유지보수 용이한 구조
방식 2 일단 돌아가게
- 하드코딩 허용
- 하나의 화면에 여러 기능
- 구조보다 배포 우선
- 추후 리팩토링 예정
나는 오랫동안 방식 1만이 정답이라고 생각했다.
방식 2는 실무에서 쓸 수 없는 코드고, 그런 식으로 기획하는 건 무책임하다고까지 생각했다.
그 믿음이 실무에서 어떻게 부딪혔는지 이야기해보려 한다.
개발자의 SRP vs 기획자의 SRP
단일 책임 원칙(SRP)은 객체지향 설계에서 나온 개념이다. 하나의 클래스, 하나의 함수는 하나의 역할만 해야 한다는 원칙.
근데 이 원칙을 어떤 관점에서 바라보느냐에 따라 의미가 완전히 달라진다.
개발자의 SRP는 코드 구조의 문제다. 함수 하나가 DB 조회, 비즈니스 로직, 응답 포맷팅을 동시에 하고 있으면 안 된다. 역할이 분리되어야 변경이 생겼을 때 영향 범위가 최소화된다.
기획자의 SRP는 집중의 문제다. 지금 이 시점에 검증해야 할 것에만 집중해야 한다. 아직 필요하지 않은 것까지 미리 완성하려는 시도는 오히려 전체 흐름을 무겁게 만든다.
쿠폰 기능을 예로 들어보면,
개발자 입장에서는 발급·적용·중복 방지·만료 처리를 각각 분리된 모듈로 설계하는 게 맞다. 지금 발급만 필요하더라도.
- CouponService
- CouponValidator
- CouponRepository
- CouponExpiryScheduler
근데 기획자 입장에서 쿠폰이 실제로 쓰일지 검증도 안 된 상태에서 모든 플로우와 예외 케이스를 미리 문서화하는 건?
- 쿠폰 발급 플로우
- 쿠폰 적용 예외 처리
- 만료 알림 정책
- CS 대응 매뉴얼...
둘 다 꼼꼼함에서 출발하지만, 기획에서의 완벽함은 때로 속도를 죽인다.
실무에서 마주친 피드백
회사에서 내일배움카드(내배케) 도입 관련 운영 매뉴얼 작업을 맡았다.
어차피 정리해야 할 내용이라면 처음부터 완벽하게 해두자는 마음으로 임했다.
목차를 꼼꼼하게 구성하고, 기존 매뉴얼에 내용이 있으면 백링크로 연결하고, 없는 내용은 플로우까지 직접 작성했다. 한눈에 보기 쉽도록 구조도 다듬었다.
그런데 돌아온 피드백은 저희는 에자일하게 진행해야 한다. 워터풀
꼼꼼하게, 완벽하게 하려고 했던 건데. 그게 왜 문제일까?
이후로 이사님과 여러 번 회의를 진행했다. 처음엔 솔직히 잘 이해가 안 됐다. 내가 잘못하고 있다는 건 알겠는데, 뭐가 어떻게 다른 건지 감이 오지 않았다.
그렇게 회의를 반복하면서 조금씩 가닥을 잡아가고 있는 중이다. 지금은 80% 정도 진행된 상태다.
그래서, 뭐가 달랐던 걸까
내가 내린 결론은 이거다.
나는 개발자의 시선으로 기획을 하고 있었다.
코드에서 처음부터 완벽하게 구조를 잡는 건 맞다. 근데 기획에서 "완벽함"의 기준은 다르다. 기획에서의 완벽함은, 지금 필요한 것을 가장 빠르게 검증할 수 있는 형태로 만드는 것이다.
워터폴은 처음부터 전체 계획을 세우고, 그대로 실행하는 방식이다. 내가 한 게 딱 그거였다.
애자일은 작은 단위로 빠르게 실행하고, 피드백을 받아 수정하면서 나아가는 방식이다.
이 차이가 방법론의 차이가 아니라 사고 방식의 차이라는 걸 이번에 실감했다.
(애자일과 워터폴에 대한 이야기는 별도 글로 정리할 예정이다.)
생각이 바뀐 것, 바뀌지 않은 것
방식 2가 무조건 틀렸다는 생각은 이제 버렸다. 맥락이 있다는 걸 알았다.
그렇다고 방식 1이 틀린 건 아니다. 코드에서 구조를 잡고, SRP를 지키고, 유지보수성을 고려하는 건 여전히 중요하다.
달라진 건 이거다.
언제 어떤 방식을 쓸지 판단하는 것 자체가 능력이라는 것.
지금 배포가 먼저인 상황인가, 구조를 잡아야 하는 상황인가. 지금 검증이 필요한가, 설계가 필요한가. 그 맥락을 읽는 것. 그게 기획이고, 그게 실무인 것 같다.
대학교 때는 그 맥락을 읽을 일이 별로 없었다. 항상 "좋은 코드"가 목표였고, 구조의 완성도가 더 중요했다. 그 기준을 실무에 그대로 가져왔던 것 같다.
아직 80%밖에 안 됐지만, 완성되면 다시 회고해볼 것 같다.
아직 배우는 중이라 틀릴 수도 있지만, 이게 지금 내 생각이다.