이 코드를 구현하는 데 아마 5분 정도 걸렸던 것 같다. 코드 자체는 매우 간단해 보인다. 우리는 왜 추상화에 신경을 쓰는 걸까? 이렇게 API 계층에 모든 것을 넣으면 되지 않을까?

이러한 솔루션은 완벽한 설계가 필요하지 않은 시제품을 제작할 때 적합할 수 있다. 하지만 생산 시스템에서 이런 결정을 내린다면 신중해야 한다. 생산 시스템을 중단할 수 있는가? 몇 분 정도 사이트가 다운되어도 괜찮을까? 괜찮다면 사용해도 상관없다. 다른 팀원의 생각은 어떨까? API 계층의 유지 관리자가 이러한 SQL 쿼리를 여기저기에 넣는 것을 좋아할까? 테스트는 어떤가? 이 코드를 테스트하고 올바르게 실행되는지 확인하려면 어떻게 해야 할까? 여기에 새 필드를 추가하는 것은 어떤가? 다음날 사무실에서 벌어질 일을 상상해 보자. 사람들이 여러분을 안아주며 칭찬할까? 아니면 여러분의 책상과 의자에 압정을 박아둘까?

실제 데이터베이스 구조에 종속성을 추가한 꼴이 된 것이다. 코드에서 사용한 Messages 테이블이나 데이터베이스 기술의 레이아웃을 변경해야 하는 경우, 코드의 모든 부분을 확인하여 새로운 데이터베이스나 새로운 테이블 레이아웃과 함께 모든 것이 잘 동작하는지 확인해야 한다.