LLM 시대에 병목은 더 이상 코드를 만드는 일이 아니라, 변화를 계획하고 조율하며 검토하고 배포하는 통합 능력에 있다는 글.
2026년 5월 26일 Andrew Halberstadt 작성, mozilla, llm, productivity에 게시
당신은 느꼈다. 그 전환을. LLM 덕분에 당신의 역할이 근본적으로 바뀌었다는 것을. 그것은 이제 PR을 얼마나 쉽게 쏟아낼 수 있는지 깨달았을 때 처음 무의식 속으로 스며들었다. 그리고 어느 날 아침 노트북을 열었을 때, 다른 사람들 역시 PR을 마구 쏟아내고 있어서 리뷰 대기열이 평소의 두 배가 되어 있는 것을 보며, 리뷰어로서 더 구체적으로(그리고 덜 반갑게) 그것을 느꼈다. 그리고 당신은 이 만연하고 전반적인 _마찰_의 감각을 느낀다.
이 _마찰_이 정확히 어디에서 오는지 콕 집어 말하기는 어렵다. 저장소 규모와 CI 설정에 따라 사람마다 조금씩 다를 것이다. 리뷰 시간이 더 길어지거나 리뷰 기준이 느슨해지는 문제일 수도 있다. 머지 충돌과 머지 관련 CI 실패가 더 많아지고 있음을 눈치채고 있을지도 모른다. 어쩌면 더 많은 실패가 main까지 스며들거나, CI가 결과를 내놓는 데 더 오래 걸리고 있을 수도 있다. 당신은 거의 확실히 이 _고됨_을 느끼고 있다. 사람들은 날카로워져 있고, 지쳐 있으며, 개발자들은 서로 반대 방향으로 잡아당기고 있다.
LLM이 바꿔 놓은 것은 이것이다. 병목은 더 이상 코드를 만들어내는 일이 아니다. 병목은 그것을 통합하는 일이다. 우리가 느끼는 마찰은 LLM 덕분에 가능해진 더 많은 PR, 더 많은 아이디어, 더 많은 리뷰, 더 많은 이견의 결과다. 짧게 말해, 이 문제는 Figure 1이 가장 잘 요약한다:
하지만 우리는 아직 많은 사람들이 이것을 깨닫지 못한 순간을 살고 있다. 그리고 여전히 자신의 일이 코드를 생산하는 것이라고 생각하고 있다.
그렇지 않다. 당신의 새로운 일은 그것을 통합하는 것이다.
당신의 첫 번째 본능은 버티면서 평소처럼 일을 진행하는 것일 수 있다. 결국 LLM이 기술 산업을 뒤흔든 첫 번째 대규모 혼란은 분명 아니며, 이 전략은 과거에 잘 통했으니 매우 합리적인 반응이다. 하지만 그것에는 꽤 큰 위험도 따른다. 업계 전반의 CEO들 역시 그 전환을 느꼈다. 그리고 그들은 실제로 행동하고 있다. 정확히는 일자리를 줄이면서 123. 결국 배포할 수 있는 속도보다 더 빨리 코드를 생산하는 데에는 아무 의미가 없다.
그렇다면 이에 대해 당신은 무엇을 할 수 있을까? LLM에 맞서 흐름을 되돌리는 것은 불가능하지만, 당신은 자신의 영향권 안에 있는 것은 통제할 수 있다. 그리고 그것은 당신의 새로운 역할과 그 안에서 어떻게 번성할지에 대한 솔직한 성찰에서 시작된다. 코드를 생산하는 일은 더 이상 예전처럼 희소한 자원이 아니다. 이제 희소한 것은 그것을 통합하는 능력이다.
당신의 새로운 역할은 변화를 통합하는 것이다. 이는 높은 품질 기준을 유지하면서도 가능한 한 효율적으로 변경 사항을 파이프라인을 통과시키는 것을 의미한다. 여기에는 실제 구현 이전, 구현 중, 구현 이후에 일어나는 작업이 모두 포함될 수 있다.
구현 전에 당신은 계획을 세우고 그것을 지지해야 한다. 이해관계자들과 함께 조건과 우선순위를 조율해야 한다. 다른 팀들과 협업하여 서로 다른 방향으로 끌려가지 않도록 해야 한다. 더 복잡한 변경의 경우에는 해법을 높은 수준에서 설계하고 아키텍처를 구상해야 한다.
구현 중에는 LLM을 올바른 경로로 이끌어야 한다. 받아들일 수 있는 구현안을 떠올리도록 돕고 그 상충관계를 이해하도록 해야 한다. 생성되는 동안 LLM의 출력을 검토해야 한다. 다른 리뷰어에게 설명할 수 있을 만큼 변경 사항을 테스트하고, 검증하고, 충분히 이해해야 한다. 필요하다면 방향을 수정하고 구현을 완전히 다른 경로로 전환할 준비가 되어 있어야 한다.
그리고 그 이후에는 실제로 변경 사항을 머지해야 한다. CI와 지표를 모니터링하고, 문제를 디버그하고 수정해야 한다. 문제를 빠르게 식별하고 성능 저하를 일으킨 변경 사항을 되돌릴 수 있어야 한다.
이 새로운 현실에서 프로세스와 파이프라인은 왕이 될 것이다. 기업들은 속도를 높이려 하면서 DevOps / Platform Engineering 유형의 팀에 더 높은 가치를 둘 것이다. 병목은 실제로 코드를 만드는 일에서 계획, 조율, 리뷰, CI, 배포로 옮겨갔다.
그 병목의 형태는 모든 조직마다 다르겠지만, 결과는 같다. 당신의 팀이 가장 큰 고통을 느끼는 곳이 어디든, 그것이 코드 리뷰든, 불분명한 방향성이든, 낮아진 품질이든, 바로 그곳에서 LLM이 당신의 도구와 프로세스를 앞질러 간 것이다. 바로 그곳에 해야 할 일이 있다.
이 새로운 시대에 번성하는 엔지니어는 그런 병목을 식별하고 해결할 수 있는 사람들이다. 그것은 더 나은 도구를 작성하는 것일 수도 있고, 더 명확한 기준을 세우는 것일 수도 있으며, 변경 사항이 파이프라인을 효율적으로 통과하도록 계속 움직이게 만드는 사람이 되는 것일 수도 있다.
전환은 이미 일어났다. 이제 그것을 통합하라.
