이제 AI에게 글쓰기와 읽기를 모두 맡길 때인가?

MMaximilian Schwarzmüller
컴퓨터/소프트웨어경영/리더십AI/미래기술

스크립트

00:00:00여전히 코드를 읽으시나요, 아니면 계속 읽어야 할까요?
00:00:04지난 주말 TechX에서 나온 질문이자 토론 주제였습니다.
00:00:09적어도 제 주변에서는요.
00:00:12흥미로운 질문이고, 분명히 자극적인 어그로성 질문이기도 하죠.
00:00:15하지만 이번 에피소드는 그 주제를 다루려는 게 아닙니다.
00:00:18질문에 답을 하긴 할 겁니다.
00:00:20제게는 간단히 예, 아니오로 답할 문제가 아니거든요.
00:00:22여러분 생각도 궁금합니다.
00:00:24정말 진심이에요.
00:00:25그러니 여러분의 생각도 공유해주세요.
00:00:26간단한 문제가 아니에요.
00:00:27나중에 다시 이 질문으로 돌아오겠습니다.
00:00:29하지만 먼저 짚고 넘어가야 할 다른 질문이 있어요.
00:00:32아직 코드를 직접 작성하시나요?
00:00:35만약 코드를 전부 직접 작성한다면 당연히 읽기도 하겠죠, 그렇죠?
00:00:40그러니 직접 짰다면 굳이 읽을 필요는 없을 테고요.
00:00:43하지만 저를 포함한 많은 개발자는 아마 코드를 전부 직접 작성하지는 않을 겁니다.
00:00:49코드를 얼마나 직접 작성하느냐는 0에서 100% 사이 어디든 될 수 있죠.
00:00:55그 질문에 대해 본인이 어느 정도 위치에 있는지 말이죠.
00:00:58저는 아마 지금은 100%에 꽤 가까울 겁니다.
00:01:03AI 모델이 좋아지면서 지난 6~8개월 동안 정말 많이 바뀌었습니다.
00:01:08다른 많은 개발자도 마찬가지였을 거라고 확신해요.
00:01:14가장 중요한 건, 이 모델들이 지시 사항을 더 잘 따르게 되었고,
00:01:18지시 수행 능력을 높이기 위해 미세 조정되었다는 점이죠.
00:01:20그리고 Claude Code 같은 주변 도구들도 있고요.
00:01:22그래서 제 상황이 변했습니다.
00:01:24다른 에피소드에서 이야기했었죠,
00:01:26그게 어떻게 개발이라는 직업의 즐거움을 많이 앗아가는지에 대해서요.
00:01:30저는 빼앗겨버린 코드 작성 부분이 아닌, 무언가를 구축하는 데서
00:01:33새로운 즐거움을 찾으려 노력하고 있습니다.
00:01:37앞서 언급했듯, 그 이야기는 다른 에피소드에서 다뤘으니,
00:01:39이번 에피소드 주제는 아닙니다.
00:01:42하지만 이게 첫 번째로 중요한 질문인 건 당연하죠.
00:01:45아직 코드를 직접 작성하시나요?
00:01:47여러분에게는 분명 예라는 답이 나올 수도 있습니다.
00:01:500%에 더 가까울 수도 있고, 그 범위 어디쯤일 수도 있죠.
00:01:55그건 전혀 문제없습니다.
00:01:57코딩에 관한 AI 혁명은 아직 초기 단계라
00:02:02어디가 적절한 지점인지 말하기에는 너무 이르다고 생각해요.
00:02:07점점 더 많은 소프트웨어가 AI에 의해 완전히 생성되는 장기적인 효과를 지켜봐야 할 겁니다.
00:02:12어디에 위치하든 확실한 사실이니까요.
00:02:16그게 첫 번째로 중요한 질문입니다.
00:02:18다른 질문과도 연결되어 있죠.
00:02:19그럼 이제 두 번째 질문은 어떨까요?
00:02:21여전히 코드를 읽으시나요?
00:02:22음, 다시 말하지만 이건 복잡해요. 나눌 수 있거든요.
00:02:26코드를 읽는 것과,
00:02:29코드를 신경 쓰는 것으로 나눌 수 있다고 봅니다.
00:02:33제게는 이게 같은 게 아닙니다.
00:02:36읽기는 하지만 신경 쓰지 않을 수도 있는데, 좀 바보 같은 짓이죠.
00:02:40거기에 대해 다시 이야기할 겁니다.
00:02:41아니면 읽지는 않는데 신경은 쓸 수도 있고, 그건 가능하다고 주장하고 싶네요.
00:02:45그리고 여기엔 함의가 있습니다.
00:02:47앞서 언급했듯, 읽지 않고 신경도 안 쓸 수 있고,
00:02:51읽기는 하는데 신경은 안 쓸 수도 있고,
00:02:55읽지는 않는데 신경은 쓸 수도 있죠.
00:02:58물론 읽고 신경 쓸 수도 있고요.
00:03:02읽기와 신경 쓰기라는 이 구분법에는 네 가지 조합이 있습니다.
00:03:08만약 읽지도 않고 신경도 쓰지 않는다면, 그게 제 정의로는 '와이프 코딩(Wipe Coding)'입니다.
00:03:14물론 다른 정의가 있을 수 있고 그것도 괜찮습니다.
00:03:17하지만 저는 그렇게 정의합니다.
00:03:20읽지 않고, 신경도 쓰지 않는 것, 그것이 와이프 코딩이죠.
00:03:22그렇다고 제품에 관심이 없다는 건 아닙니다.
00:03:25아마 관심이 있겠죠.
00:03:26왜냐면 제품에 관심이 없다면 애초에 무엇을 하고 있는 거겠어요, 그렇죠?
00:03:31하지만 그냥 제품에만 신경 쓸 수도 있습니다.
00:03:33작동만 하면 행복한 거죠.
00:03:34문제가 생기면 그냥 AI한테 야, 뭐 뭐 어쩌구, 작동이 안 돼.
00:03:38고쳐줘.
00:03:39그럼 코드에는 신경 안 쓰고 코드도 안 읽는 거니까요.
00:03:42그게 제 와이프 코딩의 정의입니다.
00:03:44자, 읽기는 하는데 신경 쓰지 않는다면 좀 이상하죠.
00:03:49그런 경우라면 그냥 시간 때우기 하는 거겠죠.
00:03:52읽기는 하는데 신경을 안 쓴다면, 돈을 받고 무언가를 해야 하는 직장에 있는 것일 수도 있고요.
00:03:57그래서 신경 쓰지도 않는 코드를 분석하며 시간을 보내는 거죠.
00:04:00잘 모르겠네요.
00:04:01여기가 제 초점은 아닙니다.
00:04:03하지만 확실히 그런 조합일 수도 있겠죠.
00:04:05자, 이제 더 흥미로운 조합들이 있습니다.
00:04:08읽지 않으면서 신경 쓰는 것과, 읽으면서 신경 쓰는 것이죠.
00:04:11일단 읽으면서 신경 쓰는 것부터 시작하죠.
00:04:13이게 가장 명확한 경우겠네요.
00:04:15이를 AI 기반 소프트웨어 엔지니어링 같은 것으로 부를 수 있겠죠.
00:04:20더 이상 코드를 작성하지 않거나, 전부 작성하지 않을 수는 있어도
00:04:24소프트웨어 엔지니어로서 신경을 쓰는 거죠.
00:04:26책임을 질 수도 있고요.
00:04:28그리고 신경 쓰고 책임을 지기 때문에 코드를 읽는 겁니다,
00:04:33무슨 일이 일어나고 있는지 확인하고 싶으니까요, 그렇죠?
00:04:35말이 되죠.
00:04:36그러니 그건 명확합니다.
00:04:37다시 돌아올 거고요.
00:04:38그럼 읽지 않으면서 신경 쓰는 건 어떨까요?
00:04:40이게 가능하긴 할까요?
00:04:42제 답은, 네, 가능합니다.
00:04:43가능하긴 하지만 어렵습니다.
00:04:46어쩌면 그것이 미래일 수도 있다고 주장할 수 있겠죠.
00:04:50지루한 답부터 하자면,
00:04:52당연히 저도 모릅니다.
00:04:53그게 미래일지는 저도 몰라요.
00:04:564년 전만 해도 언젠가 우리가 더 이상 코드를 직접 짜지 않게 되리라고는 상상도 못 했던 것처럼,
00:05:02말이죠.
00:05:03언젠가 우리가 코드를 아예 읽지 않게 되는 날을 아직 상상하지 못하는 것일 수도 있습니다.
00:05:09사실 우리는 아마 이런 스케일의 어딘가에 있게 되겠죠.
00:05:12이미 그런 스케일의 어딘가에 있다고 주장하고 싶네요.
00:05:15하지만 다시, 이 이야기도 나중에 하죠.
00:05:16자, 읽지 않으면서 신경 쓰는 것.
00:05:18이게 가능할까요?
00:05:20언급했듯, 제 생각엔, 네, 아마 가능할 겁니다.
00:05:24하지만 소프트웨어에 대해 생각하는 완전히 다른 방식입니다.
00:05:27AI를 신뢰하는 데 의존하는 거죠. 단순히 코드를 짜는 것뿐만 아니라, 여러분은
00:05:34아마 AI를 코드 리뷰용으로, 코드베이스 스캔이나 분석용으로, 또는
00:05:40코드베이스 감사용으로도 사용하고 있을 겁니다.
00:05:41물론 그렇게 할 수도 있죠.
00:05:43Fable 5가 있는 클라우드 코드나, Codex, 아니면 제가 가장 좋아하는 에이전트인 Pi를 가장 좋아하는 AI 모델과 함께 코드 작업에 사용할 수 있고요.
00:05:55그리고 새로운 세션에서 동일하거나 다른 모델과 같은 에이전트를 사용하거나, 다른 세션에서 다른 에이전트와 다른 모델을 사용할 수도 있습니다.
00:06:03어떤 조합이든, 코드 리뷰나 최신 변경 사항 리뷰, 코드베이스 전체에 대한 빈번한 감사를 위해 그렇게 사용할 수 있죠.
00:06:12그런 식으로 작업을 할 수 있어요.
00:06:13여러분은 계획을 세우고 그 계획을 읽거나 명세를 읽는 데 많은 시간을 할애할 수도 있고, 그래야 할 겁니다.
00:06:22코드를 읽지 않는 게 올바른 방향으로 이루어진다면, 즉 그것이 미래라면, 아무것도 읽지 않는다는 뜻은 아니어야 합니다.
00:06:32AI와 함께 좋은 계획을 만드는 데 더 많은 시간을 할애해야 하고, 올바른 구현 상세와 함께 적절한 작업을 하고 있는지 확실히 해야 하죠.
00:06:47제대로 한다면, 제품뿐만 아니라 아키텍처와 구축 블록에도 신경을 쓰는 겁니다.
00:06:54명세와 계획에 더 많은 시간을 할애하고 AI에게 구현을 맡기면 더 좋은 결과를 얻을 가능성을 높일 수 있죠.
00:07:08그리고 리뷰 에이전트에게도 그 명세나 AI가 구현해야 할 계획에 대한 접근 권한을 주는 코드 리뷰를 할 수도 있고요.
00:07:15물론 여기서 여전히 문제가 되는 점은, 그래서 제가 아예 아무것도 읽지 않는 트레인에 타지 않은 것인데, 코드베이스에서 무슨 일이 일어나는지 확신할 수 없다는 겁니다.
00:07:29절대 그럴 수 없죠. 읽지 않으면 확실히 알 수가 없으니까요.
00:07:33물론 AI에게 원하는 코드를 생성하도록 시도하고 AI를 리뷰에 사용할 수는 있지만, 들여다보지 않으면 100% 확신을 가질 순 없어요.
00:07:44그건 코딩뿐만 아니라 모든 것에 해당하는 말이죠.
00:07:46삶의 모든 영역에서 사실인 말입니다.
00:07:48AI나 변호사가, 굳이 AI가 아니더라도 계약서를 초안으로 작성해주는데, 읽지도 않고 그냥 서명하면 뭐가 들어 있는지 확신할 수 없잖아요.
00:08:00그럴 수도 있고 아닐 수도 있지만요.
00:08:03저는 개인적으로 그렇게 안 합니다.
00:08:05저는 개인적으로 코드를 읽는 편인데, 이제 그게 흥미로운 부분일 수도 있겠네요.
00:08:13다시 말하지만, 저는 코드를 100% 다 읽지는 않습니다.
00:08:19제가 그 스케일의 어디쯤 있는지 말하기 어렵네요.
00:08:24아마 중간쯤일 겁니다. 왜냐면 AI가 주는 코드를 모두 리뷰하니까요.
00:08:31하지만 그게 모든 줄을 꼭 읽는다는 뜻은 아닙니다.
00:08:36중요한 부분을 먼저 뛰어든다는 뜻이고, 저는 소프트웨어 엔지니어로서 그걸 식별할 수 있습니다.
00:08:42어떤 빌딩 블록이 중요한 부분인지, 혹은 특정 풀 리퀘스트나 커밋의 어떤 부분이 중요한 부분인지 알거든요.
00:08:51그쪽으로 뛰어듭니다.
00:08:53분석하죠.
00:08:54비판적인 부분들도 확인하고요.
00:08:56그리고 AI가 실수를 자주 하는 부분들이 어딘지 아니까 그쪽을 집중적으로 봅니다.
00:08:59그게 제가 리뷰하는 방식입니다.
00:09:01덜 중요한 부분은 그냥 스캔하거나 간단히 훑어볼 수도 있고요.
00:09:07예를 들어, AI가 환경 변수를 읽고 파싱하는 코드를 작성할 때는,
00:09:16매 줄을 다 읽지는 않을 수도 있습니다.
00:09:18하지만 일반적인 접근 방식은 확인하고 싶은데, 특히 AI는 예를 들어, 너무 방어적인 코드를 작성해서, 폴백의 폴백의 폴백을 만드는 경향이 있기 때문이죠.
00:09:27전 그런 걸 피하고 싶거든요.
00:09:28그래서 그런 부분은 직접 체크하지만, 정수를 어떻게 파싱하는지와 같은 세세한 부분에는 신경 쓰지 않습니다.
00:09:36그게 현재 제 위치라고 할 수 있겠네요.
00:09:42하지만 코드를 작성하는 것과 마찬가지로, 앞으로 100% 읽지 않는 방향으로 얼마나 이동하게 될지는 저도 모르겠습니다.
00:09:50100%가 될지는 모르겠어요.
00:09:54미래를 내다볼 순 없으니까요.
00:09:55작성과 읽기 모두 100% AI로 가게 된다면, 우리 소프트웨어 엔지니어들에게 무슨 의미가 될지 지켜봐야겠죠.
00:10:06AI에게 적절한 작업을 지시하고, 서명 시스템과 아키텍처에 대해 아는 건 여전히 매우 중요할지도 모릅니다.
00:10:15우리가 그런 방향으로 이동하고 있다고 생각합니다.
00:10:18하지만 분명히, 말하기는 어렵죠.
00:10:21어느 시점에 코드를 전혀 작성하지 않고 읽지도 않게 된다면, 여전히 코딩 방법을 알아야 하는지 하는 의문이 들겠죠, 그렇죠?
00:10:31코드를 읽거나 쓰는 능력을 갖추는 게 가치 있는 일일까요, 그렇죠?
00:10:35그게 여전히 중요할까요?
00:10:36지금 당장은 제게는 여전히 중요합니다.
00:10:39결국 중요한 질문은, 여러분이 무엇을 신경 쓰느냐 하는 거죠, 그렇죠?
00:10:44그게 다른 부분인, 신경 쓰기입니다.
00:10:46읽기는 하나의 부분이지만, 우리는 신경 쓰기 때문에 읽는 것이고, 앞서 말했듯이 읽지 않고도 신경 쓸 수 있습니다.
00:10:53하지만 신경 쓴다는 게 대체 무슨 의미일까요?
00:10:55신경 쓴다는 건 분명 많은 것을 의미할 수 있습니다.
00:11:03코드 스타일 같은 걸 의미할 수도 있죠.
00:11:06코드 스타일, 함수 생성 방식, 거기서 사용된 접근 방식 등에 신경 쓸 수 있습니다.
00:11:13객체 지향 프로그래밍을 쓸지, 함수형 프로그래밍을 쓸지 같은 더 큰 결정에도 신경 쓸 수 있죠.
00:11:21프로그램의 가독성에 신경 쓸 수도 있고요.
00:11:26보안이나 신뢰성 같은 것에도 신경 쓸 수 있습니다.
00:11:33그 외에도 고려할 차원은 많습니다.
00:11:35이제 중요도가 덜한 차원들이 몇 가지 있습니다.
00:11:39코드 스타일, 가독성, 특히 읽지 않는다면 그다지 중요하지 않죠.
00:11:44그런 경우라면 AI가 코드를 읽고 이해할 수 있는지가 중요할 뿐입니다.
00:11:50그리고 대부분 그 정도로 괜찮을 겁니다.
00:11:53자, 코드 스타일은 토큰 효율성 측면에서는 여전히 중요할 수 있습니다.
00:11:58언급했듯, AI가 불필요한 체크를 많이 넣는 경향이 있는 코드베이스가 있다면, 일부 AI 모델들은 그렇게 하죠,
00:12:04AI가 그 코드를 분석할 때 토큰을 더 많이 소모하게 될 테니까요.
00:12:11그래서 여전히 신경 쓸 부분이지만, 과거만큼 중요하지 않을 수도 있습니다.
00:12:18과거에는 우리 모두 코드 스타일에 대한 각자의 선호가 있었죠.
00:12:22하지만 제 경우, 그건 확실히 바뀌었습니다.
00:12:24확실히 바뀌었어요.
00:12:26물론 보안, 신뢰성, 테스트 가능성 같은 것들은 여전히 매우 중요합니다.
00:12:34소프트웨어에서 정말 중요한 게 있다면 바로 그것들이죠.
00:12:39해야 할 일을 정확히 수행하기를 원하니까요.
00:12:41안전하게 수행하기를 원하고요.
00:12:43성능도 신경 쓸 수 있겠죠.
00:12:46성능은 신경 써야 합니다.
00:12:47안정적이어야 하고요.
00:12:48사용자에게 무작위로 충돌을 일으키지 말아야 하죠.
00:12:51그리고 이런 것들은 현대 소프트웨어에서 우리가 보는 것들입니다.
00:12:54현대 소프트웨어는 신뢰할 수 없는 경우가 많고, 보안이 취약할 수도 있습니다.
00:12:58AI 모델이 보안 취약점을 찾는 데는 능숙해서 100% 보안을 달성하기란 특히 어렵죠,
00:13:04우리가 그런 일을 할 수 있는 최신 모델에 접근하지 못할 수도 있고요.
00:13:10하지만 그건 다른 논의입니다.
00:13:11그래도 신경은 써야 합니다.
00:13:13그게 제 요점입니다.
00:13:14제 생각엔 안전하고 신뢰할 수 있고 성능 좋은 소프트웨어를 구축하려고 노력해야 합니다.
00:13:20소프트웨어 엔지니어로서, 프로젝트에 어떤 패턴과 라이브러리를 사용할지에 대한 의견을 제시하고 싶을 수도 있고요.
00:13:30그 부분이 시스템 디자인이나 소프트웨어 아키텍처 영역으로 옮겨가는 것인데, 시스템 디자인과 소프트웨어 아키텍처는 같은 것이 아닙니다.
00:13:39하지만 여전히 중요한 것들이죠.
00:13:44코드를 100% 읽지 않는 방향으로 갈수록 좋은 명세와 계획을 갖는 게 중요합니다.
00:13:57이 모든 것에는 옳고 그름이 없다고 분명히 말씀드리고 싶네요.
00:14:02그래서 명세와 계획이 더 중요해지는 것이죠. 코드 스타일이나 가독성은 덜 신경 쓰더라도 보안과 신뢰성은 확실히 보장해야 하니까요.
00:14:18그래서 코드를 여전히 읽느냐는 질문은 앞서 언급했듯 약간의 어그로성 질문이기도 하고 답하기 쉽지 않습니다.
00:14:30옳고 그름은 없죠.
00:14:34덧붙이자면, 당연한 이야기지만, 큰 차이도 있습니다.
00:14:37수천, 수십만, 수백만 명이 사용하는 프로덕션 환경의 소프트웨어냐에 따라 다르고, 어떤 분야에서 일하느냐에 따라서도 다르죠.
00:14:49은행 쪽이라면, 소프트웨어 오류가 치명적인 결과를 낳을 수도 있죠. 은행뿐만 아니라 건강, 방위, 테크 분야 등 더 중요한 곳들도 분명히 많습니다.
00:15:05그래서 중요한 부분입니다.
00:15:10사용자가 0명인 인디 해커라면, 코드를 그렇게 신경 쓰지 않아도 되겠죠.
00:15:18하지만 전반적으로 볼 때, 코드 작성과 마찬가지로 코드를 읽지 않는 것도 100%에 가까워지는 추세를 볼 수 있을 겁니다.
00:15:32100%가 될지, 그렇게 가야 하는지, 그게 좋은 생각인지는 확신이 안 서네요.
00:15:38그리고 절대 신경 쓰는 걸 멈춰서는 안 됩니다.
00:15:41그리고 가장 큰 질문은, 읽지 않고도 신경 쓸 수 있느냐는 거죠.
00:15:45그게 정말, 정말, 정말로 가능할까요?
00:15:48확신이 안 서네요.
00:15:49제게 AI에 대한 그 정도 신뢰는 없거든요.
00:15:53언젠가 바뀔지 어떨지 모르겠습니다.
00:15:56바뀔 수도 있죠.
00:15:57가능성을 배제하진 않습니다.
00:15:58코드를 짜고 안 짜고가 변해온 것처럼요.
00:16:03하지만 지금은 여전히 읽고 신경 쓰는 편이거나, 언급했듯이 그 스케일의 중간쯤에 있습니다.
00:16:11하지만 또한 언급했듯이, 여러분이 어느 위치에 있는지 알려주세요.
00:16:150% 읽기, 100% 읽기, 아니면 여전히 100% 코드 작성 중이신가요?
00:16:19그게 올바른 방향일 수도 있죠.
00:16:21알려주세요.
00:16:22그리고 이 주제 전반에 대한 여러분의 생각도 알려주세요.

핵심 요약

AI가 코드 작성을 대체하는 흐름 속에서 개발자는 코드 자체의 읽기 여부를 넘어 보안, 신뢰성, 시스템 아키텍처에 대한 책임과 식별 능력을 유지하는 것이 중요하다.

하이라이트

  • 소프트웨어 개발자의 코딩 방식은 AI 도구의 발전으로 직접 작성 비율이 0%에서 100% 사이로 크게 변화하고 있다.

  • 코드를 읽는 행위와 코드의 품질 및 결과에 관심을 갖는 행위는 구분되어야 한다.

  • 코드를 전혀 읽지 않으면서 제품의 아키텍처와 구현 결과에만 집중하는 것은 소위 '와이프 코딩(Wipe Coding)'으로 정의된다.

  • AI가 작성한 코드를 리뷰할 때는 전체 코드를 읽기보다 중요한 빌딩 블록, 보안, 잠재적 오류 발생 지점을 집중적으로 분석하는 것이 효율적이다.

  • 소프트웨어 프로젝트의 규모나 분야에 따라 코드를 읽고 검증하는 방식은 달라야 하며, 금융이나 의료 등 치명적인 오류가 발생할 수 있는 분야는 더욱 정밀한 검증이 필요하다.

타임라인

코딩의 새로운 현실과 AI

  • 개발자가 코드를 직접 작성하는 비율은 0%에서 100%까지 매우 다양하다.
  • AI 모델의 지시 수행 능력 향상과 Claude Code 같은 도구의 등장이 개발 방식을 변화시켰다.
  • AI를 활용한 코딩은 아직 초기 단계이므로 적절한 수준을 찾는 과정이 필요하다.

과거와 달리 많은 개발자가 코드를 전부 직접 작성하지 않는다. AI의 성능 향상으로 인해 지시 사항을 따르는 능력이 정교해졌으며, 이로 인해 개발의 즐거움과 방식이 재정의되고 있다. 현재 어디가 적절한 지점인지 단정하기는 이르지만, 장기적으로 AI가 소프트웨어를 생성하는 환경에 적응해야 한다.

코딩의 두 차원: 읽기와 신경 쓰기

  • 코딩은 코드를 읽는 행위와 결과물에 신경 쓰는 행위로 분리할 수 있다.
  • 읽지도 않고 신경도 쓰지 않는 상태를 '와이프 코딩'으로 정의한다.
  • 코드를 읽지 않으면서 결과에 신경 쓰는 것은 AI에 대한 깊은 신뢰와 철저한 명세 계획을 요구한다.

코드를 읽기와 신경 쓰기라는 두 축으로 나누어 4가지 조합을 도출한다. 읽지 않고 신경도 쓰지 않는 '와이프 코딩'은 단순히 작동 여부만 확인하는 방식이다. 읽지 않으면서도 신경을 쓰는 것은 코드 리뷰 에이전트와 명세서를 활용해 시스템 디자인에 집중하는 보다 고도화된 미래형 작업 방식을 의미할 수 있다.

실전에서의 AI 코드 리뷰 전략

  • 코드를 읽지 않으면 잠재적인 보안 위험이나 오류를 100% 확신할 수 없다.
  • 리뷰 시 코드 전체를 읽기보다 비판적인 블록과 AI가 자주 실수하는 지점을 집중적으로 분석한다.
  • 정수 파싱 같은 세부 구현보다는 일반적인 접근 방식과 아키텍처 결정에 집중한다.

AI가 작성한 코드를 검증하기 위해 코드베이스의 특정 부분만을 선별적으로 분석하는 전략을 취한다. 환경 변수 처리나 방어적 코딩 습관 등 AI의 반복적인 패턴을 식별하고, 비판적인 영역을 직접 들여다봄으로써 리소스를 효율적으로 배분한다.

미래의 소프트웨어 엔지니어링

  • 코드 스타일이나 가독성보다 보안, 신뢰성, 성능이 여전히 핵심 가치이다.
  • 프로젝트의 성격에 따라 코드를 검증하는 엄격함의 기준은 달라야 한다.
  • AI 시대에도 소프트웨어 엔지니어는 아키텍처와 시스템 디자인에 대한 의견을 제시해야 한다.

코드 스타일은 AI가 분석하는 데 필요한 토큰 효율성 측면에서만 일부 중요해졌을 뿐, 과거만큼의 중요성을 갖지는 않는다. 반면, 보안과 신뢰성은 여전히 소프트웨어 엔지니어가 책임져야 할 필수 영역이다. 사용자가 많은 프로덕션 환경이나 금융·의료 분야일수록 AI에 대한 맹신보다는 시스템 전반에 대한 깊은 관여가 필수적이다.

커뮤니티 글

모든 글 보기