할수 있는 것과 하지 말아야 하는 것들

개발을 하다 보면 할 수 있는 일과 하지 말아야 하는 일이 나뉘는것 같아요. 대부분의 일들을 할 수 있는 일들이고, 사실 안되는 일들은 거의 없을 수도 있는거 같아요.

개발상으로 하면 안된다는 것은 수많은 선배들의 경험을 토대로 규칙과 같은 것들이 많이 정의되어 있어요. 예를 들어서 MSA를 한다면 각각의 도메인은 자신의 도메인 db 를 가진다는 것과 효율적 설계를 하기 위하여, db 테이블의 정규화 같은 것들이 그런 규칙인거죠. (코딩에도 다양한 규칙과 최적화를 위한 규칙들 같은게 있으니까요)

이러한 규칙은 우리가 개발을 함에 있어서 무엇이 최적화 이고, 무엇이 효율화인지. 그리고 관리와 추후 운영까지 생각하여 최선의 결과를 선택하기 위한 과정이라고 생각해요.

예를 들어 두개의 서로 다른 서비스 (도메인은 같음) 을 합친가고 가정을 하였을때 최적화를 위하여 각자의 다름을 인정하고, 공통화를 찾아서 최적화 할 수 있는지 보고, 합치는 것이 능사가 아닌 다름 자체를 인정하고, 통합이 답이 아닌 것도 최선의 선택이 될 수 있는거 같아요

하지만, 일은 일이기 때문에 시도를 해봐야 하는 상황이 올수도 있는데요.

딱 봐도 "응 이건 아니야" 라고 할 수 있는 것들을 시도 해야 할때, 할 수 있는 것과 하지 말아야 하는 것의 경계가 무너지기 시작하고, 업무 멘탈이 흔들리는 경우가 다수 인거 같습니다.

그렇기에 인정하긴 싫지만 "하지 말아야 하는 것" 들에 대해서 해보고 안되는 것과 안해보고 안되는 것의 차이를 상기하고, 시도를 해볼때가 있는데요.

결론은 대부분 이상하게 만들어지거나, 이상하게 설계가 되거나 하여, 되는 것 처럼 보이지만, "왜 이렇게 했지", "이건 뭐야~?" 와 같은 추후의 사이드 이펙트가 나오고 그에 대한 비판이 감당하는게 힘들때가 많은것 같습니다.