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

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

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

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

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

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

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

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

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

둘 다 이해할 수 있습니다. 

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

다만 설계를 개발자의 취향이나 코드의 미학으로만 이해하면 중요한 부분을 놓치게 됩니다.

좋은 설계는 오늘의 코드를 예쁘게 만드는 일이 아니라, 내일의 변경을 덜 비싸게 만드는 것이니까요.

설계는 변경의 범위를 정하는 기준입니다

제품은 계속 바뀝니다. 고객의 요구사항이 달라지고, 

처음에는 임시로 넣었던 기능이 핵심 기능이 되기도 합니다.

이 변화 속에서 필요한 것은 모든 미래를 예측하는 능력이 아닙니다. 

어디를 고쳐야 하는지, 무엇은 건드리지 않아도 되는지, 변경의 영향이 어디까지인지 알 수 있는 구조입니다.

SOLID 같은 설계 원칙도 같은 이유로 필요합니다. 

단일 책임 원칙은 하나의 모듈이 너무 많은 이유로 바뀌지 않도록 돕고, 

의존성 역전 원칙은 중요한 업무 규칙이 데이터베이스나 외부 API 같은 세부사항에 끌려가지 않게 합니다.

원칙보다 선택 이유를 남깁니다

그렇다고 모든 기능을 처음부터 완벽하게 나눠야 한다는 뜻은 아닙니다.

초기에는 낮은 비용으로 시작하고, 실제로 변경이 반복되는 지점부터 경계를 세워도 됩니다. 

중요한 건 원칙을 지켰다는 사실보다, 팀이 왜 그렇게 나눴는지 설명할 수 있는가입니다.

이 기준이 없으면 설계는 쉽게 논쟁이 됩니다. 한쪽은 “이게 더 깔끔하다”고 말하고, 

다른 쪽은 “지금은 과하다”고 말합니다.

반대로 변경 비용이라는 기준을 공유하면 대화가 달라집니다. 

이 기능은 앞으로 자주 바뀔 것인지, 다른 기능과 함께 바뀌어야 하는지, 

외부 시스템이 바뀌어도 핵심 업무는 그대로 남아야 하는지를 볼 수 있습니다.

업무 대화에도 경계가 필요합니다

제품의 코드에 경계가 필요하듯 팀의 업무에도 경계가 필요합니다.

업무 메신저의 한 대화 안에는 배경 설명, 결정, 담당자, 후속 액션, 진행 상태가 한꺼번에 섞여 있습니다.

대화가 이어지는 동안에는 모두가 맥락을 알고 있는 것처럼 보입니다.

하지만 시간이 지나면 결정만 남거나, 담당자만 기억나거나, 다음에 무엇을 하기로 했는지가 흐려집니다.

CROS Air가 집중하고 있는 문제도 여기서 출발했습니다. 

업무 메신저의 대화를 단순히 보관하는 것이 아니라, 

대화 속 결정과 실행 항목이 이어지도록 

업무 흐름으로 연결하는 일입니다.

기술 설계든 업무 설계든 핵심은 비슷합니다. 

모든 것을 한곳에 넣는 것이 아니라, 서로 다른 책임과 정보를 적절히 나누고 

필요한 순간에 다시 연결하는 것입니다.