에이전트가 코드를 짜는 시대, 엔지니어가 여전히 알아야 할 것: 기초·폭넓은 지식·필요할 때 깊이 파기

Here be monsters: What do you still need to know when agents do the work?

Oct 27, 2026•adrq•View Original

TL;DR Highlight

에이전트가 짠 코드의 오너십은 기초, 폭넓은 지식, 즉시 깊이 파는 능력에 달렸다

Who Should Read

코딩 에이전트가 짠 코드를 운영하며 어디까지 직접 이해해야 할지 고민하는 백엔드·풀스택 개발자

Core Mechanics

CI가 잡아낸 건 한 줄짜리 컴포넌트였다
- SonarQube가 App.tsx의 cyclomatic complexity(분기 수로 재는 코드 복잡도)를 경고했다.
- App.tsx는 약 30줄이었는데 그중 15줄이 컴포넌트 하나씩을 통째로 한 줄에 쓴 코드였다.
- Codex에게 SonarQube를 만족시키라고 하자 10개 파일로 쪼개서 CI가 통과했다.
오너십은 직접 짠 경험이 아니라 시스템 지도다
- 시스템 전체를 세세히 아는 게 아니라 어디를 파야 하는지 아는 고수준 지도가 필요하다고 말한다.
- '내가 모듈 X를 짜서 속속들이 안다'와 '추상화 모델을 갖고 어떤 모듈이든 들어가 고친다'는 다르다고 한다.
- 호출당하는 사람에게 필요한 건 후자다.
주니어가 직접 짜며 배우는 길은 막혔다
- 회사가 주니어에게 몇 년간 손으로 짜며 배우라고 돈을 대줄 가능성이 낮다고 본다.
- '에이전트 코드를 한 줄씩 이해하라', '시니어와 페어하라', '꼼꼼히 코드리뷰하라'도 일부 회사 말고는 비현실적이라고 한다.
- 모든 코드를 읽으라는 쪽과 코드를 아예 보지 말라는 쪽, 어느 극단도 맞지 않다고 한다.
첫 번째 기둥은 기초 CS다
- 조용한 실패(대체로 동작하지만 이상하게 느려지거나 19번에 한 번 실패하는 경우)를 알아채려면 기초가 필요하다.
- 자료구조·알고리즘, 네트워킹, 동시성, 분산 시스템 같은 기초다.
- 2m 작업은 4초, 4m는 16초, 16m는 256초 걸리는 예시로 quadratic complexity(입력의 제곱으로 느려지는 복잡도)를 알아보는 법을 설명한다.
두 번째 기둥은 폭넓은 지식이다
- 모든 분야의 전문가가 될 필요는 없고 이상할 때 뭘 찾아볼지 아는 정도면 된다고 한다.
- 폭은 가르칠 수 없고 읽고 탐색하며 호기심을 갖도록 권할 수밖에 없다고 한다.
- 폭은 복리로 쌓이지만 계속 유지해야 한다고 한다.
세 번째 기둥은 필요할 때 깊이 파기다
- 처음 보는 영역이라도 뛰어들어 배우려는 의지와, 혼자 못 할 때 도움을 청하는 겸손이 포함된다.
- 저자는 에이전트 오케스트레이터의 수명주기 버그를 겪다가 예전에 읽은 Kubernetes 책의 'level-triggered state machine'을 떠올렸다.
- 그 뒤 에이전트와 함께 코어 아키텍처를 처음부터 다시 설계했고 이후 안정적이라고 한다.

Community Reactions

How to Apply

오늘 에이전트 코드의 구조 지도를 한 장 그리기
- 쓰고 있는 서비스의 컴포넌트와 경계를 박스와 선으로 에이전트에게 그리게 하라.
- 각 박스의 입력·출력을 적고 직접 맞는지 확인하라.
품질 게이트를 CI에 걸어 두기
- SonarQube 같은 정적 분석을 CI에 켜고 복잡도 경고를 사람이 확인하는 트리거로 삼아라.
- 경고가 뜨면 에이전트에게 맡기기 전에 먼저 코드를 직접 읽어 판단하라.
기초 CS 약점 한 가지를 정해 학습하기
- 동시성, 분산 시스템, 복잡도 중 한 주제를 골라 이번 달에 읽을 자료를 정하라.
- 에이전트 출력이 느려지거나 간헐적으로 실패할 때 원인을 가설로 세워 보라.

Try It

복사해서 바로 해보기

# Claude Code 또는 ChatGPT에 붙여넣기 (원문의 '시스템 지도' 아이디어를 프롬프트로 옮긴 간이 버전)

너는 시니어 엔지니어다. 아래 코드베이스의 고수준 시스템 지도를 만들어 줘.
{{코드베이스 경로 또는 파일 목록}}

요구사항:
1. 주요 컴포넌트를 박스, 연결을 선으로 하는 Mermaid 다이어그램으로 그려라.
2. 각 컴포넌트의 입력/출력 경계를 한 줄씩 적어라.
3. 복잡도가 높거나 실패하기 쉬운 곳(괴물이 사는 곳)을 5개 꼽고 이유를 써라.
4. 이 지도를 확인하려면 내가 직접 열어봐야 할 파일을 알려 줘.

이어서 해 볼 것: 3번에서 꼽은 곳 중 하나를 직접 읽고 에이전트의 설명과 맞는지 비교해 보라.

Terminology

cyclomatic complexity코드 안의 분기(if, for 등)가 얼마나 많은지로 재는 복잡도 지표다. 길 갈래가 많을수록 길 찾기 어려운 미로와 같다.

quadratic complexity입력이 2배가 되면 작업 시간이 4배가 되는 식으로 제곱으로 느려지는 성질이다. 규모가 커질수록 급격히 느려진다.

level-triggered state machine이벤트가 발생한 순간이 아니라 현재 상태를 보고 동작을 결정하는 상태 기계다. Kubernetes의 컨트롤러가 이 방식이다.

Just-in-Time Depth미리 다 배워두는 대신 문제가 생겼을 때 필요한 깊이만큼 바로 파고드는 능력이다.

Related Resources

에이전트가 코드를 짜는 시대, 엔지니어가 여전히 알아야 할 것: 기초·폭넓은 지식·필요할 때 깊이 파기

Here be monsters: What do you still need to know when agents do the work?

Oct 27, 2026•adrq•View Original

TL;DR Highlight

에이전트가 짠 코드의 오너십은 기초, 폭넓은 지식, 즉시 깊이 파는 능력에 달렸다

Who Should Read

코딩 에이전트가 짠 코드를 운영하며 어디까지 직접 이해해야 할지 고민하는 백엔드·풀스택 개발자

Core Mechanics

CI가 잡아낸 건 한 줄짜리 컴포넌트였다
- SonarQube가 App.tsx의 cyclomatic complexity(분기 수로 재는 코드 복잡도)를 경고했다.
- App.tsx는 약 30줄이었는데 그중 15줄이 컴포넌트 하나씩을 통째로 한 줄에 쓴 코드였다.
- Codex에게 SonarQube를 만족시키라고 하자 10개 파일로 쪼개서 CI가 통과했다.
오너십은 직접 짠 경험이 아니라 시스템 지도다
- 시스템 전체를 세세히 아는 게 아니라 어디를 파야 하는지 아는 고수준 지도가 필요하다고 말한다.
- '내가 모듈 X를 짜서 속속들이 안다'와 '추상화 모델을 갖고 어떤 모듈이든 들어가 고친다'는 다르다고 한다.
- 호출당하는 사람에게 필요한 건 후자다.
주니어가 직접 짜며 배우는 길은 막혔다
- 회사가 주니어에게 몇 년간 손으로 짜며 배우라고 돈을 대줄 가능성이 낮다고 본다.
- '에이전트 코드를 한 줄씩 이해하라', '시니어와 페어하라', '꼼꼼히 코드리뷰하라'도 일부 회사 말고는 비현실적이라고 한다.
- 모든 코드를 읽으라는 쪽과 코드를 아예 보지 말라는 쪽, 어느 극단도 맞지 않다고 한다.
첫 번째 기둥은 기초 CS다
- 조용한 실패(대체로 동작하지만 이상하게 느려지거나 19번에 한 번 실패하는 경우)를 알아채려면 기초가 필요하다.
- 자료구조·알고리즘, 네트워킹, 동시성, 분산 시스템 같은 기초다.
- 2m 작업은 4초, 4m는 16초, 16m는 256초 걸리는 예시로 quadratic complexity(입력의 제곱으로 느려지는 복잡도)를 알아보는 법을 설명한다.
두 번째 기둥은 폭넓은 지식이다
- 모든 분야의 전문가가 될 필요는 없고 이상할 때 뭘 찾아볼지 아는 정도면 된다고 한다.
- 폭은 가르칠 수 없고 읽고 탐색하며 호기심을 갖도록 권할 수밖에 없다고 한다.
- 폭은 복리로 쌓이지만 계속 유지해야 한다고 한다.
세 번째 기둥은 필요할 때 깊이 파기다
- 처음 보는 영역이라도 뛰어들어 배우려는 의지와, 혼자 못 할 때 도움을 청하는 겸손이 포함된다.
- 저자는 에이전트 오케스트레이터의 수명주기 버그를 겪다가 예전에 읽은 Kubernetes 책의 'level-triggered state machine'을 떠올렸다.
- 그 뒤 에이전트와 함께 코어 아키텍처를 처음부터 다시 설계했고 이후 안정적이라고 한다.

Community Reactions

How to Apply

오늘 에이전트 코드의 구조 지도를 한 장 그리기
- 쓰고 있는 서비스의 컴포넌트와 경계를 박스와 선으로 에이전트에게 그리게 하라.
- 각 박스의 입력·출력을 적고 직접 맞는지 확인하라.
품질 게이트를 CI에 걸어 두기
- SonarQube 같은 정적 분석을 CI에 켜고 복잡도 경고를 사람이 확인하는 트리거로 삼아라.
- 경고가 뜨면 에이전트에게 맡기기 전에 먼저 코드를 직접 읽어 판단하라.
기초 CS 약점 한 가지를 정해 학습하기
- 동시성, 분산 시스템, 복잡도 중 한 주제를 골라 이번 달에 읽을 자료를 정하라.
- 에이전트 출력이 느려지거나 간헐적으로 실패할 때 원인을 가설로 세워 보라.

Try It

복사해서 바로 해보기

# Claude Code 또는 ChatGPT에 붙여넣기 (원문의 '시스템 지도' 아이디어를 프롬프트로 옮긴 간이 버전)

너는 시니어 엔지니어다. 아래 코드베이스의 고수준 시스템 지도를 만들어 줘.
{{코드베이스 경로 또는 파일 목록}}

요구사항:
1. 주요 컴포넌트를 박스, 연결을 선으로 하는 Mermaid 다이어그램으로 그려라.
2. 각 컴포넌트의 입력/출력 경계를 한 줄씩 적어라.
3. 복잡도가 높거나 실패하기 쉬운 곳(괴물이 사는 곳)을 5개 꼽고 이유를 써라.
4. 이 지도를 확인하려면 내가 직접 열어봐야 할 파일을 알려 줘.

이어서 해 볼 것: 3번에서 꼽은 곳 중 하나를 직접 읽고 에이전트의 설명과 맞는지 비교해 보라.

Terminology

cyclomatic complexity코드 안의 분기(if, for 등)가 얼마나 많은지로 재는 복잡도 지표다. 길 갈래가 많을수록 길 찾기 어려운 미로와 같다.

quadratic complexity입력이 2배가 되면 작업 시간이 4배가 되는 식으로 제곱으로 느려지는 성질이다. 규모가 커질수록 급격히 느려진다.

level-triggered state machine이벤트가 발생한 순간이 아니라 현재 상태를 보고 동작을 결정하는 상태 기계다. Kubernetes의 컨트롤러가 이 방식이다.

Just-in-Time Depth미리 다 배워두는 대신 문제가 생겼을 때 필요한 깊이만큼 바로 파고드는 능력이다.

에이전트가 코드를 짜는 시대, 엔지니어가 여전히 알아야 할 것: 기초·폭넓은 지식·필요할 때 깊이 파기

TL;DR Highlight

Who Should Read

Core Mechanics

Community Reactions

How to Apply

Try It

Terminology

관련 논문

Related Resources

에이전트가 코드를 짜는 시대, 엔지니어가 여전히 알아야 할 것: 기초·폭넓은 지식·필요할 때 깊이 파기

TL;DR Highlight

Who Should Read

Core Mechanics

Community Reactions

How to Apply

Try It

Terminology

관련 논문

Related Resources