어어, 수면교육은 진짜 되는 방법 있어요. 저도 첫째 때는 그런 거 잘 몰라서 안했는데, 둘째 때는 공부하고 제대로 수면교육했더니 산후조리원 나오고 사흘 만에 통잠 자기 시작했어요. 한국에는 좀 이상한 수면교육법이 퍼져 있는데, 제대로 배워서 하면 거의 실패가 없다고 해요.

https://twitter.com/drinking_dog_/status/1992929028312014860

심지어 첫째는 수면교육을 안해서 초3까지도 옆에 붙어서 한참을 재워야 했는데, 다 큰 애도 될까 싶어서 거의 비슷한 방법으로 해봤더니 첫째도 성공했어요. 영유아 키우는 엄마아빠들 꼭 수면교육하고 밤의 평안을 찾으시길.

그래서 개발자는 안된다고 말하기보다, 그 일에 따르는 비용과 리스크, 먼저 쌓여 있는 다른 일에 대해 설명해야 한다. 개발의 비전문가들은 되냐 안되냐로 물어보지만 그렇다고 개발자가 그 질문에 대해 Y/N로 답하면 안된다. 오렌지주스 테스트가 바로 이런 상황을 말하는 것이다.

https://twitter.com/Basix1120/status/1766727568269725832

물론 되냐 안되냐라고 물어보는 그 질문 자체도 나쁜 질문이다. 개발자가 아니라도 소프트웨어 개발을 이해하는 사람은 이렇게 질문하지 않는다. 운 좋게 개발자가 오렌지주스 테스트를 이해하는 사람이라면 우문현답으로 해피엔딩이 될 수 있지만, 대개는 그렇지 않다. 질문부터 달라져야 한다.

FK 이야기도 재미있는 이야기라 한 번 풀어본다. 일단 FK를 쓴다고 할 때의 FK는 논리적 의미의 FK가 아니라 보통 FK constraint를 말한다. 원래 DB는 FK 선언을 안해도 join이 가능하며, 인덱스만 똑같이 걸면 성능에는 아무런 차이가 없고, 논리적 FK와 동일하게 쿼리할 수 있다. 그러니까 FK를 안 쓴다는 건 그냥 FK 제약을 안 건다는 뜻이지, 논리적인 FK 설계를 안한다는 뜻은 아니다. 그럼 FK는 왜 필요하며, 또 왜 피하는가? 필요한 이유는 데이터 정합성 때문이다. FK 제약이 없으면 FK가 걸린 부모 row를 삭제해버릴 수도 있어서 졸지에 자식 row들이 고아가 될 수 있다.

백엔드가 API를 제공하고 프론트엔드에서 그 API를 사용하는 구조는 데이터를 주고 받는 과정에서 낭비가 많이 생긴다. 과거의 서버사이드 템플릿에서는 모델 코드를 그대로 템플릿에서 쓸 수 있었기 때문에 이런 낭비가 없었고, 이 차이가 전세계적인(?) 개발팀의 생산성 저하로 이어졌다. 이게 문제라는 사실을 인식도 못하고 있는 사람들이 대부분이라는 게 더 큰 문제지만, 다행스럽게도 이 문제를 집요하게 해결하려는 사람들이 존재한다. graphql도 이런 관점이 들어 있고, 아예 서버와 프론트엔드를 결합하는 풀스택 프레임워크도 있다. 나는 openapi의 접근법을 관심 있게 보고 있다.