아키텍처

이곳은 제가 개발을 마주하며 고민하고 검증해 온 아키텍처적 시도와 기록을 다루는 공간입니다.

처음 객체지향 프로그래밍(OOP)을 배우며 디자인 패턴을 접했을 때의 즐거움은 아직도 생생합니다. 어떻게 하면 더 견고하고 유연한 코드를 작성할 수 있을지 고민했고, '어떤 코드가 옳은가'에 깊이 몰두하기 시작했습니다. 자연스럽게 레이어드 아키텍처, 클린 아키텍처, 도메인 주도 설계(DDD) 등의 방법론을 탐독하며, 나름의 주관적 해석을 더해 코드에 적용하고 다듬어 나갔습니다.

실무에서 프론트엔드와 백엔드를 엄격히 분리하여 개발하다 보니, 개인 프로젝트를 진행할 때도 관성처럼 동일한 스택을 고수하곤 했습니다. 그러나 혼자 모든 것을 감당해야 하는 1인 개발 환경에서 고도화된 디커플드(Decoupled) 아키텍처는 이내 과도한 엔지니어링 비용으로 다가왔습니다. 결국 피로감을 느끼며 전통적인 백엔드 모놀리스 풀스택이나 하이퍼미디어 기반 아키텍처(HDA)처럼 실용성에 무게를 둔 방식으로 선회하기도 했습니다. 그 과정에서 프로젝트 규모와 인원에 맞는 설계가 존재하며, 1인 개발에서는 불필요한 구조적 비용을 덜어내는 것이 현실적인 해법이라는 나름의 기준을 세우기도 했습니다.

하지만 대형 언어 모델(LLM)의 등장으로 개발 환경은 다시 한번 급변했습니다. 어느 순간부터 세부 코드를 직접 작성하기보다는 AI와 대화하며 기능을 만들어가는 흐름이 일상이 되었습니다. 아키텍처 스택이 무엇이든 간에 구현 자체에 소요되는 시간의 격차는 크게 줄어들었고, 코드 한 줄 한 줄을 세밀하게 들여다보는 시간 또한 눈에 띄게 줄었습니다.

과거에는 긴 시간 동안 집중해 코드를 작성하는 과정 자체가 개발의 큰 즐거움이었습니다. 그러나 AI가 상당 부분의 구현을 더 빠르고 정교하게 대신해 주는 환경을 마주하면서, 전통적인 구현 방식에서 얻던 몰입의 즐거움은 희미해졌습니다. 직접 코드를 한 줄씩 작성하던 방식으로 되돌아가 보려 하기도 했지만, 효율의 격차를 실감한 뒤로는 지속하기 어려웠습니다.

문득 AI와의 대화 방식을 되돌아보며 제 행동 패턴을 관찰해 보았습니다. 코드는 AI가 생성해 주는데, 저는 AI와 무엇을 그렇게 집요하게 토론하고 있었을까요.

그것은 바로 '아키텍처'와 '경계'에 대한 질문이었습니다. AI가 인터넷에서 수많은 모범 사례를 가져오더라도, 프로젝트의 구조적 일관성과 패키지 간의 참조 방향, 모듈이 서로 협력하는 환경만큼은 온전히 개발자의 판단과 원칙에 달려 있었기 때문입니다. 미시적인 코드 조각이 아닌 거시적인 설계의 정합성을 조율하는 과정에서, 저는 개발자로서 새로운 흥미와 몰입의 대상을 발견했습니다.

이제 관심의 초점을 단순한 애플리케이션 수준의 구현을 넘어, 전체적인 시스템 구조와 경계 설계로 넓혀가려 합니다. 물론 여전히 조심스러운 부분도 많습니다. 더 많은 실전 경험과 시행착오를 거치며 성장해야 할 시기에 모든 구현을 자동화해 주는 도구를 접하다 보니, 자칫 얕은 경험의 틀 안에서 잘못된 설계를 정답으로 여길 수 있다는 우려도 있습니다. 대규모 분산 환경을 다뤄본 적이 없기에 마이크로서비스 아키텍처(MSA) 같은 거대한 개념은 논할 수도 없습니다.

그렇기에 더욱더, 제가 직접 겪고 검증한 현실적인 수준에서 아키텍처를 테일러링(Tailoring)하고 지속적으로 기록하려 합니다.

이곳은 절대적인 정답을 설파하는 곳이 아닙니다. 제가 마주한 문제와 그에 맞게 선택한 구조, 그리고 인식이 확장됨에 따라 설계를 점진적으로 개선해 나가는 과정을 투명하게 기록하는 공간입니다. 이 문서와 아키텍처 역시 완성된 결론이 아니며, 새로운 경험과 배움에 따라 언제든 고쳐질 수 있습니다.