May 10, 2026

AI가 코드를 써주는 시대에, 우리는 무엇을 책임져야 하나

이 글은 이전에 썼던 AI Advisor 회고의 다음 이야기다.

그때 나는 회사에서 AI Advisor 역할을 하며, “환경만 만들면 사람들이 자연스럽게 AI를 잘 쓰게 될 것”이라는 생각이 순진했다는 걸 배웠다.
지금은 AI Advisor 로서 활동하고 있지 않지만, 조언자로서의 고민이 개발 조직의 코드 품질과 리더십에 대한 고민으로 이어졌다.

AI를 잘 쓰는 개인이 되는 것만으로 충분한가.
아니면 팀이 함께 더 나은 판단을 반복할 수 있도록 baseline을 만들어야 하는가.

이 글은 그 질문에 대한 현재의 생각이다.

AI는 개발문화를 많이 바꿨다.

예전에는 무언가를 만들기 위해 많은 시간을 정보 탐색에 썼다.
어떤 API를 써야 하는지, 어떤 코드가 필요한지, 왜 에러가 나는지, 비슷한 예제는 어디 있는지 찾아야 했다.
물론 지금도 이런 일이 완전히 사라진 것은 아니지만, 적어도 예전만큼 많은 시간을 쓰지는 않는다.

이제는 AI에게 내가 하고 싶은 것을 적절히 설명하면, 꽤 그럴듯한 코드를 만들어준다.
문법을 찾고, 예제를 뒤지고, 에러 메시지를 검색하는 비용은 확실히 낮아졌다.
덕분에 우리는 조금 더 본질적인 질문에 집중할 수 있게 되었다.

“무엇을 만들 것인가?”
“왜 만들어야 하는가?”
“어떤 방식으로 만들어야 하는가?”

나는 이 변화가 굉장히 크다고 생각한다.
하지만 동시에 계속 찝찝한 고민도 같이 하게 되었따.

AI가 이렇게 좋아졌는데, 왜 우리는 자동으로 더 안전하고 좋은 코드를 쓰게 되지는 않을까?

지금 내가 내리는 답은 이렇다.

AI는 구현의 비용을 낮췄지만, 판단의 책임을 없애지는 않았다.
오히려 구현이 쉬워진 만큼, 무엇을 만들지, 어디에 책임을 둘지, 어떤 리스크를 알고 감수할지 판단하는 능력이 더 중요해졌다.

한 대화에서 시작된 고민

최근에 동료와 어떤 기능의 상태 판단을 어디에서 해야 하는지 이야기한 적이 있다.

동료는 특정 상태 판단을 백엔드가 아니라 프론트에서 처리하는 편이 낫다고 보고 있었다.
나는 그 말을 듣고 조금 당황했다.

이유는 단순히 “백엔드가 해야 하는 일을 프론트에 넘기려고 해서”가 아니었다.
프론트에 위임해야 하는 상황은 실제로 올 수 있다.
개발 일정, 구현 난이도, 현재 시스템 구조, 팀의 상황에 따라 현실적인 선택을 해야 할 때도 있다.

다만 내가 중요하게 생각했던 것은, 그런 선택을 할 때 리스크를 알고 있어야 한다는 점이었다. 리스크는 또한 모두가 인식할 수 있도록 문서로 관리되어야 한다.

클라이언트에서 계산된 상태는 사용자가 조작할 가능성을 항상 고려해야 한다.
프론트의 실수가 백엔드 상태에 영향을 줄 수도 있다.
해당 기능이 웹 브라우저 환경뿐만 아니라 앱 환경에서도 사용된다면, 각 클라이언트마다 같은 판단 로직을 중복해서 구현해야 할 수도 있다.
그렇게 되면 시간이 지날수록 상태 판단의 일관성이 깨질 위험도 커진다.

그래서 나는 동료에게 이야기했다.

프론트에 위임할 수는 있다.
하지만 근본적으로 백엔드가 상태 관리의 책임을 가져야 하는 경우가 많다.
특히 그 상태가 시스템의 중요한 판단과 연결되어 있다면 더 그렇다.
만약 모든 리스크를 고려한 뒤에도 현재 상황에서는 프론트에 위임하는 것이 더 낫다고 판단한다면, 그때는 그렇게 할 수도 있다.
하지만 그 선택은 리스크를 알고 내리는 선택이어야 한다.

내가 전달하고 싶었던 것은 정답이 아니었다.

내가 말하고 싶었던 것은 “기술부채는 알고 져야 한다”는 것이었다.

기술부채는 나쁜 것이 아니다

나는 기술부채가 무조건 나쁘다고 생각하지 않는다.

현실의 개발은 항상 이상적인 조건에서 이루어지지 않는다.
시간은 부족하고, 요구사항은 바뀌고, 시스템은 이미 복잡하고, 팀은 여러 우선순위 사이에서 선택해야 한다.
그런 상황에서 때로는 이상적인 구조를 포기하고, 당장의 문제를 해결하는 선택을 해야 한다.

그 자체가 나쁜 것은 아니다.

하지만 어떤 빚을 지는지 모른 채 빚을 지는 것은 위험하다.
이 빚이 어디에 영향을 줄지, 나중에 어떤 비용으로 돌아올지, 어떤 상황에서 문제가 될 수 있는지 모른다면 그 선택은 점점 위험해진다.

기술부채는 선택일 수 있다.
하지만 리스크를 모르는 선택은 위험한 선택이 될 수 있다.

그 대화에서 내가 느낀 고민은 여기에 가까웠다.
상태 판단을 프론트에 둘 수도 있고, 백엔드에 둘 수도 있다.
하지만 그 판단을 하기 전에 책임 경계와 리스크를 충분히 봐야 한다.

이건 단순히 코드 위치를 정하는 문제가 아니다.
시스템의 책임이 어디에 있어야 하는지, 어떤 변경이 어디까지 영향을 줄 수 있는지, 어떤 판단을 중앙에서 관리해야 하는지에 대한 문제다.

그리고 이 지점에서 나는 AI 시대의 개발에 대해 다시 생각하게 되었다.

AI는 잘못된 판단도 빠르게 코드로 만든다

AI는 코드를 빠르게 만들어준다.

이건 분명 큰 장점이다.
예전에는 구현에 오래 걸리던 것들이 이제는 훨씬 빠르게 만들어진다.
초안을 만들고, 테스트를 작성하고, 리팩토링 방향을 잡고, 문서를 정리하는 일도 훨씬 쉬워졌다.

하지만 바로 그 점 때문에 더 위험해진 부분도 있다.

AI는 내가 잘못 정의한 문제도 빠르게 구현해준다.
내가 놓친 리스크도 그대로 지나칠 수 있다.
내가 책임 경계를 잘못 잡으면, 그 잘못된 경계를 기준으로 그럴듯한 코드를 만들어낸다.

예전에는 잘못된 설계를 구현하는 데에도 시간이 걸렸다.
그 시간이 때로는 다시 생각할 기회를 주기도 했다.
그런데 지금은 다르다.
AI를 붙이면 잘못된 판단도 빠르게 코드가 된다.
심지어 꽤 그럴듯하게 보인다.

그래서 나는 이런 생각을 자주 한다.

AI가 쓴 코드가 얼마나 좋아질지는 결국 파일럿에게 달려 있다.

AI가 좋아질수록 개발자가 덜 중요해지는 것이 아니라, 개발자의 판단이 더 중요해질 수 있다.
코드를 작성하는 비용이 낮아졌기 때문에, 무엇을 만들지 결정하는 비용의 중요성이 더 커졌다.
구현 속도가 빨라졌기 때문에, 잘못된 방향으로 빠르게 달리지 않게 만드는 기준이 더 중요해졌다.

AI는 개발자의 손을 일부 대신할 수 있다.
하지만 개발자의 책임까지 대신해주지는 않는다.

내가 AI와 일하던 방식

나는 최근 AI와 일하는 방식에서 꽤 큰 변화를 느꼈다.

처음에는 AI에게 바로 구현을 요청하는 일이 많았다.
하지만 시간이 지나면서, 그렇게 하면 원하는 결과가 잘 나오지 않는다는 것을 알게 되었다.
AI가 코드를 못 써서가 아니라, 내가 원하는 것이 충분히 정리되지 않은 상태였기 때문이다.

그래서 점점 방식을 바꾸기 시작했다.

먼저 내가 하고 싶은 것을 설명한다.
그다음 AI와 티키타카를 하면서 goal, 즉 목표를 확정한다.
goal이 어느 정도 정리되면, 그것을 구현하기 위한 spec, 즉 단계별 명세를 작성한다.
그리고 각 spec마다 반드시 판단해야 할 checklist, 즉 검증 기준을 관리한다.

이 흐름은 내가 하는 일에서 꽤 잘 먹혔다.

중요한 것은 프롬프트를 예쁘게 쓰는 것이 아니었다.
AI와 내가 같은 문제를 보고 있도록 만드는 것이 중요했다.
무엇이 목표인지, 어떤 제약이 있는지, 어떤 기준을 만족해야 하는지, 어디에서 실패할 수 있는지 서로 맞춰야 했다.

말하자면 shared context, 즉 AI와 내가 공유하는 작업 맥락을 만드는 과정이었다.

AI는 맥락이 충분할수록 더 좋은 결과를 낸다.
하지만 그 맥락은 저절로 생기지 않는다.
사람이 먼저 문제를 설명하고, 기준을 세우고, 필요한 질문을 던지고, AI가 이해한 것이 맞는지 확인해야 한다.

그러던 중 Matt Pocock의 Full Walkthrough: Workflow for AI Coding 영상을 보게 되었다.

이 영상에서 내가 크게 공감했던 것은, AI에게 바로 코드를 시키는 것이 아니라 AI와 내가 같은 맥락을 공유하고 있는지 먼저 확인해야 한다는 점이었다.
요구사항을 질문으로 압박하고, PRD로 목적지를 정리하고, 구현 가능한 작은 단위로 나누고, feedback loop를 통해 결과를 검증하는 과정이 중요해 보였다.

그걸 보면서 한 가지 생각이 들었다.

“내가 자연스럽게 하고 있는 걸, 다른 사람들도 하고 있을까?”

그리고 곧바로 다른 생각도 들었다.

“어쩌면 내가 틀릴 수도 있지 않을까?”

내가 당연하게 여기던 것은 모두에게 당연하지 않았다

나는 요즘 AI와 개발에 관한 콘텐츠를 많이 본다.
내 SNS도 그런 내용으로 많이 채워져 있다.
새로운 모델, 새로운 툴, 새로운 워크플로, AI와 일하는 방식에 대한 글들을 자주 본다.

그러다 보니 착각했다.

다른 사람들도 비슷한 정보를 보고 있을 것이라고.
다른 사람들도 비슷한 고민을 하고 있을 것이라고.
다른 사람들도 AI와 일하는 자기만의 방법을 빠르게 만들고 있을 것이라고.

하지만 실제로는 그렇지 않을 수 있다.

사람들은 각자의 관심사에 노출된다.
누군가는 AI보다 도메인 지식에 더 관심이 있을 수 있고, 누군가는 인프라나 운영에 더 관심이 있을 수 있다.
누군가는 아직 AI를 본격적으로 업무에 쓰지 않았을 수도 있다.
누군가는 AI를 쓰고 있지만, 단순히 코드 생성 도구 정도로만 사용하고 있을 수도 있다.

그 차이를 알게 되면서, 나는 문제를 조금 다르게 보기 시작했다.

내가 AI를 잘 쓰는 것만으로는 부족하다.
팀이 함께 잘해야 한다.

팀의 목표는 한 사람만으로 이루어내기 쉽지 않다.
나 혼자 빠르게 구현하고, 나 혼자 AI를 잘 쓰고, 나 혼자 좋은 판단을 하려고 해도 한계가 있다.
결국 팀 전체가 일정 수준 이상의 기준을 가져야 한다.

그리고 이 기준은 개인의 의지에만 맡겨서는 안 된다고 생각한다.

리더 역할도 다시 배워야 하는 일이다

이 고민을 하면서 최근에 읽은 글 하나도 계속 떠올랐다.

최고의 직원이 최악의 관리자가 되는 이유라는 글이었다.

이 글에서 인상 깊었던 점은, 뛰어난 개인 기여자가 관리자가 되는 것은 단순한 승진이 아니라 완전히 다른 직업으로 이동하는 일이라는 관점이었다.
기술적으로 잘하는 사람이라고 해서 자연스럽게 좋은 리더가 되는 것은 아니다.
리더에게는 기술 역량뿐 아니라, 사람을 이해하는 능력, 모호한 상황에서 판단하는 능력, 불편한 대화를 피하지 않는 능력, 팀 전체의 성공을 위해 환경을 설계하는 능력이 필요하다.

이 관점은 지금 내가 하는 고민과도 연결되어 있었다.

나는 백엔드 리드로서 동료가 더 나은 판단을 하길 바랐다.
처음에는 특정 판단에 대해 “이 방향은 위험하지 않을까?”라고 생각했다.
하지만 시간이 지나면서, 이 문제를 단순히 개인의 판단 문제로만 볼 수 없다는 생각이 들었다.

리더라면 팀원이 좋은 판단을 하길 기대하는 것에서 멈추면 안 된다.
그 판단이 자연스럽게 나올 수 있는 환경을 만들어야 한다.

좋은 코드베이스, 좋은 리뷰 문화, 좋은 질문 방식, 좋은 학습 구조가 있어야 한다.
어떤 사람이 들어오더라도 그 환경 안에서 더 높은 기준으로 사고하고 행동하게 만들어야 한다.

이건 AI 시대에도 똑같다.

AI를 잘 쓰는 사람이 몇 명 있는 것만으로는 팀이 좋아지지 않는다.
AI를 쓸 때 어떤 질문을 먼저 해야 하는지, 어떤 판단은 사람이 반드시 책임져야 하는지, 어떤 결과는 반드시 검증해야 하는지, 어떤 리스크는 명시적으로 기록해야 하는지에 대한 환경이 필요하다.

결국 내가 해야 할 일은 “내가 AI를 잘 쓰는 것”에서 끝나지 않는다.
리더로서 내가 해야 할 일은, 팀이 더 나은 판단을 할 수 있는 baseline을 만드는 것이다.

baseline을 높이는 환경

그래서 나는 요즘 “baseline”이라는 단어를 자주 생각한다.

여기서 내가 말하는 baseline은 개인에게 요구하는 근성이나 역량 목록이 아니다.
팀이 좋은 선택을 반복하게 만드는 기본 환경에 가깝다.
좋은 코드베이스, 좋은 리뷰 문화, 좋은 질문 방식, 빠른 feedback loop가 합쳐져 팀의 baseline을 만든다.

어떤 사람이 팀에 들어오더라도 자연스럽게 높은 기준에서 일하게 만드는 환경.
좋은 질문을 하게 만드는 환경.
리스크를 먼저 보게 만드는 환경.
기술부채를 알고 선택하게 만드는 환경.
AI에게 바로 구현을 맡기기 전에, 목표와 맥락을 먼저 정리하게 만드는 환경.

이건 단순히 동료들에게 “더 잘해야 한다”고 말하는 방식으로는 만들어지지 않는다.
리더인 나 역시 새로운 역할을 배워야 한다.
좋은 엔지니어였던 사람이 곧바로 좋은 리더가 되는 것이 아니듯, AI를 잘 쓰는 사람이 곧바로 팀의 AI baseline을 잘 끌어올리는 사람이 되는 것도 아니다.

그 사이에는 의도적인 학습과 실험이 필요하다.

사람은 환경에 영향을 많이 받는다.
좋은 코드베이스 안에서는 좋은 코드를 짤 가능성이 높아진다.
좋은 리뷰 문화 안에서는 더 좋은 판단을 배울 가능성이 높아진다.
좋은 질문이 오가는 팀에서는 문제를 더 깊게 볼 가능성이 높아진다.

반대로 기준이 낮은 환경에서는, 좋은 사람도 낮은 기준에 적응할 수 있다.
나쁜 구조가 계속 쌓여 있는 코드베이스에서는, 새로운 사람도 그 구조를 당연하게 받아들일 수 있다.
리스크를 설명하지 않는 문화에서는, 리스크를 모른 채 선택하는 일이 반복될 수 있다.

그래서 나는 AI 시대일수록 좋은 환경이 더 중요하다고 생각한다.

AI를 잘 쓰는 개인을 만드는 것도 중요하지만, 그보다 더 중요한 것은 AI와 함께 일할 때의 팀 기준을 만드는 일이다.

AI에게 작업을 요청하기 전에 무엇을 설명해야 하는가.
AI가 만든 결과를 어떤 기준으로 검토해야 하는가.
어떤 판단은 AI에게 맡기면 안 되는가.
어떤 책임은 반드시 사람이 가져야 하는가.
좋은 코드베이스를 만들기 위해 우리는 어떤 기본기를 다시 공부해야 하는가.

이런 질문들이 필요하다.

agent 에게 feedback 이 필요하다.

AI agent와 일할수록 feedback loop의 중요성도 더 크게 느낀다.

여기서 말하는 feedback loop는 AI가 만든 결과를 검증하고, 실패 정보를 다시 다음 시도에 넣는 구조를 말한다.

AI가 한 번에 좋은 결과를 내면 좋겠지만, 실제 개발은 그렇게 단순하지 않다.
타입이 깨질 수 있고, 테스트가 실패할 수 있고, 브라우저에서 동작하지 않을 수 있고, 코드가 요구사항을 만족하지 못할 수 있다.
사람이 보기에는 당연한 제약을 AI는 놓칠 수도 있다.

그래서 AI에게 일을 맡긴다는 것은 피드백 없이 방치한다는 뜻이 아니다.
오히려 더 좋은 피드백 루프를 만들어야 한다는 뜻에 가깝다.

타입체크, 테스트, 린트, 포맷팅, 브라우저 확인, pre-commit hook, 리뷰 기준, QA.
이런 것들은 예전에도 중요했지만, AI 시대에는 구현능력보다 검증하는 능력이 더중요해졌다.

사람은 같은 실패를 반복하면 지치지만, AI는 반복 자체에 지치지 않는다.
대신 실패를 알려주는 신호가 필요하다.
무엇이 틀렸는지, 어떤 기준을 만족하지 못했는지, 다음 시도에서 무엇을 고쳐야 하는지 알려주는 루프가 필요하다.

Ralph 같은 loop agent 개념도 이 관점에서 흥미롭다.
agent가 한 번 작업하고 끝나는 것이 아니라, 결과를 검증하고, 부족한 점을 다시 피드백으로 넣고, 완료 조건을 만족할 때까지 반복하는 방식이다.

나는 이 흐름이 AI 시대의 개발 방식에 중요한 힌트를 준다고 생각한다.

AI를 더 오래 돌리는 것이 핵심은 아니다.
AI가 무엇을 완료로 봐야 하는지, 어떤 실패를 다시 시도해야 하는지, 어디에서 멈춰야 하는지를 사람이 정의해야 한다.

결국 여기에서도 사람의 책임은 사라지지 않는다.

agent가 반복할 수 있도록 피드백 루프를 설계하는 책임.
완료 조건을 정의하는 책임.
잘못된 방향으로 계속 반복하지 않도록 멈춤 조건을 두는 책임.
그리고 그 결과를 실제 코드베이스의 품질 기준으로 검증하는 책임.

AI 시대에 좋은 코드베이스는 사람만을 위한 코드베이스가 아닐지도 모른다.
AI agent도 잘 읽고, 잘 고치고, 잘 검증할 수 있는 코드베이스여야 한다.
명확한 구조, 일관된 이름, 빠른 테스트, 좋은 문서, 분명한 책임 경계가 있는 코드베이스는 사람에게도 좋고 AI에게도 좋다.

AI 시대에 기본기는 더 중요해진다

AI가 코드를 써주는 시대가 되면 기본기가 덜 중요해질 것처럼 보일 수 있다.

하지만 나는 오히려 반대라고 느낀다.
AI가 코드를 더 빨리 써줄수록, 기본기는 더 중요해진다.

문제 정의를 못 하면 AI는 엉뚱한 문제를 빠르게 풀어준다.
책임 경계를 모르면 AI는 잘못된 위치에 로직을 넣어준다.
테스트 기준이 없으면 AI가 만든 코드가 맞는지 확인하기 어렵다.
좋은 코드베이스에 대한 감각이 없으면, AI가 만든 그럴듯한 코드가 장기적으로 어떤 비용을 만들지 보기 어렵다.

결국 AI는 내 사고를 대체한다기보다, 내 사고를 증폭한다.

내가 좋은 기준을 가지고 있으면 AI는 그 기준을 더 빠르게 실행하게 도와준다.
내가 흐릿한 기준을 가지고 있으면 AI는 그 흐릿함도 빠르게 코드로 만든다.

그래서 AI 시대에 우리가 해야 할 일은 단순히 AI 툴을 더 많이 배우는 것이 아니라고 생각한다.
물론 툴도 배워야 한다.
새로운 모델과 기능을 실험하는 것도 중요하다.

하지만 그보다 더 중요한 것은 엔지니어로서의 baseline을 다시 세우는 일이다.

무엇이 좋은 코드인가.
좋은 코드베이스는 어떤 구조를 가지고 있는가.
기술부채는 언제 감수할 수 있는가.
책임 경계는 어떻게 판단해야 하는가.
비즈니스 로직은 어디에 있어야 하는가.
AI가 만든 결과를 어떻게 검증해야 하는가.

이 질문들은 AI가 좋아질수록 더 중요해진다.

내가 하려는 실험

나는 지금 이 고민을 팀 안에서 실험하고 있다.

단순히 “AI를 이렇게 쓰세요”라고 말하고 싶지는 않다.
내 방식이 정답이라고 생각하지도 않는다.
내가 지금 쓰는 goal, spec, checklist 방식도 지금까지 나에게 잘 동작한 하나의 방법일 뿐이다.

다른 사람에게는 다른 방식이 더 잘 맞을 수도 있다.
그리고 내가 지금 믿고 있는 방식도 시간이 지나면 바뀔 수 있다.

다만 한 가지는 분명하다고 생각한다.

AI를 잘 쓰기 위해서는 AI에게 무엇을 시킬지 먼저 잘 생각해야 한다.
그리고 그 생각은 혼자만의 감각으로 끝나면 안 된다.
팀 안에서 공유 가능한 기준이 되어야 한다.

나 혼자에서 그치지 않고 동료들과 함께 세미나를 해보려고 한다.
AI 사용법만 이야기하는 세미나는 아니다.
좋은 코드베이스를 어떻게 만들지, 소프트웨어 공학의 기본을 어떻게 다시 공부할지, 우리가 어떤 기준으로 코드를 작성하고 리뷰할지 이야기해보고 싶다.

AI가 코드를 써주는 시대에, 우리는 오히려 더 사람다운 질문을 해야 한다.

이 코드는 왜 필요한가.
이 책임은 어디에 있어야 하는가.
이 선택은 어떤 리스크를 만드는가.
우리는 이 기술부채를 알고 지는가.
이 코드베이스는 다음 사람에게 좋은 행동을 요구하는가.
AI와 나는 같은 맥락을 공유하고 있는가.
AI agent는 어떤 feedback loop 안에서 일하고 있는가.

이 질문들이 팀의 baseline이 되었으면 한다.

나는 어떻게 하고 있지?

이 글을 쓰면서도 조심스러운 마음이 있다.

내가 경험한 한 장면을 너무 크게 해석하고 있는 것은 아닐까.
내가 쓰는 AI 활용 방식이 정말 좋은 방식이라고 말할 수 있을까.
내가 동료들에게 권장하려는 기준이 또 다른 강요가 되지는 않을까.

그래서 이 글은 결론이라기보다 질문에 가깝다.

AI는 이미 개발문화를 바꾸고 있다.
구현 비용은 낮아졌고, 개발자는 더 빠르게 결과물을 만들 수 있게 되었다.
하지만 그렇기 때문에 우리는 더 분명하게 생각해야 한다.

AI가 코드를 써주는 시대에, 우리는 무엇을 책임져야 할까?

나는 지금 그 답을 이렇게 생각하고 있다.

문제를 정의하는 책임.
책임 경계를 판단하는 책임.
리스크를 알고 기술부채를 지는 책임.
AI와 shared context를 만드는 책임.
feedback loop를 설계하는 책임.
좋은 코드베이스와 좋은 팀 문화를 만드는 책임.

AI가 코드를 대신 써줄 수는 있다.
하지만 우리가 어떤 엔지니어가 될지는 여전히 우리가 정해야 한다.

나는 이 질문을 팀 안에서 계속 실험해보고 싶다.

그리고 이 글을 읽는 사람에게도 같은 질문을 던져보고 싶다.

나는 지금 AI와 어떻게 일하고 있지?
AI가 내 판단을 더 좋게 만들고 있을까, 아니면 내 부족한 판단을 더 빠르게 코드로 만들고 있을까?

참고한 자료

시리즈 전체 보기