비슷하지만 조금은 다른 코드가 점점 늘어나는 건 아름답지 않은 걸까요? 거의 다 완성되어갔을 때 진행하는 리팩터링은 무얼 기준으로 아름답게 바꿀 수 있을까요? 아름다운 분리는 무엇일까요? 아름답다라는 건 어떤 걸까요? 질문자님 스스로가 아름답다는 표현의 정의를 내릴 수 있어야 정말 아름다운 분리가 가능할 것 같습니다. 더 나아가서 꼭 분리가 필요한지 고민해보실 수 있을 것 같아요. 질문자님께서는 API / Service / Database 로 레이어를 분리하는 이유에 대해 알고 계신가요? 흔히들 아키텍처와 패턴을 학습하며 “이렇게 짜야 객체지향스러워.” 라는 코드에 자주 노출되다 보니 맹목적으로 비슷한 형태의 코드를 작성하고 “아름답군.” 라는 자기만족에 빠지는 것 같아요. 개발자들이 레이어를 분리하고, 도메인을 분리하고, 아키텍처를 학습하고, 패턴을 공유하는 모든 이유는 지금 코드를 짜는 내가 조금의 불편을 감수해서, 다음에 내 코드를 수정하는 다른 사람(먼 훗날의 자기자신)을 위해서라고 생각해요. 애플리케이션 특성에 알맞는 아키텍처를 적용해서 효용성을 끌어올리고, 코드를 수정할 때 사이드이펙트가 퍼져나가지 않도록 레이러와 도메인을 분리하고, 패턴을 만들고 공유해서 같은 학습수준을 갖춘 뒤 서로 읽기 쉬운 코드를 작성하고… 코드를 수정하는데 필요한 비용을 아껴 다른 곳에 몰두하고자 하는 선대 개발자들의 고민들입니다. 모두 유지보수와 관련되어 있습니다. 질문자님만의 애플리케이션을 먼 훗날 유지보수 할 필요가 있나요? 어제 짠 뭔가 비슷하지만 조금은 다른 코드가 오늘 유지보수에 방해 됐나요? 혹시 더 잘 짜여지는 부분은 없었나요? 마땅히 불편함이 느껴지는 부분이 없고, 내가 기대하는 동작을 성실히 수행하는 코드라면 이미 너무나 아름다운 코드인 것 같아요. 어제 짠 코드를 읽고 컨텍스트를 파악하는데 시간이 소요되고, 한 부분을 수정하면 여러 곳에서 사이드이펙트가 발생할 때 ‘이런걸 보완할 방법은 없을까…’ 생각을 떠올리면서 아키텍처나 디자인 패턴을 접하면 뛰어난 학습효과를 누릴 수 있을 것 같습니다. 관련해서 제 생각을 정리한 글이 있습니다. 도움이 되시면 좋겠네요! https://hyeon9mak.github.io/consider-oop/