이 사이트가 지향하는 것

나는 좋은 소프트웨어 개발을 좋아한다.

특히 무언가를 수정할 때마다 운에 맡기는 느낌이 들지 않는 개발을 좋아한다.

시스템의 경계가 명확하고, 책임이 어디에 있는지 찾기 쉽고, 데이터 흐름을 이해할 수 있으며, 도메인 로직이 제자리를 가지고 있으면 개발 자체가 달라진다. 변경이 갑자기 쉬워지는 것은 아니다. 대신 이해할 수 있게 된다. 왜 이런 결정을 했는지 설명할 수 있고, 문제의 범위를 좁힐 수 있으며, 새로운 요구사항이 들어올 때마다 시스템 절반을 다시 발굴할 필요도 줄어든다.

그럴 때 소프트웨어 개발은 다시 하나의 기술처럼 느껴진다.

마법도 아니고, 영웅적인 밤샘 작업도 아니며, 매번 불이 난 뒤 뛰어다니는 일도 아니다. 경험과 주의, 좋은 도구, 그리고 명확한 판단을 통해 충분히 잘할 수 있는 전문적인 일이다.

이 사이트에서는 그런 이야기를 하고 싶다.

나는 어디에서 이런 관점을 얻었는가

내가 아키텍처를 바라보는 방식은 대부분 실제 프로젝트에서 만들어졌다.

오랫동안 규제가 강한 시스템을 다뤘다. 이런 환경에서는 소프트웨어가 오늘 동작한다는 사실만으로는 충분하지 않다. 시간이 지나도 이해할 수 있어야 하고, 유지보수할 수 있어야 하며, 검증 가능해야 하고, 누군가는 기술적 결정을 설명하고 책임질 수 있어야 한다.

시스템을 만들고 넘겨주는 것으로 끝난 적도 많지 않았다. 몇 년 동안 계속 개발했고, 안정화했고, 설계를 설명했고, 때로는 기존 결정을 지켜야 했으며, 수많은 변경을 함께 겪었다.

그래서 나는 첫 번째 Release만 보고 시스템의 품질을 판단하지 않는다.

오히려 3년, 5년, 7년 뒤가 더 중요하다. 사람이 떠났고, 요구사항은 바뀌었고, 규제는 늘었고, 팀도 여러 번 변했다. 어느 순간에는 당시 왜 그런 결정을 했는지 정확히 기억하는 사람도 거의 남아 있지 않는다.

그런데도 시스템을 이해하고 변경할 수 있다면, 적어도 꽤 많은 결정은 괜찮았다는 뜻이다.

그런 시스템에서 일하는 즐거움을 알고 있다.

반대의 경우도 충분히 경험했다.

어떤 프로젝트에서는 이미 불이 난 뒤에야 불려가는 사람이 되기도 했다. 변경 자체가 두려운 일이 되었고, Component는 모든 것을 알고 있었으며, Service는 작은 운영체제처럼 커졌고, Store는 너무 많은 일을 하면서도 자신의 책임을 제대로 설명하지 못했다.

나중에는 도메인 로직이 어디에 있는지조차 누구도 자신 있게 말하지 못했다.

그래도 시스템은 돌아갔다.

가끔은 그게 가장 긍정적인 평가이기도 했다.

이런 경험들이 내가 아키텍처를 보는 방식을 만들었다. 내가 항상 더 잘 안다고 생각해서가 아니다. 불을 여러 번 꺼 본 사람은 결국 화재 예방에도 관심을 가지게 된다.

왜 이 사이트를 만들었는가

Frontend Architecture는 자주 과소평가되거나 반대로 지나치게 신비화된다.

한쪽에서는 그냥 Frontend라고 생각한다. UI 조금, State 조금, API 몇 개, Component 몇 개. 어떻게든 되겠지.

다른 쪽에서는 Diagram, Principle, Buzzword와 새로운 “Clean Something”이 등장해야 비로소 Architecture라고 생각한다.

둘 다 충분하지 않다고 생각한다.

Frontend Architecture는 목적 그 자체도 아니고 코드 미인 대회도 아니다. 결국 중요한 것은 시스템이 내일도 이해되고, 변경될 수 있으며, 누군가 책임질 수 있도록 만드는 결정들이다.

그 결정들은 팀이 장기적으로 빠르게 움직일 수 있는지, 아니면 초반에만 빨라 보이는지를 좌우한다. 도메인 로직이 계속 보이는지, 아니면 Component, Service, Store 사이로 조금씩 사라지는지도 결정한다.

새로운 요구사항은 시스템에 자연스럽게 통합될 수도 있다.

아니면 당장 빈 공간이 있는 곳에 억지로 들어갈 수도 있다.

시스템은 성장할 수 있다.

그저 살이 붙기만 할 수도 있다.

이 사이트에서는 그 차이를 이야기하고 싶다. 가능하면 구체적으로, 필요할 때는 꽤 직접적으로 이야기할 생각이다. 적어도 Framework 홍보 글이 되지는 않았으면 한다.

내 관점은 오래 잘 유지된 시스템에서도 왔고, 결국 가장 안정적으로 돌아가던 것이 장애 대응 프로세스뿐이었던 시스템에서도 왔다.

여기에서 무엇을 이야기하고 싶은가

일반적인 Best Practice를 다시 정리하는 사이트를 하나 더 만들 생각은 없다.

이미 충분히 많다.

내가 더 관심 있는 것은 실제 프로젝트에서 Architecture가 어디에서 도움이 되고, 어디에서 조금씩 무너지기 시작하는가이다.

Component가 어느 날부터 전체 Use Case를 담당한다. Service는 먼지가 쌓이듯 Responsibility를 계속 모은다. Store는 Side Effect, Business Logic, ViewModel을 모두 품는다. Reactive Data Flow는 계속 추가되는 Imperative Shortcut 때문에 점점 설명하기 어려워진다.

Microfrontend도 잘못 사용하면 Boundary 문제를 해결하지 않는다. 기존의 Boundary 문제를 여러 Deployment로 나누어 놓을 뿐이다.

규제가 강한 시스템에서는 Traceability가 선택 사항이 아니다. 품질을 중요하게 생각하는 팀도 많지만, 정작 도끼를 갈 시간은 좀처럼 주어지지 않는다.

반대로 잘 작동하는 것들에도 관심이 많다.

명확한 경계, 좋은 이름, 작고 이해하기 쉬운 Context는 생각보다 큰 차이를 만든다. Domain Language는 오해를 줄여주고, Tests는 변경에 대한 신뢰를 준다. Store도 자신의 역할이 명확하면 매우 유용하다.

좋은 Interface는 필요한 것보다 더 많은 정보를 드러내지 않는다.

그리고 Legacy System에서는 처음부터 완벽한 답이 필요한 것도 아니다. 때로는 다음 변경을 가능하게 만들어 주는 현실적인 다리가 먼저 필요하다.

그래서 단순히 무엇이 나쁜지 말하고 싶지는 않다.

왜 그런 상태가 되었는지, 어떻게 알아챌 수 있는지, 이미 그렇게 된 뒤에는 어떻게 빠져나올 수 있는지가 더 흥미롭다.

아키텍처는 기술이다

소프트웨어 개발을 가끔 마법처럼 이야기하는 경우가 있다.

실제로는 훨씬 평범하다.

좋은 소프트웨어는 대부분 꽤 기본적인 것들에서 나온다. 명확한 용어, 이해할 수 있는 경계, 좋은 도구, 연습, Feedback, Mentoring, 경험, 그리고 모든 문제를 특별히 영리한 아이디어 하나로 해결하려 하지 않는 절제 같은 것들이다.

그래서 나는 Architecture를 현실과 떨어진 상아탑의 일이라고 생각하지 않는다.

시스템 수준에서 책임을 다루는 하나의 엔지니어링 기술이라고 생각한다.

Feature는 당연히 완성해야 한다.

다만 Architecture는 몇 가지 질문을 더한다. 이 책임은 어디에 있어야 하는가? 다음 변경이 오면 어떻게 되는가? Data Flow는 계속 이해할 수 있는가? 여기에서 어떤 Dependency가 생기는가? 나중에 되돌리기 어려운 결정은 무엇인가? 그리고 2년 뒤에는 누가 이 코드를 이해해야 하는가?

이런 질문이 개발을 자동으로 느리게 만들지는 않는다.

다만 단기적인 처리량을 장기적인 속도와 착각하지 않도록 도와준다.

AI 때문에 왜 더 중요해지는가

AI Tooling은 이미 소프트웨어 개발을 크게 바꾸고 있다.

코드를 더 빨리 만들 수 있고, 여러 가지 선택지를 시험하는 비용도 낮아졌다. Prototype은 아주 짧은 시간 안에 만들 수 있다. Coding Agent는 Task를 분석하고, 파일을 수정하고, Tests를 실행하고, 제안을 만들며, 이제는 Repository 전체에 걸친 꽤 큰 변경도 처리할 수 있다.

나는 이것을 매우 흥미롭게 보고 있고, 실제로도 많이 사용하고 있다.

하지만 Architecture Problem이 저절로 없어지는 것은 아니다.

명확한 Context는 사람에게만 좋은 것이 아니다. Module이 작고, Responsibility가 명확하며, 이름이 의도를 잘 드러내고, Tests와 Architecture Rules가 Feedback을 줄 수 있다면 AI도 훨씬 안정적으로 일한다.

구조가 나쁜 시스템이 Agent가 더 많은 파일을 수정할 수 있다는 이유만으로 갑자기 쉬워지는 것은 아니다.

모든 것이 모든 것과 연결되어 있다면, AI는 기존 문제를 더 빠르게 복제할 수도 있다.

반대로 경계가 명확하면 작업 공간도 훨씬 작아진다. Agent는 필요한 변경을 더 잘 찾을 수 있고, 기존 Pattern을 인식할 수 있으며, Tests를 더 효과적으로 활용하고, 제한된 Context 안에서 움직일 수 있다.

그래서 Coding Agent 시대에 좋은 Architecture가 덜 중요해진다고 생각하지 않는다.

다만 왜 필요한지에 대한 설명은 조금씩 바뀌고 있다고 생각한다.

명확한 Boundary, 명시적인 Knowledge, 그리고 자동으로 검증할 수 있는 Rule은 단지 전통적인 소프트웨어 품질을 위한 것이 아니다. Agentic Work를 신뢰할 수 있게 만드는 조건이기도 하다.

왜 이런 글을 쓰는가

물론 이 사이트에는 프로젝트를 오래 하면서 생긴 답답함도 조금 들어 있다.

오랫동안 소프트웨어를 만들다 보면 어쩔 수 없이 쌓인다.

하지만 그게 가장 중요한 이유는 아니다.

나는 좋은 소프트웨어 개발 자체를 좋아한다.

설명할 수 있는 시스템을 좋아하고, 수정할 때마다 새로운 놀라움을 주지 않는 코드를 좋아한다. 실제로 무언가를 보호하는 경계도 좋고, 팀이 같은 용어를 사용해 이야기할 수 있는 것도 좋다.

그리고 변경을 배포할 때 기도보다는 확신을 조금 더 줄 수 있는 Tests를 좋아한다.

Architecture 역시 변경을 막는 것이 아니라 변경을 가능하게 만들 때 가장 가치 있다고 생각한다.

그래서 Frontend가 싫어서 이 글들을 쓰는 것은 아니다.

오히려 반대다.

도메인 로직을 진지하게 다루는 Frontend를 좋아하고, 오늘만 동작하는 것이 아니라 앞으로의 변화를 받아들일 수 있는 시스템을 좋아한다.

새로운 요구사항이 올 때마다 “소프트웨어가 나중에도 바뀔 수 있다”는 사실을 처음 발견한 것처럼 반응하지 않는 시스템 말이다.

이 사이트가 하고 싶은 일

이 사이트는 반복해서 나타나는 Pattern을 조금 더 잘 보이게 만들고 싶다.

좋은 의도로 시작한 결정이 왜 나쁜 시스템으로 이어질 수 있는지 설명하고 싶다. Anti-Pattern에는 이름이 필요하지만, 그 이름이 곧 그것을 만든 사람에 대한 평가가 되어서는 안 된다.

Architecture Decision도 비교할 수 있어야 한다.

어떤 문제는 단순한 해결책이면 충분하다. 복잡한 설계가 자동으로 더 좋은 것은 아니다.

반대로 때로는 “단순하게 가자”는 말이 이미 존재하는 문제를 몇 달 더 미루겠다는 뜻이 되기도 한다.

그리고 항상 완벽한 해결책이 필요한 것도 아니다.

경계를 다시 나누는 비용이 너무 클 수도 있고, 문제를 너무 늦게 발견했을 수도 있다. Legacy System을 다시 변경 가능한 상태로 만들기 위해 먼저 다리를 놓아야 할 때도 있다.

모든 프로젝트에 DDD가 필요한 것은 아니다.

모든 팀에 Microfrontends가 필요한 것도 아니다.

모든 애플리케이션에 Store가 필요한 것도 아니고, 모든 문제에 Framework가 필요한 것도 아니다.

하지만 모든 시스템은 최소한 Responsibility가 어디에 있는지, Data가 어떻게 흐르는지, Domain Logic이 어디에 있는지, 어떤 Boundary를 지켜야 하는지는 알아야 한다.

Shortcut도 괜찮다.

다만 그중 어떤 것이 나중에 청구서를 보낼지는 대략 알고 있는 편이 좋다.

이 사이트가 아닌 것

이곳은 Developer를 비난하는 공간이 아니다.

좋은 Architect가 자동으로 더 뛰어난 Developer인 것은 아니다. 반대로 뛰어난 Developer가 자동으로 좋은 Architect가 되는 것도 아니다.

집중하는 영역이 다르다.

Development에는 기술적인 깊이, 정확성, 그리고 좋은 해결책을 실제로 구현하는 능력이 필요하다.

Architecture는 Responsibility, Boundary, Coupling, Changeability, Risk, 그리고 기술적 결정의 장기적인 영향까지 시야를 넓혀야 한다.

좋은 팀에서는 이 두 가지가 서로 보완된다.

팀에서 가장 뛰어난 Developer가 Architect가 아닐 수도 있다.

전혀 문제가 아니다.

서로의 강점을 알고, 상대의 역할을 진지하게 존중한다면 이런 조합은 오히려 매우 강할 수 있다.

이 사이트는 Tool Review 모음도 아니고, Framework를 숭배하는 곳도 아니다. Architecture Folklore를 만들 생각도 없고, “모든 것은 Clean해야 한다”는 연극을 할 생각도 없다.

실제 프로젝트에서 얻은 경험, 관점, Patterns, Anti-Patterns, Field Reports를 모아 놓은 공간에 가깝다.

어떤 것은 비교적 일찍 배웠고, 어떤 것은 훨씬 오래 걸렸다. 어떤 교훈은 압박 속에서 배웠고, 어떤 것은 보기 좋지 않은 임시 해결책을 거치면서 배웠다.

다음에는 모든 것을 완벽하게 하겠다는 것이 목표는 아니다.

조금 덜 순진해지는 것만으로도 충분히 좋은 출발이라고 생각한다.

내가 생각하는 Frontend Architecture는 Folder Structure에서 시작하지 않는다.

Component가 더 이상 모든 것을 알 필요가 없게 되는 순간부터 시작한다.