TECH 으로 돌아가기
TECH HACKER NEWS 7분 읽기 40 READS

AI가 코드를 더 많이 써줘도, 시스템 설계는 여전히 우리 몫이에요

AI가 코드를 더 많이 써줘도, 시스템 설계는 여전히 우리 몫이에요
SOURCE IMAGE · HACKER NEWS
AI가 코드를 더 많이 써줘도, 시스템 설계는 여전히 우리 몫이에요

코드 짜기는 쉬워졌는데, 왜 일은 줄지 않을까요?

요즘은 AI 코딩 도구를 안 쓰는 개발자를 찾기가 더 어렵죠. Claude Code, Cursor, Copilot 같은 도구에 '이 API에 페이지네이션 붙여줘'라고 하면 몇 초 만에 그럴듯한 코드가 나와요. 그런데 팀 전체의 일이 그만큼 줄었다는 얘기는 잘 안 들려요.

picon.dev에 올라온 「AI Can Write More of the Code. We Still Have to Engineer the System」이 바로 이 부분을 다루는 글이에요. 제목처럼 AI가 코드의 더 많은 부분을 써줄 수는 있어도 시스템을 설계하고 책임지는 일은 여전히 사람 몫이라는 거죠. 당연한 얘기 같지만, 이걸 제대로 이해하면 AI 도구를 쓰는 방식이 달라져요. 이 글의 문제의식을 실무 관점에서 좀 더 풀어볼게요.

코드 작성과 시스템 엔지니어링은 다른 일이에요

집 짓기에 비유하면 이해하기 쉬워요. 벽돌 쌓는 속도가 10배 빨라졌다고 좋은 집이 10배 빨리 지어지지는 않잖아요. 기둥을 어디에 세울지, 배관을 어디로 뺄지, 나중에 방을 하나 더 늘릴 수 있게 할지는 여전히 누군가 정해야 하거든요.

소프트웨어도 똑같아요. 시스템 엔지니어링에는 이런 일들이 들어가요.

AI는 주어진 맥락 안에서 그럴듯한 코드를 만드는 데 정말 뛰어나요. 그런데 그 맥락을 정하는 건 여전히 사람의 일이에요. 맥락을 잘못 주면 AI는 잘못된 방향으로 아주 빠르고 성실하게 달려가거든요.

40년 전 프레드 브룩스가 이미 한 이야기

이 논의는 꽤 오래된 이야기와 이어져요. 『맨먼스 미신』을 쓴 프레드 브룩스는 1986년 에세이 「No Silver Bullet」에서 소프트웨어의 어려움을 두 가지로 나눴어요.

본질적 복잡성(Essential Complexity)은 문제 자체가 원래 가진 어려움이에요. 비즈니스 규칙이 복잡하거나 여러 시스템이 얽혀 있는 경우가 그렇죠. 우발적 복잡성(Accidental Complexity)은 문제를 푸는 도구 때문에 생기는 어려움이에요. 문법, 매번 반복해서 써야 하는 코드(보일러플레이트), 단순 타이핑 같은 것들이요.

브룩스는 본질적 복잡성을 한 번에 없애주는 도구, 즉 '은탄환'은 없다고 했어요. AI 코딩 도구는 우발적 복잡성을 크게 줄여줬지만 본질적 복잡성은 그대로 남아 있어요. 오히려 코드를 쉽게 만들 수 있다 보니 시스템이 더 빨리 커지고 더 빨리 복잡해지는 부작용도 생기죠.

업계 데이터에서도 비슷한 신호가 보여요. 2024년 DORA 리포트에서는 AI 도입이 늘수록 개인이 느끼는 생산성은 올라가지만 배포 안정성은 오히려 떨어지는 경향이 나타났어요. 2025년 METR 실험에서는 숙련된 오픈소스 개발자들이 AI 도구를 쓰면서 스스로는 빨라졌다고 느꼈는데, 실제 작업 시간은 더 길어졌다는 결과도 나왔고요. 병목이 코드 작성에서 검증과 통합으로 옮겨간 거예요.

그럼 우리는 뭘 해야 할까요

국내 개발 조직에서도 바로 해볼 수 있는 일이 몇 가지 있어요.

첫째, 설계 문서를 다시 쓰세요. AI에게 좋은 결과를 받으려면 좋은 맥락을 줘야 하는데, 그게 바로 설계 문서예요. 특히 왜 그렇게 결정했는지 남기는 ADR(Architecture Decision Record, 아키텍처 결정 기록)은 사람에게도 AI에게도 훌륭한 가이드가 돼요.

둘째, 코드 리뷰에서 보는 지점을 바꾸세요. AI가 쓴 코드는 문법이나 스타일은 대체로 깔끔해요. 그 대신 '우리 시스템의 경계를 지키고 있나', '실패하면 어떻게 되나', '이 의존성이 꼭 필요한가'를 확인해야 해요.

셋째, 주니어라면 '왜'를 꼭 물어보세요. AI가 짜준 코드가 돌아가는 데서 멈추지 말고, 왜 이런 구조인지, 다른 방법은 없는지 한 번 더 물어보세요. 이 습관이 쌓이면 나중에 큰 차이가 나요. 코드를 쓰는 능력의 가치는 줄고 있지만, 시스템을 이해하는 능력의 가치는 오히려 올라가고 있거든요.

마무리

한 줄 정리: AI는 벽돌을 빨리 쌓아주지만, 어떤 집을 지을지는 여전히 엔지니어가 정해야 해요.

여러분 팀은 AI 도구를 도입한 뒤 병목이 어디로 옮겨갔나요? 리뷰가 늘었는지, 설계 논의가 늘었는지, 아니면 장애 대응이 늘었는지 경험을 나눠주세요.


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://picon.dev/en/publications/ai-assisted-engineering/
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기 →
처리 중...