AI에게 구현을 너무 많이 맡겼던 고등학생이, 쓴맛을 보고 배운 것

최근 「AI를 사용하면 코드를 작성할 수 있다」라는 이야기를 자주 듣는다. 실제로 그렇고, 나 자신도 그 은혜를 입어왔다.

다만, AI가 작성한 코드를 자신의 코드로 취급해도 되는가라는 질문이 계속 머릿속을 맴돌았다. 이 기사에서는 자작 OSS (Open Source Software) 개발을 통해 AI와의 관계를 재검토한 이야기를 쓰고자 한다. 비슷한 고민을 하고 있는 사람들에게 참고가 된다면 기쁘겠다.

자작 OSS인 NanaSQLite를 개발하고 있었을 때, AI가 제안한 로직에 명백한 거짓이나 결함이 포함되어 있다는 것을 깨달았다. 이것 자체는 즉시 지적해서 고칠 수 있다. 문제는 그 이후였다.

개발이 진행됨에 따라 다음과 같은 일이 늘어났다.

• 로직은 맞는데, 구현한 코드에서 버그가 발생한다
• 정상적으로 작동하고 있는 것 같은데, 퍼포먼스 (Performance)가 떨어진다

이렇게 되면, 자신이 이해하지 못한 방대한 코드의 차분 (Diff)을 추적하면서, 그 안에서 버그를 찾아내야 하는 매우 비효율적인 작업을 강요받게 된다.

문제는 어렴풋이 느끼고 있었다. 하지만 「귀찮다」는 이유로 미뤄두고 있었다. 이번 개발에서 쓴맛을 보고, 드디어 정면으로 마주할 마음이 생겼다.

자신의 개발 플로우 (Flow)를 되돌아보면, AI에 대한 의존은 다음과 같은 상태였다.

공정	당시의 실태
설계・기술 선정	AI와 상담하며 결정
...

등교에 왕복 3시간이 걸리는 데다, 동아리 활동이 있으면 귀가 시간이 22시를 넘는 일도 있다. 「설계만 생각하고 나머지는 AI에게 맡긴다」는 스타일은 당시의 나에게 합리적인 선택으로 보였다.

하지만 결과적으로, 자신의 리포지토리 (Repository)에 자신이 파악하지 못한 코드가 쌓여가고 있었다. 이는 개발자로서, OSS의 제작자로서 솔직히 위험한 상태라는 것을 깨달았다.

문제가 「모든 공정을 AI에게 맡기는 것」에 있었다면, 해결책은 공정마다 AI의 역할을 명확히 하는 것이다.

기술 선정이나 설계의 초기 단계에서의 AI 활용은 계속해서 유효하다.

단, 출력물은 반드시 스스로 확인한다. AI가 거짓말을 하고 있지는 않은지, 자신의 의도와 맞는지 검증할 책임은 자신에게 있다.

구현을 통째로 AI에게 넘기는 것을 그만두었다. 대신 다음과 같은 플로우 (Flow)로 바꾸었다.

• 태스크 (Task)를 세밀하게 나눈다
• 간단한 부분은 AI에게 맡긴다
• 의도를 알 수 없는 부분은 그때마다 AI와 논의하고, 필요에 따라 스스로 조사한다
  최종적인 확인과 판단은 반드시 스스로 수행한다

테스트 (Test)는 「자신의 의도한 설계대로 되어 있는가」와 「버그가 없는가」를 보증하는 최후의 보루다. 이곳을 AI에게 맡기는 것은 그 보증을 포기하는 것과 같다. 테스트야말로 스스로 작성한다.

방침을 전환한 후, 하나의 태스크 (Task)에 걸리는 시간은 확실히 늘어났다. 하지만 결과적으로 개발 효율은 올라갔다. 이유는 단순하다. 자신이 이해하고 있는 코드가 압도적으로 늘어났기 때문이다.

• 버그가 발생했을 때의 디버깅 (Debugging)이 빠르다
• 사양 변경에 대한 대응 시 망설이지 않는다
• 코드를 다시 읽었을 때, 스스로 판단할 수 있다

한편으로, 과거에 AI에게 작성하게 했던 코드에는 지금도 파악하지 못하는 부분이 많아, 버그가 생길 때마다 해독을 강요당하고 있다. 이는 자업자득이라고 생각한다.

눈앞의 효율을 취할 것인가, 미래의 유지보수성을 내다보고 지금 투자할 것인가.

이것은 꽤 어려운 질문이다. 하물며 공부나 동아리 활동과 개발을 병행하는 학생에게는 더욱 고민스러운 일이다.

다만 이번 반성을 통해 다시금 실감한 것은, 스스로 코드를 이해하고 판단하는 것의 중요성과 그 과정의 즐거움이다. AI는 강력한 도구이지만, 주도권은 자신이 가져야 한다.

「AI가 작성했다」가 아니라 「내가 만들었다」라고 당당하게 말할 수 있는 OSS를 앞으로도 계속 만들어 나가고 싶다.