Hacker News • 55일 전

LLM 코딩 시대, 마이크로서비스가 늘어나는 이유

IMP

7/10

핵심 요약

최근 LLM을 활용한 코딩 환경에서 마이크로서비스가 급증하는 현상과 그 원인을 분석한 글입니다. 마이크로서비스는 외부와의 계약(Contract)만 유지되면 내부적으로 대규모 리팩토링을 자유롭게 할 수 있어 AI의 코드 수정에 매우 유리한 구조이기 때문입니다. 장기적인 유지보수의 어려움에도 불구하고, 조직 내 검토를 덜 거치고 빠르게 개발할 수 있다는 현실적인 이유 때문에 계속해서 선호되는 추세입니다.

번역된 본문

LLM으로 코딩한다는 것은 마이크로서비스가 더 많아진다는 뜻일까? 2026년 4월 5일

최근 직장에서 마이크로서비스가 급증하는 초기 징후를 목격했습니다. LLM의 도움을 받아 코딩하다 보면 자연스럽게 작은 마이크로서비스 형태로 흘러가는 것 같으며, 거대한 백엔드 시스템은 이를 특정 작업에 사용하게 됩니다. 예를 들어, 이미지 및 비디오 생성 AI 모델을 처리하는 마이크로서비스가 그렇습니다.

마이크로서비스는 매우 명확하게 정의된 표면적(Surface area)을 가집니다. 서비스로 들어오는 모든 것(요청)과 나가는 모든 것(응답, 웹훅)이 명시적으로 정의되어 있습니다. 즉, LLM이 서비스 내부에서 대규모 리팩토링을 마음껏 하도록 두더라도, 외부와의 계약(Contract)만 동일하게 유지된다면 내부 구조는 중요하지 않다는 뜻입니다. 마이크로서비스에는 자체 데이터베이스, 캐시, 객체 스토리지가 있을 수 있지만, 이를 호출하는 입장에서는 신경 쓸 필요가 없습니다. 일종의 방공호(그 안에서 클로드(Claude) 모양의 폭탄을 터뜨릴 수 있는)와도 같습니다.

모놀리식(Monolith) 구조로 코딩할 때는 암묵적인 결합(Coupling)을 걱정해야 합니다. 작업을 수행하는 순서나 캐시 키의 이름이 모놀리식 아키텍처의 다른 부분에서 암묵적으로 의존하고 있을 수 있습니다. 경계를 넘나들며 애플리케이션의 여러 부분을 미묘하게 얽히게 만들기가 훨씬 쉽습니다. 물론 숙련된 개발자라면 그런 유지보수 불가능한 짓을 하지 않겠지만, 동료들은 그렇게 성스럽지 않을 수 있습니다(실수를 할 수 있습니다). 마이크로서비스는 이러한 결합의 위험이 훨씬 적습니다. 클로드가 원하는 대로 하도록 두어도, 서비스가 계속 같은 방식으로 동작하기만 한다면 외부 세계는 신경 쓰지 않습니다.

조직의 관점에서 볼 때, 마이크로서비스가 '가장 저항이 적은 길'이 되는 추가적인 이유가 있습니다.

별도의 GitHub 리포지토리에 있으면 PR(Pull Request) 리뷰에 대한 감시가 줄어들어(또는 메인 브랜치에 바로 커밋할 수도 있어) 더 빠르게 반복 개발을 할 수 있습니다.
프로덕션 데이터 및 인프라에 훨씬 쉽게 접근할 수 있습니다. 보통 메인 프로덕션 데이터베이스는 일반 엔지니어가 연결하기 어렵게 엄격하게 통제되지만, 마이크로서비스의 인프라는 그토록 중요하게 보안을 유지해야 한다고 여겨지지 않기 때문입니다.

물론 마이크로서비스의 급증은 장기적으로 볼 때 더 안 좋고 유지보수하기도 더 어려울 수 있습니다. 수십 개의 앱(모두 자체 결제 계정, 호스팅 설정 및 리소스를 가진)을 보유하게 되면, Vercel에 호스팅된 이미지 생성 마이크로서비스만 사용하는 OpenAI API 계정의 갱신을 잊어버리기가 매우 쉽습니다. 하지만 이러한 마이크로서비스가 바로 저항이 가장 적은 길인 것입니다. 더 나은 실무 방식을 원한다면, 사람들이 원하는 모범 사례를 통해 원하는 결과를 더 쉽게 얻을 수 있도록 만들어야 합니다.

관련 포스트: AI는 웹 개발 학습의 장애물이다

원문 보기

원문 보기 (영어)

Does coding with LLMs mean more microservices? April 5, 2026 Recently, at work, I’ve seen the beginnings of a proliferation of microservices. It seems that LLM-assisted coding naturally flows towards small microservices, which the big backend uses for specific tasks. For example, a microservice that handles image and video generation AI models. A microservice has a very well-defined surface area. Everything that flows into the service (requests) and out (responses, webhooks) is defined explicitly. That means that you can let an LLM rip large-scale refactors inside of the service, and as long as the contract with the outside world remains the same, the inside does not matter. The microservice might have its own database, caches, and object storage, but the caller does not care. It’s a bomb shelter (within which you can detonate your Claude-shaped bomb). When coding in a monolith, you have to worry about implicit coupling. The order in which you do things, or the name of a cache key, might be implicitly relied-upon by another part of the monolith. It’s a lot easier to cross boundaries and subtly entangle parts of the application. Of course, you might not do such unmaintainable things, but your coworkers might not be so pious. A microservice has much less risk of coupling. Let Claude do whatever it wants, and the outside world doesn’t care as long as the service keeps behaving the same way. From an organizational perspective, there’s additional reasons why a microservice can be the path of least resistance: Being in a separate GitHub repo, there’s less scrutiny on PR review (or you can commit straight to main ), meaning you can iterate faster Production data and infrastructure can be much easier to access — often the main production database is hard for everyday engineers to connect to, but a microservice’s infrastructure isn’t deemed so critical to secure A proliferation of microservices is probably worse and harder to maintain in the long term. When you have dozens of apps (all with their own billing accounts, hosting setups, and resources) it’s a lot easier to forget to renew that OpenAI API account that only your image-generation microservice hosted on Vercel uses. But these microservices are where the path of least resistance flows. If you want better practices, you have to make it easier for people to achieve their desired outcomes using your desired best practices. Related posts: AI is an impediment to learning web development

마이크로서비스 LLM 코딩 소프트웨어 아키텍처 모놀리식 리팩토링