우리 팀이 에이전트 기반 개발을 본격적으로 도입했을 때, 코딩 속도는 빨라지지만 리뷰 시간이 늘어날까 걱정했음
아직은 뚜렷한 변화가 없고, 모두가 새로운 워크플로우를 익히는 중이라 데이터가 충분하지 않음
하지만 빠른 코딩이 특히 유용한 경우들이 있음 — 아이디어 실험, 복잡한 반복 작업, 단순하지만 노동집약적인 구현, 해피 패스 이후의 엣지 케이스 처리 등
특히 기존 브랜치나 PR을 그대로 확장하는 경우에 에이전트가 매우 잘 작동함
가장 큰 생산성 향상은 에이전트가 코딩하는 동안 내가 다른 일을 할 수 있다는 점임. 예를 들어 PR 리뷰를 하고 돌아오면 결과물이 나와 있음
처음엔 회의적이었지만 지금은 조심스럽게 기대 중임. 10배 향상은 무리겠지만 2배 향상만 돼도 대단한 일임
나도 그 단계를 거쳤지만 결국 포기했음. 에이전트가 코딩하는 동안 다른 일을 하는 건 컨텍스트 전환이 너무 많아 오히려 집중력과 생산성을 해침
이 방식은 실수 비용이 낮거나 변경 범위가 작을 때만 쓸 만함. 그렇지 않으면 품질과 만족도가 떨어지고 일정만 압축됨
결국 병렬로 시간을 되찾는 게 아니라, 미루던 일을 조금 덜 미루게 되는 정도임
다른 회사의 경험을 엿볼 수 있어 흥미로웠음. 나도 대부분 동의함
다만 에이전트가 코딩하는 동안 다른 일을 하는 건 이상한 피로감을 줌
AI는 생산적이지만, 인간 장인으로서의 코딩과는 전혀 다른 종류의 노동임
대규모 리팩터링을 AI가 대신 해주면 매몰비용에 덜 얽매이게 됨
직접 했다면 포기하기 어려웠을 리팩터링도, AI가 한 경우엔 “이건 별로였다”고 솔직히 판단하기 쉬움
에이전트가 코딩하는 동안 다른 일을 하는 건 끔찍하게 들림
계속 멀티태스킹하면 번아웃이 빠르게 옴. 인간적인 요소가 논의에서 빠져 있는 게 아쉬움
나는 항상 ‘최적화된 상태’로 일하고 싶지 않음
누군가 “문제를 이해하는 게 병목”이라 했는데, 나는 왜 빠른 타이핑이 문제 이해를 돕지 못하냐고 묻고 싶음
잘못된 걸 빨리 만들어보면 오히려 올바른 방향을 더 빨리 찾을 수도 있지 않겠음?
나는 종종 뭔가를 만들어보면서 내가 진짜 원하는 걸 깨닫곤 함. 프로토타입 제작이 싸질수록 이 경향은 더 강해짐
물론, 결국 “사용자와 더 이야기해야 한다”는 회고로 끝나긴 하지만, 그건 또 다른 문제임
하지만 고객은 실패를 무한히 참아주지 않음. 특히 B2B나 SaaS 환경에서는 피드백 루프가 매우 느림
은행 같은 곳은 잘해야 일주일에 한 번 정도만 실험 가능함
AI는 이미 수없이 반복된 문제나, 대충 맞으면 되는 결과에는 강함
하지만 대부분의 소프트웨어는 그렇지 않음. 코드를 쓰는 건 전체 일의 일부일 뿐임
외과의가 단순히 ‘자르는 일’만 하는 게 아니듯, 엔지니어도 단순히 코드를 쓰는 게 전부가 아님
“빠른 타이핑으로 문제를 빨리 이해할 수 있나?”라는 질문엔 이렇게 답하고 싶음 — “그럼 말을 빨리 하면 대화도 더 잘 이해되나?”
빠른 프로토타이핑이 유용할 때는 그 결과가 사용자나 요구사항과 직접 부딪힐 때임
혼자서 코드만 다듬는다면, 그건 단지 더 큰 혼란을 만드는 것일 뿐임
때로는 PM이나 고객과 한 시간 대화하는 게 훨씬 낫음
“타이핑을 빨리 하면 문제를 빨리 이해할 수 있나?”에 대한 예시가 있다면 궁금함
지금의 LLM 열풍은 문제보다 솔루션이 먼저 나온 느낌임
진짜 속도를 높이려면 “무엇이 병목인가?”를 먼저 물어야 함
경영진이 AI 프레젠테이션을 보고 “이거 쓰면 빨라진다”라고 믿는 건 분위기 경영(vibe management) 에 불과함
하지만 내 30년 경험상, 개발은 단순히 코딩(#4 단계)이 아니라 비즈니스 이해, 설계, 테스트, 승인, 운영, 유지보수까지의 긴 과정임
코딩은 그중 가장 노동집약적이고 자동화 가능한 부분임
LLM은 이 부분을 상당히 덜어줄 수 있음. 특히 테스트 코드 작성 같은 건 AI가 잘함
인간 개발자는 여전히 코드에 대한 집착을 버리지 못하고 있음
사실 코드란 단지 해결책의 중간 표현(IR)에 불과함
GCC가 어셈블리로 변환할 때 내부 최적화를 신경 쓰지 않듯, 에이전트가 코드를 생성해도 우리는 결과의 정확성만 보면 됨
명확한 명세와 반복적인 검토 과정이 있다면, 인간이든 에이전트든 동일한 구현을 낼 수 있음
하지만 컴파일러는 결정론적으로 동작하고, 항상 같은 결과를 냄
LLM은 그렇지 않음. 오해하거나 환각(hallucination) 을 일으킬 수 있음
그래서 여전히 사람이 리뷰해야 함
고급 언어의 소스 코드는 형식 언어임. 자연어와는 다름
정말 그렇게 믿는다면, 차라리 직접 어셈블리로 변환하지 왜 중간 단계를 거치나?
실제로는 그렇게 단순하지 않음. 여러 번 리모델링된 집처럼, 코드베이스도 구조적 한계에 부딪힘
에이전트가 잘못된 패턴을 선택하거나 기술 부채를 쌓는 경우가 많음
언젠가 프로그래밍 언어 자체를 없앨 수도 있겠지만, 아직은 멀었음
고급 언어는 의미가 결정론적으로 유지되지만, 에이전트 코딩은 그렇지 않음
의미가 확장되거나 압축되고, 심지어 사라지기도 함
많은 회사는 진짜로 좋은 코드를 원하지 않음
내부 평가는 “얼마나 많이 배포했는가”로 이뤄지고, 문제를 지적하면 “너무 세세하다”는 말을 듣게 됨
결국 내부 이해관계자들은 단지 ‘성공했다’는 명분을 원함
나는 좀 더 관대하게 보려 함. 회사는 좋은 코드를 원하지만, 속도와 품질의 트레이드오프를 고려함
기술자는 그 위험을 설명할 책임이 있음
하지만 현실적으로는 사람들이 점점 덜 신경 쓰고 있음
AI 도입 이후 품질 저하가 실제로 나타나고 있음
우리 회사는 PR 승인도 대충 하고, CI는 45분 걸리고, 배포는 며칠씩 지연됨
게다가 AI 사용도 금지되어 있음. 대부분 인간이 쓴 코드라고 하지만 의심스러움
이 글이 놓친 건 두 가지임 — (A) 에이전트 사용과 프로세스 최적화는 양립 가능하다는 점, (B) 어떤 티켓은 정말 코드가 병목이라는 점
결국 중요한 건 AI 여부가 아니라, 병목을 제거하는 프로세스 개선임
나는 1인 개발자임. 코딩 속도는 실제로 문제임. 다른 일에 쓸 시간을 빼앗기기 때문임
오늘 Claude Code를 설정했는데, 이제 구글링이나 테스트 작성에 시간을 덜 씀
생산성이 10배 오르진 않겠지만, 노동 절약 기술로서 충분히 가치 있음. 마치 식기세척기처럼
나도 비슷한 경험을 함. 예전엔 퇴근 후 새벽까지 구글링하고 테스트는 미루기 일쑤였음
이제는 AI가 테스트까지 작성하고 엣지 케이스를 경고해줌
완벽하진 않지만, 새 기능 출시 속도가 빨라지고 내 시간도 늘어남
“AI를 믿을 수 없다”는 말은 마치 “컴파일러를 믿을 수 없다”는 말처럼 들림
결국 인간이 방향을 제시하고, 프롬프트를 개선하며 함께 성장하는 과정임
제목이 말하는 건 “코딩이 주된 문제냐”는 것임
스타트업이나 VC 환경에서는 코딩보다 비즈니스 문제 해결이 핵심임
코드 생산량이 늘어도 시스템 전체의 결과가 좋아진다는 보장은 없음
나도 동의함. 여전히 코드를 한 줄씩 리뷰해야 함
템플릿이나 코드 생성기처럼 속도는 빨라지지만, 요구사항 수집이 10배 빨라지지 않는 한 10배 생산성은 불가능함
이게 맞는 방향임
다만 식기세척기는 물과 에너지를 절약하지만, LLM은 그렇지 않음
비유로 쓰기엔 조금 부적절함
AI가 사람이 잘 안 하는 실수를 저지르지 않게 하려면 어떻게 해야 할까?
사람은 코드를 단계별로 논리적으로 검토하지만, AI는 그렇지 않음
Amazon처럼 시니어 엔지니어가 리뷰하더라도, 리뷰는 모든 버그를 잡기 위한 과정이 아님
게다가 시니어일수록 회의가 많아 코드 맥락을 잘 모름. 이런 리뷰가 얼마나 효과적일까?
하지만 인간도 실수함. GitLab, S3, Knight Capital, MySpace 모두 대형 사고를 냈음
인간이 완벽하다고 생각하는 건 착각임
우리는 AI에게 인간보다 더 높은 기준을 요구하고 있음
결국 중요한 건 QA 프로세스 강화임. 개발자에게 테스트를 맡기지 말아야 함
예전에 읽은 책 《The Goal》이 떠오름. 공정의 한 단계를 자동화하면, 그 다음 단계가 병목이 되는 현상임
소프트웨어도 마찬가지로, 코드 생성이 빨라져도 전체 프로세스가 따라오지 못하면 의미가 없음
결국 모든 것은 이윤 창출이라는 목표 아래에 있음. 코드 품질도 그 목표의 하위 개념일 뿐임
코드 작성 속도는 위험이 큰 상황에서는 병목이 아님
때로는 천천히 계획하고 결과를 숙고하는 게 더 낫음
예를 들어 AI 산업처럼 거대한 시스템을 너무 빠르게 구축하면, 잘못된 방향의 문명적 리스크를 초래할 수 있음
반면 주말에 혼자 만드는 작은 게임이라면 상관없음. 결국 리스크의 크기가 속도를 결정함
Hacker News 의견들
우리 팀이 에이전트 기반 개발을 본격적으로 도입했을 때, 코딩 속도는 빨라지지만 리뷰 시간이 늘어날까 걱정했음
아직은 뚜렷한 변화가 없고, 모두가 새로운 워크플로우를 익히는 중이라 데이터가 충분하지 않음
하지만 빠른 코딩이 특히 유용한 경우들이 있음 — 아이디어 실험, 복잡한 반복 작업, 단순하지만 노동집약적인 구현, 해피 패스 이후의 엣지 케이스 처리 등
특히 기존 브랜치나 PR을 그대로 확장하는 경우에 에이전트가 매우 잘 작동함
가장 큰 생산성 향상은 에이전트가 코딩하는 동안 내가 다른 일을 할 수 있다는 점임. 예를 들어 PR 리뷰를 하고 돌아오면 결과물이 나와 있음
처음엔 회의적이었지만 지금은 조심스럽게 기대 중임. 10배 향상은 무리겠지만 2배 향상만 돼도 대단한 일임
이 방식은 실수 비용이 낮거나 변경 범위가 작을 때만 쓸 만함. 그렇지 않으면 품질과 만족도가 떨어지고 일정만 압축됨
결국 병렬로 시간을 되찾는 게 아니라, 미루던 일을 조금 덜 미루게 되는 정도임
다만 에이전트가 코딩하는 동안 다른 일을 하는 건 이상한 피로감을 줌
AI는 생산적이지만, 인간 장인으로서의 코딩과는 전혀 다른 종류의 노동임
직접 했다면 포기하기 어려웠을 리팩터링도, AI가 한 경우엔 “이건 별로였다”고 솔직히 판단하기 쉬움
계속 멀티태스킹하면 번아웃이 빠르게 옴. 인간적인 요소가 논의에서 빠져 있는 게 아쉬움
나는 항상 ‘최적화된 상태’로 일하고 싶지 않음
누군가 “문제를 이해하는 게 병목”이라 했는데, 나는 왜 빠른 타이핑이 문제 이해를 돕지 못하냐고 묻고 싶음
잘못된 걸 빨리 만들어보면 오히려 올바른 방향을 더 빨리 찾을 수도 있지 않겠음?
나는 종종 뭔가를 만들어보면서 내가 진짜 원하는 걸 깨닫곤 함. 프로토타입 제작이 싸질수록 이 경향은 더 강해짐
물론, 결국 “사용자와 더 이야기해야 한다”는 회고로 끝나긴 하지만, 그건 또 다른 문제임
은행 같은 곳은 잘해야 일주일에 한 번 정도만 실험 가능함
하지만 대부분의 소프트웨어는 그렇지 않음. 코드를 쓰는 건 전체 일의 일부일 뿐임
외과의가 단순히 ‘자르는 일’만 하는 게 아니듯, 엔지니어도 단순히 코드를 쓰는 게 전부가 아님
혼자서 코드만 다듬는다면, 그건 단지 더 큰 혼란을 만드는 것일 뿐임
때로는 PM이나 고객과 한 시간 대화하는 게 훨씬 낫음
지금의 LLM 열풍은 문제보다 솔루션이 먼저 나온 느낌임
진짜 속도를 높이려면 “무엇이 병목인가?”를 먼저 물어야 함
경영진이 AI 프레젠테이션을 보고 “이거 쓰면 빨라진다”라고 믿는 건 분위기 경영(vibe management) 에 불과함
코딩은 그중 가장 노동집약적이고 자동화 가능한 부분임
LLM은 이 부분을 상당히 덜어줄 수 있음. 특히 테스트 코드 작성 같은 건 AI가 잘함
인간 개발자는 여전히 코드에 대한 집착을 버리지 못하고 있음
사실 코드란 단지 해결책의 중간 표현(IR)에 불과함
GCC가 어셈블리로 변환할 때 내부 최적화를 신경 쓰지 않듯, 에이전트가 코드를 생성해도 우리는 결과의 정확성만 보면 됨
명확한 명세와 반복적인 검토 과정이 있다면, 인간이든 에이전트든 동일한 구현을 낼 수 있음
LLM은 그렇지 않음. 오해하거나 환각(hallucination) 을 일으킬 수 있음
그래서 여전히 사람이 리뷰해야 함
에이전트가 잘못된 패턴을 선택하거나 기술 부채를 쌓는 경우가 많음
언젠가 프로그래밍 언어 자체를 없앨 수도 있겠지만, 아직은 멀었음
의미가 확장되거나 압축되고, 심지어 사라지기도 함
많은 회사는 진짜로 좋은 코드를 원하지 않음
내부 평가는 “얼마나 많이 배포했는가”로 이뤄지고, 문제를 지적하면 “너무 세세하다”는 말을 듣게 됨
결국 내부 이해관계자들은 단지 ‘성공했다’는 명분을 원함
기술자는 그 위험을 설명할 책임이 있음
AI 도입 이후 품질 저하가 실제로 나타나고 있음
우리 회사는 PR 승인도 대충 하고, CI는 45분 걸리고, 배포는 며칠씩 지연됨
게다가 AI 사용도 금지되어 있음. 대부분 인간이 쓴 코드라고 하지만 의심스러움
이 글이 놓친 건 두 가지임 — (A) 에이전트 사용과 프로세스 최적화는 양립 가능하다는 점, (B) 어떤 티켓은 정말 코드가 병목이라는 점
결국 중요한 건 AI 여부가 아니라, 병목을 제거하는 프로세스 개선임
나는 1인 개발자임. 코딩 속도는 실제로 문제임. 다른 일에 쓸 시간을 빼앗기기 때문임
오늘 Claude Code를 설정했는데, 이제 구글링이나 테스트 작성에 시간을 덜 씀
생산성이 10배 오르진 않겠지만, 노동 절약 기술로서 충분히 가치 있음. 마치 식기세척기처럼
이제는 AI가 테스트까지 작성하고 엣지 케이스를 경고해줌
완벽하진 않지만, 새 기능 출시 속도가 빨라지고 내 시간도 늘어남
“AI를 믿을 수 없다”는 말은 마치 “컴파일러를 믿을 수 없다”는 말처럼 들림
결국 인간이 방향을 제시하고, 프롬프트를 개선하며 함께 성장하는 과정임
스타트업이나 VC 환경에서는 코딩보다 비즈니스 문제 해결이 핵심임
코드 생산량이 늘어도 시스템 전체의 결과가 좋아진다는 보장은 없음
템플릿이나 코드 생성기처럼 속도는 빨라지지만, 요구사항 수집이 10배 빨라지지 않는 한 10배 생산성은 불가능함
비유로 쓰기엔 조금 부적절함
AI가 사람이 잘 안 하는 실수를 저지르지 않게 하려면 어떻게 해야 할까?
사람은 코드를 단계별로 논리적으로 검토하지만, AI는 그렇지 않음
Amazon처럼 시니어 엔지니어가 리뷰하더라도, 리뷰는 모든 버그를 잡기 위한 과정이 아님
게다가 시니어일수록 회의가 많아 코드 맥락을 잘 모름. 이런 리뷰가 얼마나 효과적일까?
인간이 완벽하다고 생각하는 건 착각임
우리는 AI에게 인간보다 더 높은 기준을 요구하고 있음
결국 중요한 건 QA 프로세스 강화임. 개발자에게 테스트를 맡기지 말아야 함
예전에 읽은 책 《The Goal》이 떠오름. 공정의 한 단계를 자동화하면, 그 다음 단계가 병목이 되는 현상임
소프트웨어도 마찬가지로, 코드 생성이 빨라져도 전체 프로세스가 따라오지 못하면 의미가 없음
결국 모든 것은 이윤 창출이라는 목표 아래에 있음. 코드 품질도 그 목표의 하위 개념일 뿐임
코드 작성 속도는 위험이 큰 상황에서는 병목이 아님
때로는 천천히 계획하고 결과를 숙고하는 게 더 낫음
예를 들어 AI 산업처럼 거대한 시스템을 너무 빠르게 구축하면, 잘못된 방향의 문명적 리스크를 초래할 수 있음
반면 주말에 혼자 만드는 작은 게임이라면 상관없음. 결국 리스크의 크기가 속도를 결정함