빠르게 만든 기능이 나중에는 팀의 속도를 늦추는 경우가 있습니다.

처음에는 한 파일에 여러 기능을 넣고, 화면에서 바로 데이터를 호출하고, 

외부 서비스의 응답을 제품의 핵심 로직에 연결합니다. 당장 하나의 기능을 만드는 속도는 빠릅니다.

그런데 시간이 지나면 작은 요구사항 하나가 여러 곳을 건드리게 되죠. 

담당자가 바뀌면 코드를 이해하는 데 시간이 오래 걸리고, 테스트 범위는 점점 넓어집니다.

 무엇 하나 바꾸기 전에 관련된 사람들에게 영향 범위를 물어봐야 하기도 해요.

이럴 때 설계 이야기를 꺼내면 두 가지 반응이 나옵니다.

“지금은 빨리 만들어야 하니 설계는 나중에 하죠.”

또 하나는 “이 원칙을 지키지 않으면 안 됩니다”라며 규칙부터 세우는 반응입니다.

둘 다 이해할 수 있습니다. 

초기 팀은 빠르게 고객을 만나야 하고, 제품이 커질수록 일정한 기준도 필요하니까요.