소프트웨어는 비즈니스를 위해 존재해야 하며, 그 반대가 되어서는 안 된다.

Source: Dev.to

The Problem

저는 너무 많이 보아왔습니다: 비즈니스가 아직 검증조차 하지 않은 문제를 위해 완벽하고 확장 가능한 아키텍처를 만든 경우를. 그 결과는? 아무도 사용하지 않는 기술 걸작.

스타트업 세계에서는 코드가 비즈니스 문제를 해결하기 전까지는 부채입니다.

고객은 여러분이 클린 아키텍처를 사용하든 지저분한 모놀리스를 사용하든 신경 쓰지 않습니다. 그들은 버튼이 작동하고 그들의 고통을 해결하는지에 신경 씁니다.

비즈니스가 피벗하면(그럴 겁니다), 여러분의 코드는 그 변화를 따라갈 수 있을 만큼 유연해야 합니다—이동을 방해할 정도로 경직돼서는 안 됩니다.

우리는 종종 10명밖에 없는 상황에서 1 백만 사용자를 위해 구축합니다. 이것이 바로 “소프트웨어가 비즈니스를 앞서는” 경우입니다.

Why Business Should Lead

• “지저분한” 코드가 있더라도 성공적인 비즈니스를 갖는 것이 “완벽한” 코드만 가진 실패한 스타트업보다 낫습니다.
• 시니어 개발자의 역할은 단순히 함수를 작성하는 것이 아니라 비즈니스 모델을 이해하는 것입니다. 회사가 어떻게 돈을 버는지 모르면 그에 맞는 효과적인 소프트웨어를 만들 수 없습니다.
• “우리는 어떻게 이것을 만들 수 있나요?” 대신 “우리는 이것을 만들어야 할까요?” 라고 질문하세요. 비즈니스 목표가 git 커밋을 주도하도록 하세요.

Key Takeaways

• 검증된 비즈니스 요구와 소프트웨어 개발을 맞추세요.
• 피벗을 수용할 수 있도록 유연성을 우선시하세요.
• 아키텍처의 순수성보다 고객에게 가치를 제공하는 데 집중하세요.

원래는 보다 캐주얼하고 지역적인 맥락(말레이어)에서 제 블로그에 공유한 내용입니다: 원문을 여기서 읽어보세요.