Okay. Hello. Hey everyone. Thanks for joining in. Today uh we will be talking about how to kill the code reviews.

Everyone's favorite topic. I'm Ankit, co-founder of Aviator. At Aviator, we are building AI code verification platform.

So we'll bring in some of the ideas and concepts that we talk about in the uh that we build in our product. Uh but first, let's dive into a little bit.

So a few months ago I wrote a post on latent space about uh how to kill code review creating a framework a five layers trust model. So this model was focused around how do we actually layer by layer build trust into the code that can then be merged without needing line by line review.

And I got some things right and I got some things wrong. So this talk will be about just really diving a bit more into it. I'm not going to talk about specific layers but we will talk about some of the concepts that emerge from this session.

So let's just talk about the problem we are looking today at the volume of code is increasing every day and we are struggling to keep up.

So when we think about like how long will it take us to actually stop reading code line by line and the reality is we've already stopped reviewing it there is 861% code churn that means we are like producing more code the incidence to PR ratio is increasing that means even if you're doing reviews today they're not effective so the medium time of review is increasing we have just increased the bottleneck to from the coding now kind of like coding is solved to now reviewing where everything just gets stuck there.

You're spending 4x the time that you were spending before just waiting for the reviews.

And today over 30% of changes are actually getting merged without a review at all. So let's just think about it a little bit.

Think about AI reviews. So everyone is probably using some form of AI reviews today. when AI write the code and AI review the code, why are we doing it in a UI, right?

Like we open a GitHub, there's kind of like, you know, maybe two or three AI coding agents who are like doing the reviews. You know, you the review goes back pass to the user and or the agent and it gets resolved and they're kind of like you're doing back and forth with the agent.

like you're eventually just looking at okay you know if AI has reviewed it most of the things probably found let's just kind of like you know do a skimming of it and merge it so when AI reviews and nobody reads we have configured the wrong thing so let's just take a step back code reviews are not very old they're maybe 15 to 20 years ago in 2006 was when Google launched Montrean internally when they made formal code review as a thing if you think about Windows back in the days.

The first versions were actually built without reviews. But if we look carefully, code review is not just about code reviews.

You know, obviously we are looking at it like catching bugs, understanding kind of conventions, identifying security issues, but code reviews is also about alignment.

And this was one piece which was missing from my five layers model that I talked about a few months ago. So a big part of code reviews is knowledge sharing, mentorship, architectural feedback, on boarding, being able to collaborate.

This is again if you're doing um white coding, you're working as a solo project, this is not a talk for you. If you are working in teams, which I believe most of you folks are collaborating in teams, you're not likely using completely dock factories orchestrators where nobody looks at the code.

You're actually collaborating in teams. you need to do knowledge sharing which is the alignment part and that is the part which is the most important aspect of release.

So for semantic accuracy we can build better tooling but alignment must survive. So let's just kind of like dive into alignment. What does it mean? Like in today's world can we actually think of better model than aligning just based on reading line by line code.

So most folks have probably heard about specdriven development by now. So specdriven development is like okay we write a spec you know um it covers all the details we pass it to an agent it generates a code and then we verify.

So what's wrong here? If you look back in 1970 this is what waterfall model was.

You know you have requirements you have specification you implement and then you verify but there's no feedback loop. You know the spec is written before we identified everything else. Right?

That's why today everyone still wants to use your coding sessions whether it's clot code, codeex, cursor, whatever you're using. You want to interact with the agents and the reason you're interacting with agents is because there were certain things which are not clear in the spec and we still need to capture that.

And second is as you implement you identify more issues and you never go back and update the spec because like if you're doing a spec development it's already done. Once the spec is done you expect like you know the code will come deterministically. But guess what? LLM is not deterministic.

It's going to make decisions itself. So that's why specdriven development is a great uh methodology, but it falls short in day-to-day software development. But there are some interesting aspects of this which we should carry forward. The most important part is the intent and intent doesn't only live in the spec.

Intent live in your zero ticket. That's the goal, right? Like it's kind of like where you express what we want to do.

It lives in your pods. It's kind of like details like it's a plan. But most importantly, it lives in your prompts today. This is where the real decisions are being made.

You start with like, okay, this is a zero ticket I'm going to look at, but you're going back and forth with the agent and this is where all the user decisions are being made.

But what we do today is we create a change, we create a pull request, and then we throw away the cross.

And this is one of the things that we need to change. Let's just first talk also about semantic accuracy because like you know you're saying hey an okay I understand the alignment part but like there are still bugs in the code who's going to look at that lms are also not great at this and we already talked about how AI agents may reviewers may not also be perfect so this is where I introduce you to a concept of AI slop registry so think about this we are reviewing if you're reviewing code today manually and I expect everyone should be doing some degree of this we are essentially possibly identifying the same issues over and over again.

Can we actually capture these concepts and codify them so that we don't have to always create those review feedback one by one. You actually also have all of those things automatically identified.

The beauty of this is if you do it a few times, you now build sort of like a system which actually learns over time.

So think of this as sort of like you're not you know you're doing more training on top of the standard LLM that you have actually extracted like built on top of.

So AI slop registers now can create better results because it's trained it's learning from the review experience that you as humans are providing.

Every recurring comment is now a guardrail that you don't have to review again. Okay, so let's kind of like try to put both of these alignment and the semantic accuracy together.

It is two halves of the same problem. We are trying to understand what are the core mechanics of review. How do we actually break it down into two parts which is the alignment and the semantic accuracy and bring them together into a single loop.

So first thing is you go take your session and you capture the uh user responses and that essentially forms your acceptance criteria.

This acceptance criteria then tied with your AI slop register that you are now constantly maintaining finally creates a test plan and this is the test plan which then gets verified. This is part of the system that we're building is the verification system where it spins up a preview, takes your test plan and make sure it actually works end to end.

Even if the code looks right, does it actually work?

So this verification parts become interesting. And now the kicker is this is now your review surface. You're not reviewing code line by line, but rather you're looking at the evidence of what was the intent.

Did the user actually implement the capability that was defined in the intent and did the behavior actually meet the requirements that we had in the accept as acceptance criteria. So you're still having the architectural decisions, you're still having these arguments but the review surface changes.

So just giving a walkthrough of like how we have built our system. The session becomes a criteria. So all these decisions that you are doing here with the agent you're asking uh you know you're providing this feedback like even if there is a simple task many times you're going back and forth agent will stop to ask questions.

These are the decision that we need to capture. This is the intent. This is what makes your review makes your collaboration more valuable.

This is how you teach your junior engineers on how to improve over time. And these are the decisions which make a software engineer valuable today.

We convert those into an acceptance criteria. This is where you can also leverage LLM to do so. So you capture these user uh decisions and make sure you can actually create a test plan based on this.

I know test plan creation is always painful which is where I would also recommend people to use LLM for this purpose.

And finally the criteria plus invariant is what makes the test plan and we build the verification systems to actually capture the test plan run your previews and be able to test based on this test plan. So even imagine if you're building a new feature you don't have to maintain test at all.

This is creating test in real time and this is where you can leverage the power of LLM because the test plan maintenance and creation can be very painful but the value of human in the loop here is the governance and the review part and the part where you're reviewing the test plan and not the code.

Right? I know it's been like over 20 years we came up with test-driven development. This in some ways is closer to behavior devel driven development where the test plan is now something which even you can share with your product managers, your designers, everyone can participate because these things are now in English.

At the same time we have now deterministic verification which actually verifies whether the particular test criteria has been met or not.

Let's move on. So this is where I would say the system is not supposed to be perfect. It's deterministic where it can be but LLM where you must. Not everything can be deterministic.

Not every system can be built in a way which is 100% built on deterministic uh systems. This is where you use LLM as a fallback. Let me give you an example. Like if you're making a change in your web application, what you can do is it creates a test plan of what the behavior changes.

Let's say you introduce a new payment uh form.

So it creates a new payment form. The verification here is does the payment system changes.

a an AI agent can go and browse through your application to fill out a form and capture screenshots as evidence and then take those screenshots as well as your database snapshots to identify whether the criteria was met.

So the screenshot testing or like sampling can then still be done by agents, but at the same time you're creating more solid evidence which now a reviewer can look at and build more confidence that this actually works.

So now reviewers are reviewing the intent, not the diff. You're reviewing the intent decisions uh what we said to build out what we tried and rejected and capture all of these things from the sessions. Remember capturing it from the sessions is the key.

If we try to build it from the code, you end up in the same situation that we were talking about. I think Dex was talking about yesterday which is if your code is built by the same agent which is actually building a test plan.

It's not going to build a test plan which will actually catch issues.

So that's why it's important to actually use the session information to build out a test plan. You can discuss architectural decisions.

So how you're creating the data models, how these services interact with each other. So you're moved one level above. So you're essentially instead of like reviewing line by line, you're actually having discussions on architecture which are very critical for any kind of collaboration.

And then you look at the evidence, everything that was collected from the verification. So here's a homework for everyone. Go home and mine your last 1,000 review comments and build out a AI swap register for the things which are repeatable.

So a vast majority of the comments that we're providing in your code review are something that we repeat over and over again. This compounds with every merged PR. Every time you capture something as a register, you don't have to capture that comment again.

And this is where you can actually codify some of the best practices of doing code, maintain semantic accuracy. At the same time, do not lose the collaboration part of the review.

It does follow a J curve. So PIN is real. uh you will have to spend some time to actually make it pay off because initially creating a registry can take some time and this is where I would recommend you folks can come and try out our product.

So code review is not just about code review it is about uh really getting the alignment and where we can build better tools is creating the semantic accuracy and defining your AI slop register.

So if you remember one thing from today, remember code review is not just about code review.

It is about getting the alignment. And yes, we are piloting our new product called verify. Uh please uh join and be our early design partners. We are working with a few companies to uh pilot out a new verification system.

This combines both the alignment side of things as well as building tools and capabilities for detecting semantic accuracy using the AI's lock register.

[한글자막] 코드 리뷰를 완전히 없애는 방법: diff 대신 의도를 검증하세요

Tech Bridge

코드 라인을 일일이 확인하는 대신, 개발 세션에서 생성된 의도와 수락 기준을 캡처하여 테스트 계획을 자동화하십시오.

반복되는 리뷰 코멘트를 'AI 슬롭 레지스터'로 데이터화하여 시스템이 스스로 모범 사례를 학습하고 의미적 정확성을 검증하도록 구축하십시오.

코드 리뷰의 본질인 팀 간의 정렬(Alignment)과 아키텍처 논의에 집중하고, 검증은 결정론적 시스템과 LLM 폴백을 조합한 자동화 프로세스로 대체하십시오.

실제 통계에 따르면 개발자들은 과거보다 리뷰를 기다리는 데 약 4배 더 많은 시간을 소모하고 있습니다. 현재 이미 전체 변경 사항의 30% 이상이 리뷰 없이 병합되고 있는 상황에서, **AI가 코드를 작성하고 AI가 리뷰하는 과정에서 인간의 실질적인 검토 역할은 점점 희미해지고 있습니다.**

코드 리뷰의 본질: 의미적 정확성과 정렬(Alignment)

코드 리뷰의 역사는 2006년 구글의 '몬트리안' 도입으로 공식화되었습니다. 리뷰는 단순히 버그를 잡거나 보안 문제를 식별하는 것 이상의 가치를 지닙니다. **코드 리뷰의 핵심은 팀 구성원 간의 아키텍처 피드백, 지식 공유, 멘토링을 포함하는 '정렬(Alignment)' 과정입니다.**

팀 단위로 협업하는 환경에서 코드 리뷰는 정렬을 유지하는 필수 장치입니다. 우리가 지향해야 할 방향은 코드 한 줄을 읽는 것에서 벗어나, **의도(Intent)와 정렬이라는 상위 수준의 검증 모델로 진화하는 것입니다.**

사양 기반 개발의 한계와 새로운 대안: 의도 중심 개발

명세 기반 개발(Spec-driven development)은 이상적이지만, LLM의 비결정론적 특성과 개발 과정에서의 유동적인 요구사항 변경 때문에 실무 적용에 한계가 있습니다. **우리는 명세서뿐만 아니라 지라 티켓, 코드, 그리고 에이전트와의 프롬프트 상호작용 속에 담긴 '의도'에 집중해야 합니다.**

반복되는 피드백을 시스템화하기 위해 'AI 슬롭 레지스터(AI Slop Registry)' 개념을 도입해야 합니다. **반복되는 코드 코멘트를 가이드라인으로 코드화하여 학습시키면, 의미적 정확성을 자동으로 유지하면서 중복 리뷰 과정을 제거할 수 있습니다.**

AI 기반 검증 시스템의 통합 루프 구축

새로운 리뷰 방식은 에이전트와 나눈 대화 세션을 수락 기준(Acceptance Criteria)으로 캡처하는 것에서 시작합니다. **시스템은 이 수락 기준과 AI 슬롭 레지스터를 결합하여 테스트 플랜을 자동으로 생성하고, 검증 시스템이 이를 실시간으로 실행하여 코드의 동작을 확인합니다.**

이 과정에서 인간의 역할은 코드를 한 줄씩 읽는 것이 아니라, **테스트 계획 자체를 거버넌스 관점에서 검토하고 의도가 실제 결과물과 일치하는지 확인하는 고차원적인 협업으로 전환됩니다.**

실행 전략: 결정론적 구현과 LLM의 조화

모든 것을 LLM에 의존할 수는 없습니다. 가능한 곳은 결정론적 시스템으로 구현하고, 복잡한 판단이 필요한 곳에 LLM을 폴백(fallback)으로 활용해야 합니다. **결제 시스템과 같은 핵심 기능을 검증할 때 AI 에이전트가 데이터베이스 스냅샷과 스크린샷을 대조하는 방식이 대표적인 예시입니다.**

개발자들에게 드리는 실천 과제는 지난 1,000개의 리뷰 코멘트를 분석하여 **'AI 슬롭 레지스터'를 구축하는 것입니다. 이를 통해 반복되는 기술적 부채를 체계화하고, 코드 리뷰를 단순한 점검이 아닌 진정한 팀 정렬을 위한 협업 도구로 재정의하시기 바랍니다.**

안녕하세요. 여러분, 함께해주셔서 감사합니다. 오늘은 코드 리뷰를 완전히 없애는 방법에 대해 이야기해보려 합니다.

모두가 좋아하는 주제죠. 저는 Aviator의 공동 창업자인 앙킷입니다. Aviator에서는 AI 코드 검증 플랫폼을 만들고 있습니다.

저희 제품을 통해 다루고 있는 아이디어와 개념들을 몇 가지 소개하고자 합니다. 우선, 조금 더 깊이 들어가 보겠습니다.

몇 달 전, 저는 Latent Space에 코드 리뷰를 없애는 방법과 5단계 신뢰 모델을 만드는 프레임워크에 대한 글을 썼습니다. 이 모델은 한 줄씩 리뷰하지 않고도 코드를 병합할 수 있도록 단계별로 어떻게 신뢰를 구축할지에 초점을 맞췄습니다.

글을 쓰면서 맞게 본 부분도, 틀린 부분도 있었습니다. 그래서 이번 발표에서는 그 내용을 조금 더 자세히 다뤄보고자 합니다. 구체적인 단계에 대해서는 언급하지 않겠지만, 이 세션에서 도출된 몇 가지 개념에 대해 이야기하겠습니다.

먼저 우리가 오늘 직면한 문제를 살펴보죠. 코드의 양은 매일 증가하고 있고, 우리는 이를 따라잡느라 고전하고 있습니다.

코드를 한 줄씩 읽는 것을 언제 멈출 수 있을지 생각해보면, 사실 우리는 이미 제대로 리뷰를 하지 못하고 있습니다. 코드 변동성이 861%에 달한다는 것은 더 많은 코드가 생산되고 있다는 뜻입니다. PR 대비 인시던트 비율은 계속 증가하고 있죠. 이는 오늘날 리뷰를 하고 있더라도 효과적이지 않다는 의미이며, 리뷰에 걸리는 중간 시간은 계속 늘어나고 있습니다. 이제 병목 현상은 코딩 자체가 아니라 코딩이 끝난 뒤 모든 것이 멈춰버리는 리뷰 단계로 이동했습니다.

여러분은 리뷰를 기다리는 데 예전보다 4배나 많은 시간을 쓰고 있습니다.

오늘날 전체 변경 사항의 30% 이상은 리뷰 없이 병합되고 있습니다. 이에 대해 조금 생각해보죠.

AI 리뷰에 대해 생각해보세요. 아마 다들 어떤 형태로든 AI 리뷰를 사용하고 계실 겁니다. AI가 코드를 작성하고 AI가 리뷰를 한다면, 왜 굳이 UI에서 수행하는 걸까요?

GitHub을 열어보면 아마 두세 명의 AI 코딩 에이전트가 리뷰를 하고 있을 겁니다. 리뷰 결과가 사용자나 에이전트에게 전달되고 해결되는 과정에서 에이전트와 끊임없이 의견을 주고받고 있죠.

여기서 인간은 어떤 역할을 하고 있나요?

결국 AI가 검토를 다 했으니 대부분의 문제는 찾아냈을 것이라 생각하고 대충 훑어본 뒤 병합하게 됩니다. AI가 검토하고 아무도 읽지 않으면 잘못된 설정을 그대로 반영하게 되죠. 한 걸음 물러서서 생각해 봅시다. 코드 리뷰의 역사는 그리 길지 않습니다. 15~20년 전인 2006년 구글이 내부적으로 '몬트리안(Montrean)'을 도입하면서 코드 리뷰가 공식화되었습니다. 옛날 윈도우 개발 시절을 생각해보세요.

초기 버전들은 사실 리뷰 없이 만들어졌습니다. 하지만 자세히 살펴보면 코드 리뷰는 단순히 코드만 확인하는 것이 아닙니다.

버그를 잡고, 코딩 컨벤션을 이해하며, 보안 문제를 식별하는 것도 당연하지만, 코드 리뷰는 '정렬(alignment)'을 위한 과정이기도 합니다.

이는 제가 몇 달 전 이야기했던 5단계 모델에서 빠졌던 부분이기도 합니다. 코드 리뷰의 큰 부분은 지식 공유, 멘토링, 아키텍처 피드백, 온보딩, 그리고 협업 능력에 있습니다.

만약 여러분이 혼자서 코딩하거나 1인 프로젝트를 진행 중이라면 이 이야기는 해당하지 않습니다. 하지만 팀으로 일하는 대부분의 여러분은 아무도 코드를 보지 않는 완전 자동화된 공장에서 일하는 것이 아니겠죠.

실제로 팀 단위로 협업하고 있다면 정렬을 위한 지식 공유가 필요하며, 그것이 코드 리뷰에서 가장 중요한 측면입니다.

의미적 정확성을 위해서는 더 나은 도구를 만들 수 있지만, 정렬은 반드시 유지되어야 합니다. 정렬에 대해 깊이 파고들어 봅시다. 그게 무슨 뜻일까요? 오늘날 코드 한 줄 한 줄을 읽는 것보다 더 나은 정렬 모델을 생각할 수 있을까요?

아마 대부분 '사양 기반 개발(spec-driven development)'에 대해 들어보셨을 겁니다. 사양 기반 개발이란 사양을 작성하고 모든 세부 사항을 담아 에이전트에 전달하면 에이전트가 코드를 생성하고, 우리는 그것을 검증하는 방식이죠.

그럼 무엇이 문제일까요? 1970년대로 돌아가 보면 이것이 바로 폭포수 모델(waterfall model)이었습니다.

요구사항과 사양을 먼저 정의하고 구현한 뒤 검증하지만, 피드백 루프가 없습니다. 모든 것을 파악하기 전에 사양부터 작성되어 버리는 것이죠. 그렇지 않나요?

그렇기 때문에 오늘날 모든 사람들이 여전히 코딩 세션을 사용하고 싶어 합니다. 클로드 코드, 코드엑스, 커서 등 무엇을 사용하든 상관없이 말이죠. 여러분은 에이전트와 상호작용하기를 원하며, 그 이유는 명세서에 명확하지 않은 부분이 있고 우리는 여전히 그것을 포착해야 하기 때문입니다.

두 번째로, 구현을 하다 보면 더 많은 문제가 발견되는데 명세서를 다시 돌아가서 업데이트하지는 않습니다. 명세 기반 개발을 한다면 이미 끝난 일이라고 생각하기 때문이죠. 일단 명세가 완료되면 코드가 결정론적으로 나올 것이라고 기대합니다. 하지만 아시다시피 LLM은 결정론적이지 않습니다.

LLM은 스스로 결정을 내립니다. 그래서 명세 기반 개발은 훌륭한 방법론이지만, 일상적인 소프트웨어 개발에서는 한계가 있습니다. 하지만 여기서 우리가 가져가야 할 흥미로운 측면들이 있습니다. 가장 중요한 부분은 의도이며, 의도는 명세서에만 존재하는 것이 아닙니다.

의도는 지라 티켓에 담겨 있습니다. 그것이 목표니까요. 우리가 무엇을 하고 싶은지 표현하는 곳이기도 합니다.

그것은 포드에도 담겨 있습니다. 계획과 같은 세부 사항들 말이죠. 하지만 가장 중요한 것은 오늘날 여러분의 프롬프트에 담겨 있다는 점입니다. 바로 이곳에서 실질적인 결정들이 내려지고 있습니다.

여러분은 지라 티켓을 보며 시작하지만, 에이전트와 계속해서 피드백을 주고받게 되며 바로 여기서 모든 사용자 결정이 이루어집니다.

하지만 우리가 오늘날 하는 방식은 변경 사항을 만들고 풀 리퀘스트를 생성한 뒤, 그 과정을 버리는 것입니다.

이것이 우리가 바꿔야 할 것 중 하나입니다. 먼저 의미론적 정확성에 대해 이야기해 봅시다. 여러분이 정렬 부분은 이해하지만 여전히 코드에 버그가 있다고 말할 때, 누가 그것을 검토할 것인가 하는 문제죠. LLM도 이 부분에서는 완벽하지 않으며, AI 에이전트나 리뷰어들도 완벽하지 않을 수 있다는 점은 이미 논의했습니다. 그래서 여기서 저는 'AI 슬롭 레지스트리'라는 개념을 소개합니다. 오늘날 우리가 수동으로 코드를 검토할 때, 저는 모두가 어느 정도는 그렇게 하고 있으리라 생각하는데, 사실 우리는 본질적으로 같은 문제들을 반복해서 식별하고 있을 가능성이 높습니다.

우리가 이런 개념들을 포착하고 코드화하여, 매번 검토 피드백을 하나하나 생성할 필요가 없도록 만들 수 있지 않을까요? 실제로 이런 모든 사항을 자동으로 식별할 수도 있습니다.

이 방식의 장점은 몇 번 반복하면 시간이 지남에 따라 스스로 학습하는 시스템을 구축할 수 있다는 것입니다.

기본적으로 사용 중인 표준 LLM 위에 추가 학습을 진행하여 그 토대 위에 기능을 구축하는 것이라고 생각하면 됩니다.

따라서 AI 슬롭 레지스터는 인간인 여러분이 제공하는 리뷰 경험을 통해 학습하며 더 나은 결과를 만들어낼 수 있습니다.

반복되는 모든 코멘트는 이제 다시 검토할 필요가 없는 가이드라인이 됩니다. 자, 그럼 정렬과 의미론적 정확성, 이 두 가지를 결합해 보겠습니다.

이는 동일한 문제의 양면과 같습니다. 리뷰의 핵심 메커니즘을 이해하려는 것이죠. 정렬과 의미론적 정확성이라는 두 부분으로 나누어 어떻게 단일 루프로 통합할지 고민해야 합니다.

첫 번째 단계는 세션을 통해 사용자 응답을 캡처하는 것이며, 이것이 본질적으로 수락 기준을 형성합니다.

이 수락 기준은 지속적으로 유지 관리하는 AI 슬롭 레지스터와 결합되어 최종적으로 테스트 플랜을 생성합니다. 우리가 구축하는 시스템의 일부인 검증 시스템은 이 테스트 플랜을 가져와 미리보기를 실행하고, 실제로 처음부터 끝까지 정상 작동하는지 확인합니다.

코드가 올바르게 보이더라도 실제로 작동할까요?

이 검증 과정이 흥미로운 부분입니다. 이제 핵심은 이것이 새로운 리뷰 방식이 된다는 점입니다. 코드 라인을 한 줄씩 검토하는 대신, 의도가 무엇이었는지에 대한 증거를 살펴보는 것입니다.

사용자가 정의된 의도에 맞는 기능을 실제로 구현했는지, 그리고 그 동작이 수락 기준에서 요구한 조건을 충족했는지 확인하는 것이죠. 여전히 아키텍처 결정을 내리고 논의가 이루어지지만, 리뷰의 방식은 바뀌는 것입니다.

저희 시스템 구축 방식을 간단히 설명하자면, 세션이 곧 기준이 됩니다. 에이전트와 함께 내리는 모든 결정, 즉 간단한 작업이라도 에이전트가 질문을 위해 멈추고 피드백을 제공받는 과정이 포함됩니다.

우리가 캡처해야 할 결정들이 바로 이것입니다. 이것이 곧 의도이며, 리뷰와 협업을 더 가치 있게 만드는 요소입니다.

이런 방식으로 주니어 엔지니어들이 시간이 지남에 따라 성장하도록 가르칠 수 있으며, 바로 이러한 결정들이 오늘날 소프트웨어 엔지니어를 가치 있게 만듭니다.

이것들을 수용 기준(acceptance criteria)으로 변환합니다. 바로 이 지점에서 LLM을 활용할 수 있습니다. 사용자의 결정 사항들을 포착하여 이를 바탕으로 테스트 계획을 확실하게 수립할 수 있습니다.

테스트 계획을 만드는 과정은 항상 고통스럽다는 것을 알고 있으며, 그렇기에 이 목적을 위해 LLM을 사용할 것을 추천합니다.

결국 기준과 불변량(invariant)이 테스트 계획을 구성하며, 우리는 이 테스트 계획을 포착하여 프리뷰를 실행하고 테스트할 수 있는 검증 시스템을 구축합니다. 따라서 새로운 기능을 만들 때 테스트를 유지 관리할 필요조차 없게 되는 것입니다.

이 방식은 실시간으로 테스트를 생성하며, 테스트 계획의 유지 관리와 생성이 매우 고통스러울 수 있다는 점에서 LLM의 강력함을 활용할 수 있습니다. 여기서 사람이 개입하는 가치는 거버넌스와 검토 과정에 있으며, 코드가 아닌 테스트 계획 자체를 검토하는 데 있습니다.

그렇지 않나요? 테스트 주도 개발(TDD)이 나온 지 20년이 넘었습니다. 이 방식은 어떤 면에서 행동 주도 개발(BDD)과 더 유사하며, 이제 테스트 계획은 기획자나 디자이너 등 모두와 공유할 수 있고 누구나 참여할 수 있는 것이 되었습니다. 왜냐하면 이 모든 것이 이제는 평문(영어)으로 되어 있기 때문입니다.

동시에 우리는 이제 특정 테스트 기준이 충족되었는지 여부를 실제로 검증하는 결정론적(deterministic) 검증 체계를 갖추게 되었습니다.

다음으로 넘어가죠. 시스템이 완벽해야 한다는 것은 아닙니다. 가능한 곳은 결정론적으로 구현하고, 반드시 필요한 곳에는 LLM을 사용해야 합니다. 모든 것이 결정론적일 수는 없으니까요.

모든 시스템을 100% 결정론적인 시스템으로 구축할 수는 없습니다. 바로 그럴 때 LLM을 폴백(fallback)으로 사용하는 것입니다. 예를 들어보죠. 웹 애플리케이션을 변경할 때, 어떤 행동 변화가 있는지 테스트 계획을 생성하게 할 수 있습니다.

새로운 결제 폼을 도입한다고 가정해 봅시다.

그러면 새로운 결제 폼이 생성됩니다. 여기서의 검증은 결제 시스템이 변경되었는지를 확인하는 것입니다.

AI 에이전트가 애플리케이션을 탐색하여 폼을 작성하고 증거로 스크린샷을 캡처한 다음, 해당 스크린샷과 데이터베이스 스냅샷을 대조하여 기준이 충족되었는지 확인할 수 있습니다.

즉, 스크린샷 테스트나 샘플링은 여전히 에이전트가 수행할 수 있지만, 동시에 리뷰어가 살펴보고 이 기능이 실제로 작동한다는 확신을 가질 수 있는 더 견고한 증거를 생성하는 것입니다.

이제 리뷰어들은 변경 사항이 아닌 의도를 검토하게 됩니다. 무엇을 만들려고 했는지, 무엇을 시도했고 무엇을 거부했는지와 같은 의도적인 결정 사항들을 세션에서 추출하여 검토하는 것이죠. 세션에서 정보를 추출하는 것이 핵심이라는 점을 기억하세요.

만약 코드 자체로부터 테스트 계획을 세우려 한다면, 우리가 어제 이야기했던 상황에 다시 직면하게 됩니다. 덱스가 언급했던 것처럼, 테스트 계획을 세우는 것과 동일한 에이전트가 코드를 작성한다면.

문제를 잡아낼 수 있는 제대로 된 테스트 계획을 세울 수 없을 것입니다.

그렇기 때문에 세션 정보를 활용해 테스트 계획을 세우는 것이 중요합니다. 설계 결정 사항들에 대해 논의할 수 있기 때문이죠.

데이터 모델을 어떻게 생성하는지, 서비스들이 서로 어떻게 상호작용하는지 등을 논의하게 됩니다. 즉 한 단계 위로 올라가는 것이죠. 코드 한 줄 한 줄을 리뷰하는 대신 협업에 매우 중요한 아키텍처에 대한 논의를 하게 됩니다.

그리고 검증 과정에서 수집된 모든 증거를 살펴보세요. 여러분 모두에게 숙제를 하나 드립니다. 집에 가서 지난 1,000개의 리뷰 코멘트를 분석해 반복되는 항목들에 대한 AI 슬롭 레지스터(AI Slop Register)를 만들어 보세요.

우리가 코드 리뷰에서 제공하는 수많은 코멘트는 사실 반복되는 것들입니다. 이는 PR이 병합될 때마다 누적되죠. 항목을 레지스터로 만들어 두면, 같은 코멘트를 다시 달 필요가 없습니다.

이곳이 바로 코딩의 모범 사례를 체계화하고 의미적 정확성을 유지할 수 있는 지점입니다. 동시에 리뷰의 협업적 측면도 잃지 않아야 합니다.

이는 J 커브를 따릅니다. 성장은 실재하죠. 초기에는 레지스트리를 만드는 데 시간이 걸리므로 성과를 보려면 투자가 필요합니다. 이 부분에서 여러분들이 저희 제품을 사용해 보시길 권장합니다.

코드 리뷰는 단순히 코드만을 검토하는 것이 아닙니다. 진정한 정렬을 이루는 과정이며, 우리가 더 나은 도구를 구축할 수 있는 지점은 의미적 정확성을 만들고 여러분만의 AI 슬롭 레지스터를 정의하는 것입니다.

오늘 딱 하나만 기억해야 한다면, 코드 리뷰는 단순히 코드 리뷰에 그치지 않는다는 점을 기억하세요.

그것은 정렬을 이루는 과정입니다. 네, 저희는 '베리파이(Verify)'라는 새로운 제품을 시범 운영하고 있습니다. 부디 참여하셔서 초기 디자인 파트너가 되어 주십시오. 저희는 새로운 검증 시스템을 도입하기 위해 여러 기업과 협력하고 있습니다.

이는 정렬 측면뿐만 아니라 AI의 로그 레지스터를 사용하여 의미론적 정확성을 감지하기 위한 도구와 기능을 구축하는 것을 결합한 것입니다.

모두 감사합니다. 참여해 주셔서 감사합니다.

코드 리뷰 문제점 및 해결 방안 소개

발표자 Ankit은 Aviator 공동 창업자로, AI 코드 검증 플랫폼을 개발 중이다.

과거 '코드 리뷰 제거 방법'에 대한 5단계 신뢰 모델 포스팅의 경험을 바탕으로 심층적인 내용을 다룰 예정이다.

코드 리뷰의 현주소와 비효율성

코드의 양은 매일 증가하고 있으며, 라인별 코드 리뷰는 이미 비현실적이다. 861%의 코드 churn과 PR 대비 이슈 증가율은 리뷰의 비효율성을 나타낸다.

리뷰 대기 시간으로 인해 4배의 시간을 더 소모하며, 30% 이상의 변경 사항은 리뷰 없이 병합된다.

AI가 코드를 작성하고 AI가 리뷰하는 상황에서 사람이 UI에서 검토하는 것은 비효율적이며, 결국 AI가 리뷰하면 아무도 읽지 않는 문제가 발생한다.

코드 리뷰는 2006년 Google의 Montrean 출시 이후 정식화되었으나, 그 이전에도 소프트웨어는 개발되었다.

코드 리뷰의 진정한 목적: 정렬(Alignment)

코드 리뷰는 버그 발견, 컨벤션 이해, 보안 이슈 식별 외에도 '정렬(alignment)'이 중요하다.

지식 공유, 멘토십, 아키텍처 피드백, 온보딩, 협업 등 팀 작업에 있어 정렬은 필수적이다.

의미론적 정확성은 도구로 개선 가능하지만, 정렬은 반드시 유지되어야 한다.

스펙 중심 개발의 한계와 의도(Intent)의 중요성

스펙 중심 개발(Spec-driven development)은 스펙 작성 후 에이전트가 코드를 생성하고 검증하는 방식이다.

이는 1970년대 워터폴 모델과 유사하며, 피드백 루프가 없어 스펙에 모든 것을 담기 어렵다.

구현 중 새로운 문제 발견 시 스펙을 업데이트하지 않으며, LLM은 비결정적이어서 스펙대로만 코드가 나오지 않는다.

스펙 중심 개발의 중요한 부분은 '의도(intent)'이며, 이는 Jira 티켓, PODS, 그리고 특히 오늘날에는 프롬프트에 담겨 있다.

현재 우리는 프롬프트를 버리고 풀 리퀘스트를 생성하는 문제를 가지고 있다.

의미론적 정확성 확보: AI Slop Registry

코드 내 버그는 여전히 존재하며, AI 에이전트도 완벽하지 않으므로 'AI Slop Registry' 개념을 도입한다.

반복되는 코드 리뷰 이슈를 코드로 캡처하고 자동 식별하여 반복적인 피드백을 줄인다.

Registry를 통해 시스템이 시간이 지남에 따라 학습하고, LLM 위에 추가 학습을 제공한다.

사람의 리뷰 경험에서 학습하여 더 나은 결과를 생성하며, 반복되는 모든 코멘트는 다시 검토할 필요 없는 가드레일이 된다.

정렬(Alignment)과 의미론적 정확성(Semantic Accuracy)의 통합

코드 리뷰의 핵심 메커니즘을 정렬과 의미론적 정확성으로 나누어 하나의 루프로 통합해야 한다.

사용자 세션 응답을 캡처하여 '승인 기준(Acceptance Criteria)'을 형성한다.

이 승인 기준과 AI Slop Registry를 결합하여 테스트 계획을 생성하고, 검증 시스템을 통해 코드가 실제로 작동하는지 확인한다.

이제 코드 라인별 리뷰가 아닌, 의도가 충족되었는지, 행동이 요구사항을 만족하는지 증거를 기반으로 리뷰한다.

세션 데이터 기반의 테스트 계획 및 검증

에이전트와의 상호작용 세션에서 발생하는 사용자 결정(피드백, 질문 등)을 캡처하여 의도를 파악한다.

이러한 결정은 리뷰와 협업의 가치를 높이고, 주니어 엔지니어 교육 및 소프트웨어 엔지니어의 가치를 높이는 데 중요하다.

캡처된 사용자 결정을 LLM을 활용하여 승인 기준으로 변환하고, 이를 기반으로 테스트 계획을 생성한다.

승인 기준 + 불변성을 통해 테스트 계획을 만들고, 실시간으로 테스트를 생성하여 검증한다.

테스트 계획 유지보수 및 생성은 LLM을 활용하고, 인간은 거버넌스와 테스트 계획 리뷰에 집중한다.

이 방식은 행동 주도 개발(BDD)에 가까우며, 테스트 계획이 비전문가와도 공유 가능해 협업을 증진한다.

동시에 특정 테스트 기준 충족 여부를 결정론적으로 검증한다.

검증 시스템의 유연성과 리뷰 대상의 변화

시스템은 완벽할 필요는 없으며, 가능한 부분은 결정론적으로, 필요할 때는 LLM을 활용한다.

예시: 웹 애플리케이션 변경 시 AI 에이전트가 테스트 계획을 만들고, 애플리케이션을 탐색하여 스크린샷과 DB 스냅샷을 통해 기준 충족 여부를 확인한다.

리뷰어는 이제 코드 차이(diff)가 아닌 '의도'와 그 결정, 그리고 생성된 증거를 검토한다.

핵심은 세션에서 정보를 캡처하는 것이며, 코드에서 빌드하면 같은 문제가 반복된다.

리뷰 대상이 데이터 모델, 서비스 상호작용 등 아키텍처 수준으로 상향되어 협업의 질이 향상된다.

AI Slop Registry 구축 권장 사항 및 결론

마지막 1,000개의 리뷰 코멘트를 분석하여 반복 가능한 부분에 대한 AI Slop Registry를 구축할 것을 권장한다.

Registry에 캡처될 때마다 해당 코멘트는 다시 작성할 필요가 없으며, 이는 모범 사례를 코드화하고 의미론적 정확성을 유지하면서 협업을 잃지 않는 방법이다.

[한글자막] 코드 리뷰를 완전히 없애는 방법: diff 대신 의도를 검증하세요

스크립트