프론트엔드 엔지니어링

Architecture는 중요한 질문에 답할 수 있도록 도와줍니다.

시스템의 Boundary를 정의하고, Responsibility를 나누고, 시간이 지나도 변경할 수 있는 구조를 만드는 데 중요한 역할을 합니다.

하지만 좋은 Architecture만으로 좋은 Software Engineering이 완성되는 것은 아닙니다.

구조가 잘 나뉜 시스템도 Tests가 부족할 수 있습니다. 좋은 설계도 안정적이지 않은 Delivery Process 때문에 충분한 효과를 내지 못할 수 있습니다. Architecture Decision이 합리적이어도 Release할 때마다 불안하다면, 다른 부분을 함께 살펴볼 필요가 있습니다.

그리고 Code가 아무리 좋아도 팀이 그것을 안전하게 변경하는 방법을 모른다면 장기적으로 유지하기는 어렵습니다.

여기서 말하는 Frontend Engineering은 이런 영역을 다룹니다.

Code를 작성하는 것보다 넓은 이야기

Frontend Engineering은 Feature를 어떻게 구현할지만 다루지 않습니다.

실제 Frontend System을 개발하고, 검증하고, 배포하고, 관찰하고, 변경하고, 오랫동안 안정적으로 운영하기 위해 필요한 Engineering Practice 전체를 함께 봅니다.

Software Quality, Tests, Quality Gates, Code Reviews, CI/CD, Tooling, Technical Governance, Development Process 등이 여기에 포함됩니다.

Role과 Collaboration도 중요합니다. Team이 어떤 방식으로 Decision을 내리고, Knowledge를 어떻게 공유하며, 중요한 경험이 특정 사람에게만 남지 않도록 할 것인지도 Engineering의 일부입니다.

이런 주제들은 새로운 Framework나 눈에 띄는 Pattern만큼 화려해 보이지 않을 수 있습니다.

하지만 실제 프로젝트에서는 오히려 이런 부분이 시스템을 전문적으로 개발할 수 있는지 결정하는 경우가 많습니다.

Architecture가 계속 작동하기 위한 환경

Strategic Design과 Tactical Design이 주로 시스템 자체의 구조를 다룬다면, Frontend Engineering은 그 구조가 실제 개발 과정에서 계속 유지될 수 있는 환경을 봅니다.

전략적 프론트엔드 설계는 어떤 Boundary가 필요하고, 어떤 부분이 함께 변화해야 하며, 어떤 부분은 독립성을 가져야 하는지를 고민합니다.

전술적 프론트엔드 설계는 그 Boundary와 Responsibility가 실제 Code 안에서 어떤 형태를 가져야 하는지 살펴봅니다.

Frontend Engineering은 그 다음 질문으로 이어집니다.

변경이 정말 올바른지 어떻게 확인할 수 있을까요? 어떤 수준의 Quality를 목표로 해야 할까요? 어떤 Rule은 자동화하는 것이 좋을까요? 언제 Code Review만으로 충분하고, 언제 더 명확한 Verification이 필요할까요?

중요한 Knowledge가 특정 사람의 머릿속에만 남지 않도록 하려면 무엇이 필요할까요?

그리고 어떤 Tool이 실제로 일을 더 잘하게 만들어 줄까요?

Tooling은 새롭다는 이유보다, 실제 작업을 개선할 때 가치가 있습니다.

전문적인 Software Engineering은 여러 요소가 함께 만드는 결과입니다

Software Quality는 하나의 Practice만으로 만들어지기 어렵습니다.

Test 하나가 있다고 해서 Test Strategy가 완성되는 것은 아닙니다. Linter는 Architecture Understanding을 대신할 수 없습니다. Pipeline이 있다고 해서 Team이 자동으로 빨라지는 것도 아닙니다.

Quality Gate도 왜 그 Rule이 필요한지 아무도 이해하지 못한다면 장기적으로는 의미를 잃을 수 있습니다.

좋은 Engineering은 여러 작은 요소가 함께 작동하면서 만들어집니다.

좋은 Tool은 반복 작업을 줄여줍니다. 명확한 Process는 불확실성을 낮춥니다. Automation은 문제를 더 일찍 발견할 수 있게 해줍니다. Review는 Knowledge를 Team 안에 퍼뜨릴 수 있습니다. Documentation은 시간이 지나도 중요한 Decision을 이해할 수 있도록 도와줍니다.

그리고 때로는 새로운 Tool이나 Pattern보다 Responsibility를 조금 더 명확하게 만드는 것이 가장 큰 개선이 되기도 합니다.

Frontend Engineering은 이런 요소들이 함께 어떻게 작동하는지에 관심이 있습니다.

Role도 Engineering의 일부입니다

Software Development는 기술적인 Artifact만으로 이루어지지 않습니다.

사람마다 다른 Role을 맡고, 서로 다른 강점을 가지고 있으며, 같은 시스템도 다른 관점에서 바라봅니다.

Senior Developer가 자동으로 Software Architect가 되는 것은 아닙니다. Architect가 항상 Team에서 구현 능력이 가장 뛰어난 Developer일 필요도 없습니다. Tech Lead, Staff Engineer, Solution Architect 역시 서로 다른 범위의 Responsibility를 가질 수 있습니다.

이런 차이는 단순한 직함의 문제가 아닙니다.

어떤 Decision을 누가 맡는지, 어떤 관점을 기대하는지, Responsibility를 Team 안에서 어떻게 나누는지에 영향을 줍니다.

그래서 이 영역에서는 앞으로 Role, Responsibility, Collaboration도 함께 다루려고 합니다.

조직도를 설명하기 위해서가 아니라, 실제 개발 작업에서 서로 다른 역할이 어떻게 함께 일할 수 있는지를 이해하기 위해서입니다.

그리고 AI가 들어왔습니다

LLM과 Coding Agent는 이미 내 개발 방식에서 중요한 Tool이 되었습니다.

나는 이것을 새로운 Architecture Layer라고 생각하지 않습니다. 그렇다고 잠시 지나갈 주제라고 생각하지도 않습니다.

Software Engineering 안에서 사용하는 새로운 종류의 Tool에 가깝습니다.

매우 강력하지만, 여전히 Tool입니다.

Code를 만드는 속도를 바꾸고, 정보를 찾는 방법을 바꾸고, Requirement를 분석하는 방식도 바꾸고 있습니다. 자동화할 수 있는 작업의 범위도 계속 넓어지고 있습니다.

동시에 Verification, 명시적인 Knowledge, 명확한 Technical Boundary의 중요성도 커지고 있습니다.

그래서 AI와 Agentic Work는 Frontend Engineering에서 다루기에 자연스러운 주제입니다.

유행이라서가 아니라, 이미 실제 개발 작업의 일부가 되고 있기 때문입니다.

시리즈

Agentic Work in Real Life

이 영역의 첫 번째 큰 시리즈는 LLM, Coding Agent, Agentic Work를 전문적인 Software Engineering의 관점에서 다룹니다.

LLM과 Benchmark의 기본 개념에서 시작해 점차 Coding Agent를 실제로 사용하는 과정으로 이동합니다. Context, Memory, Requirements, Architecture, Data Protection, Verification, AI-friendly Software, 그리고 Agentic Work의 경제적인 영향까지 함께 살펴봅니다.

마지막에 중요한 질문은 어느 Model이 지금 Benchmark에서 가장 높은 점수를 받는가가 아닙니다.

Code를 만드는 비용이 계속 낮아진다면, Software Engineering의 다른 부분에서는 무엇이 더 중요해질까요?

이 시리즈는 AI를 과장해서 이야기하지도 않고, 반대로 의미 없는 것으로 취급하지도 않습니다.

실제로 사용하는 환경에서 Tool의 가능성과 한계를 살펴보는 것이 목적입니다.

앞으로 이 영역에서 다룰 것들

Frontend Engineering에서는 Architecture Diagram과 Production System 사이에 있는 다양한 Engineering Topic을 다루려고 합니다.

Quality와 Verification, Delivery와 Tooling, Development Process, Large-Scale Applications, Technical Governance, Role과 Responsibility, 그리고 계속 등장하는 새로운 Tool들입니다.

모든 주제가 거대한 이론을 필요로 하지는 않습니다.

어떤 문제에는 좋은 Method 하나면 충분할 수 있습니다.

어떤 문제에는 안정적인 Process가 더 중요할 수 있습니다.

그리고 어떤 경우에는 새로운 철학을 만들지 않고, 자신이 맡은 일을 조용히 잘하는 Tool이 가장 좋은 Tool일 수도 있습니다.