서론

저 자신도 개인 개발이나 업무에서 AI를 사용한 개발을 수행하고 있습니다. 그 경험을 바탕으로 "AI가 자율적으로 움직이게(자주, 自走) 하기 위해 무엇이 필요한가"를 생각할 기회가 있었기에, 기사로 정리해 보았습니다.

여기서 다시 한번 느낀 점은, AI가 자율적으로 개발할 수 있는지 여부는 도구의 사용법 이상으로 "코드베이스의 설계 (Codebase Design)"의 영향이 크다는 것입니다. 중요한 것은 "좋은 코드를 남기고, 나쁜 코드를 유입시키지 않는 것"이라고 생각했습니다.

AI에게 맡겨도 의도대로 코드를 내놓지 못하거나, AI 주도 개발 (AI-Driven Development)을 진행하면서 코드 품질에 과제를 느끼고 계신 분들은 꼭 읽어보시기 바랍니다.

애초에 "AI가 자율적으로 개발할 수 있다"는 것은?

사전에 "AI가 자율적으로 개발할 수 있다"가 어떤 의미인지 정리하겠습니다. 제 관점에서는 다음 두 가지가 갖춰진 상태를 의미합니다.

• AI가 작성한 코드에 대해 세세한 지적이 거의 필요하지 않다
• 자세히 지시하지 않아도 주변 코드를 읽어 들이며 의도를 파악한다

즉, 기존 설계에 따른 코드가 적은 지시만으로도 자연스럽게 나오는 상태입니다.

반대로 말하면, 세세하게 지시하지 않으면 의도대로 코드가 나오지 않거나, 나온 코드에 매번 똑같은 지적을 하고 있다면, 이는 AI 측이 아니라 환경 측에 개선의 여지가 있다고 생각합니다.

AI를 자율적으로 움직이게 하는 팁 (Tips)

먼저, 일상적인 개발에서 AI를 자율적으로 움직이게 하기 위해 실천하고 있는 세세한 Tips를 소개합니다.

Plan을 철저하게 만들기

구현에 들어가기 전의 Plan (구현 계획)의 질이 그대로 아웃풋의 질로 직결됩니다. 제가 의식하고 있는 것은 여러 안을 내놓게 하여 장점과 단점을 비교하는 것입니다. 일부러 마이너한 아키텍처 (Architecture)도 안(案)에 포함시키면 시야가 넓어지고, "이 방향성은 아니다"라는 판단도 내리기 쉬워집니다.

실제로 여러 안을 내놓게 하여 비교 검토했을 때의 문서

또한 Plan을 만드는 데 있어 제가 특히 의식하고 있는 요령이 두 가지 있습니다.

• 구현 전에 데이터의 흐름이나 클래스 다이어그램 (Class Diagram)을 AI가 출력하게 하여, 인식의 차이가 없는지 확인한다.
• 부족한 정보를 AI 측에서 질문하도록 한다.

이를 통해 AI와의 인식을 일치시키고, 지시 누락을 줄인 상태에서 태스크 (Task)를 맡길 수 있습니다.

AI 스스로 동작 확인을 하게 하기

Chrome DevTools MCP나 Playwright MCP를 사용하면, AI가 실제로 브라우저를 조작하여 화면의 동작 확인까지 수행할 수 있게 됩니다.

Chrome DevTools MCP로, AI가 실제로 로그인 플로우 (Login Flow)를 조작하여 동작 확인을 하고 있는 모습 (4배속)

이를 통해 최소한의 정상계(Happy Path)는 AI 스스로 테스트해 줍니다. 인증 플로우 등 자주 사용하는 절차는 Skill로 묶어 두면 불필요한 시행착오 (Try Error)를 줄일 수 있어 효율적입니다. "최소한 동작한다"는 것이 담보되어, 사람은 리뷰 (Review)에 집중할 수 있게 됩니다.

리뷰 지적 사항은 메모하게 하기

AI의 출력물에 지적을 할 때, 먼저 "왜 안 됐는가?"를 AI에게 대답하게 합니다. 원인을 설명하게 함으로써 다음에 어떻게 수정해야 하는지까지 제안하게 합니다.

그 후에 제안 내용이나 애초의 원인을 CLAUDE.md나 Skill에 추가하게 합니다. 이를 반복함으로써 같은 실수를 하지 않게 되고, 조금씩 의도대로 움직여 주게 됩니다.

같은 종류의 지적이 늘어날 때는 그 관점만 따로 떼어내어 리뷰 전용 Agent를 만드는 것도 유효합니다. 놓치는 부분이 줄어들고 리뷰의 질도 안정됩니다.

정형 작업은 Skill화 하기

AI는 Skill 안에서 Bash나 Python 스크립트 (Script)를 실행할 수 있습니다. 따라서 마이그레이션 파일 (Migration File) 생성 등 "명령어 실행" 작업도 Skill화 하여 맡길 수 있습니다. 정형 작업이야말로 AI에게 맡길 기회입니다.

마이그레이션의 생성·적용·상태 확인을 Skill 내의 스크립트로 묶은 예

체크용 명령어 나 정적 체크 (Static Check)를 Skill에組み込んで 두면, 구현 후의 확인까지 AI에게 맡길 수 있습니다.

또한 마이그레이션 파일 생성 누락 등 "기계적으로 검지할 수 있는 실수"는 CI에서도 방지하도록 하고 있습니다. AI에게 매번 주의를 주는 것보다 시스템으로 방지하는 것이 확실합니다.

AI가 자율적으로 개발할 수 있는 환경을 만들려면?

여기서부터는 왜 코드의 질이 중요한지, 그리고 어떻게 소스 코드를 정돈해 나갈 것인지에 대해 이야기하겠습니다.

왜 기존 구현의 코드 질이 중요한가?

AI는 기존 코드를 보고 새로운 코드를 만듭니다. 기존 구현을 본보기로 삼아 수평 전개해 나갑니다.

그렇기 때문에, 좋든 나쁘든 기존 구현의 설계를 답습합니다. 좋은 설계라면 그것이 확산될 것이고, 나쁜 설계라면 그것이 증식해 나갈 것입니다. '기존 것을 답습한다'는 현상 자체는 동일하지만, 원래 코드의 질에 따라 결과는 정반대가 됩니다.

여기서 중요한 것은, "규모가 작은 단계에서 얼마나 코드베이스를 정돈할 수 있는가"라고 생각합니다. 작은 앱 단계에서는 수정할 곳이 한정되어 있어 설계 문제가 현저히 드러나지 않습니다. 하지만 스케일 업(Scale-up)하려고 하는 순간, 버그가 대량으로 발생합니다.

「동작하는 코드」와 「좋은 코드」는 다르다

여기서부터 제 실패담을 조금 말씀드리겠습니다.

개인 개발에서 구현을 AI에게 통째로 맡겼을 때, 미세한 버그가 대량으로 발생했습니다.

동작은 하지만 깨지기 쉬운 코드가 차례차례 생겨나는 느낌입니다. "〇〇의 버그를 고쳐줘"라고 전달하면 고쳐지기는 합니다. 하지만 그것이 올바른 설계로 고쳐지는 것은 아닙니다. 억지로 동작시키기 위한 패치(Patch)가 적용되었을 뿐이기에, 수정할 때마다 또 다른 버그가 생겨납니다. 깨달았을 때는 정체 모를 IF 분기가 대량으로 증식해 있었습니다.

패치를 덧댄 코드는 설계로서 올바른 의미를 갖기 어렵고, 코드의 질은 점점 저하됩니다. 더욱 까다로운 점은, AI도 그 코드를 읽고 똑같은 방식을 답습한다는 것입니다. 나쁜 패턴이 기존 코드를 통해 계속해서 재생산됩니다.

AI가 설계 의도를 읽어낼 수 있는, 일관된 코드를 남기기

그렇다면 어떤 코드를 남겨야 할까요? 저는 "AI가 설계 의도를 읽어낼 수 있는, 일관된 코드"라고 생각합니다.

설계 방침이 없으면 비즈니스 로직(Business Logic)이 곳곳에 흩어집니다. "무엇을 공통화할 것인가", "공통 처리를 어디에 둘 것인가"를 명시하지 않으면, 동일한 로직이 여기저기에 작성됩니다. AI는 기존 코드를 답습하므로, 흩어진 패턴이 순식간에 확산됩니다.

반대로 일관된 패턴으로 작성되어 있고, "왜 이런 설계인가"를 읽어낼 수 있는 코드라면, AI는 적은 지시만으로도 그에 부합하는 코드를 내놓습니다. 반대로 장소마다 작성 방식이 제각각이면, AI는 어떤 것을 답습해야 할지 망설이게 됩니다.

저 자신도 설계가 오래되었다고 느껴지면 리팩터링(Refactoring)이나 리아키텍처(Re-architect)를 적극적으로 수행하려고 노력합니다. 오래된 설계를 방치하지 않고, AI가 올바르게 설계를 읽어낼 수 있는 상태를 유지하는 것도 자율 주행(Self-driving) 가능한 환경을 만드는 일의 일부라고 느끼고 있습니다.

버그가 생기기 어려운 설계·구현을 위한 리뷰 관점

이러한 전제를 바탕으로, AI가 작성한 코드를 리뷰할 때는 버그가 생기기 어려운 설계·구현이 되어 있는지를 다음의 관점에서 확인하려 합니다.

• 향후 전망을 고려한 코드인가?: 확장성(Scalability)을 내다본 설계가 되어 있는지 체크한다.
• 비즈니스 로직이 중복되지 않았는가?: 동일한 책임을 가진 로직이 흩어지면 변경 시 퇴보(Regression)가 발생하므로 이를 방지한다.
• 기존 설계에 부합하는 형태인가?: 설계에서 벗어난 코드가 들어오면 AI가 그것까지 답습해 버린다.

이러한 관점을 의식하면 코드 품질을 유지하기 쉽다고 생각합니다. 동일한 관점으로 AI에게 리뷰를 시키는 것도 유효합니다.

AI를 자율적으로 움직이게 하기 위해 의식해야 할 점

마지막으로, AI 시대의 "마음가짐"에 대해 조금만 말씀드리겠습니다.

그 생산성 향상은 올바른 방향인가요?

여기서 질문을 하나 던져보겠습니다.

"AI를 도입하여 팀의 개발 속도와 생산성이 올라갔습니까?"

아마 PR(Pull Request)의 수나 릴리스 빈도가 늘어난 팀은 많을 것입니다. 하지만 한 걸음 더 들어가 고민해 보고 싶은 것은, **"그 생산성이 올바른 방향을 향하고 있는가?"**라는 질문입니다.

PR의 수만 쫓는 함정

PR의 수는 늘어났지만, 그중에 "본래 불필요했던 PR"이 포함되어 있지는 않습니까?

설계가 허술한 코드는 부채(Debt)가 되기 쉽고, 설계 단계에서 없앨 수 있었을 에지 케이스(Edge Case)가 남아 버그가 빈번하게 발생합니다. 그러면 기존에는 필요 없었을 버그 대응 때문에 다른 멤버의 시간도 빼앗기게 되어, 팀 전체의 생산성이 떨어집니다.

질 낮은 코드의 부담은 QA에 집중되고, 팀 전체가 피로해집니다.

또한 버그 대응을 할 때마다 퇴보 방지를 위한 패치 성격의 수정이 겹치면서, 가독성과 설계 의도가 상실되어 코드의 품질은 더욱 떨어집니다. 그 후 AI가 그 코드를 답습하며 악순환이 가속화됩니다.

이 순환에 빠지면 "코드를 빠르고 많이 쓸 수 있다"는 것이 곧바로 팀의 성과로 이어지지 않게 됩니다.

개인적으로는 "기존의 가치 기준을 전환할" 필요가 있다고 생각하며, "코드를 빠르고 많이 쓸 수 있다"는 것만으로는 통하지 않는 시대가 되고 있다고 느낍니다.

「일단 돌아가게 만들기」에서 끝내지 않기

그렇다고 해서 모든 것을 사람이 세세하게 확인하는 것은 현실적이지 않습니다. 제가 의식하고 있는 것은 완급 조절(メリハリ)입니다.

리뷰를 할 때는 단순히 "돌아간다"에서 끝내지 않고, "최적의 설계인가?"까지 확인하려고 노력합니다. 사소한 설계의 미흡함이 AI의 수평적 전개(Horizontal expansion)를 통해 순식간에 확산되는 시대이기 때문입니다.

따라서 근본적인 설계는 어느 정도까지 사람이 잡아둡니다. 경계(Boundary), 책임(Responsibility), 확장(Extension)의 축만 정해두면, AI는 그것을 읽어냅니다.

반면, 표시 로직(Display logic)과 같이 영향이 국소적인 부분은 세부 사항까지 AI에게 맡기고 있습니다. 영향이 해당 화면이나 해당 컴포넌트에 머문다면, 생성(Generation)에 맡겨도 문제없다고 생각합니다.

지금보다 더욱, 설계의 질이 중요해진다

코드 자체는 즉시 만들 수 있는 시대가 되었습니다. 그렇기에 더욱, AI에게 코드를 쓰게 하기 전에 "그 설계는 어떠한가? 더 좋은 설계는 없는가?"라고 설계 그 자체를 다시 질문하는 데 시간을 쓰는 가치가 높아지고 있다고 생각합니다.

눈앞의 코드 생성과 생산성에 현혹되거나 조급해지기 쉽지만, 때로는 그 흐름에 휩쓸리지 않는 것도 중요하다고 생각합니다. (물론 우선순위는 수시로 변하겠지만요)

"만드는" 것 자체는 AI도 할 수 있기 때문에, 차이가 벌어지는 지점은 "무엇을, 어떻게 설계할 것인가"에 대한 판단력이라고 생각합니다.

AI 시대야말로 설계 능력이 최대의 무기가 될 것이라고 느낍니다.

마치며

기존 구현의 설계가 중요: AI는 현재의 코드를 수평적으로 전개한다. 좋은 설계를 남기고, 나쁜 패턴을 유입시키지 말 것 -
시스템으로 자율 주행시키기: 계획(Plan), 동작 확인, 리뷰의 축적, 스킬화(Skill化)를 통해 AI에게 맡길 수 있는 범위를 넓힐 것 -
생산성의 방향을 바라보기: 생성 속도에만 휩쓸리지 말고, 설계를 다시 질문하는 시간을 아끼지 말 것

이 기사가 AI와의 개발 방식을 재검토하는 계기가 된다면 기쁘겠습니다.

X 팔로우해주시면 감사하겠습니다

X에서도 정보를 발신하고 있으니, 팔로우해주시면 큰 힘이 됩니다!

Discussion