AI 코딩, 세 번 방식을 바꾸고 나서야 보인 개발자의 일

2024년 11월 말, 처음 AI 대화창을 열었습니다. 특별한 기대는 없었습니다. 그냥 써보자는 거였습니다.

1999년부터 개발을 해왔으니 새로운 도구가 나오는 풍경은 익숙했습니다. 언어가 바뀌고, 프레임워크가 바뀌고, 예전에는 직접 만들던 기능이 라이브러리 하나로 해결되는 일도 많이 봤습니다. 이번에도 그런 변화 중 하나일 거라고 생각했습니다.

그런데 이번에는 제가 일하는 방식이 연달아 바뀌었습니다. 하나에 익숙해졌다고 느낄 때쯤, 바로 그 일을 도구가 대신하기 시작했습니다.

처음에는 코드를 복사했습니다. 그다음에는 AI에게 파일을 맡겼습니다. 지금은 AI가 작업을 이어갈 수 있도록 기준과 환경을 만드는 데 시간을 씁니다.

그 사이에 공부가 허탈해진 순간도 있었고, 이제 정말 개발자가 필요 없어지는 것 아닌가 싶은 순간도 있었습니다. 반대로 코드를 거의 직접 치지 않았는데도, 하루 종일 개발의 가장 어려운 부분을 붙들고 있었다고 느낀 날도 있었습니다.

이상한 시기를 지나고 있습니다.

배운 걸 도구가 가져갔습니다

처음에는 대화창에 “이 코드 짜줘”라고 입력했습니다. 답이 나오면 복사해서 에디터에 붙이고, 실행하고, 오류가 나면 다시 대화창으로 가져갔습니다. 코드와 에러 메시지를 들고 두 창 사이를 오가는 일이 꽤 많았습니다.

그러다 프롬프트를 잘 써야 한다는 얘기를 들었습니다. 실제로 차이가 있었습니다. 무엇을 만들고 싶은지 대충 말하면 결과도 대충 나왔습니다. 기존 코드와 조건을 설명하고, 원하는 출력 형태까지 정해주면 훨씬 쓸 만했습니다.

그래서 공부했습니다. 역할을 부여하고, 예시를 주고, 작업 순서를 나누는 데 공을 들였습니다. 질문을 잘 만드는 것도 기술이라는 생각이 들었습니다.

그런데 파일을 직접 읽고 수정하고 실행하는 코딩 에이전트를 쓰면서, 제가 하던 일 중 상당 부분이 사라졌습니다. 오류를 복사해 올 필요가 없었습니다. AI가 실행 결과를 읽고 다음 수정을 했습니다. 제가 직접 지시문을 정교하게 쓰는 대신, 먼저 요구사항을 정리하게 하고 작업 계획까지 작성하게 할 수도 있었습니다.

좀 허탈했습니다.

방금 익힌 방법을 이제는 도구가 대신해주고 있었습니다. 저는 겨우 손에 익었는데, 그걸 익힐 필요가 없는 사람이 옆에서 바로 다음 단계로 들어오는 느낌이었습니다.

다만 시간이 지나고 보니, 없어진 건 그때 하던 작업 방식이었습니다. 그 과정에서 생긴 감각까지 사라지지는 않았습니다.

어떤 설명을 빼먹으면 결과가 어긋나는지, 너무 큰 일을 한 번에 맡기면 어디서 흐려지는지, “완료했다”는 말을 그대로 믿으면 왜 곤란한지. 복붙하면서 겪은 실패가 이후에도 계속 쓰였습니다. 질문을 다듬던 감각은 작업을 나누는 데 쓰였고, 오류를 가져다 붙이던 경험은 검증 조건을 만드는 데 쓰였습니다.

도구 사용법의 수명은 짧았지만, 실패를 이해한 경험은 생각보다 오래 남았습니다.

빨리 만들어지는 것과 끝까지 돌아가는 것 사이

AI로 개발하면 초반이 정말 빠릅니다. 화면이 뜨고, 버튼이 동작하고, 데이터가 오갑니다. 예전 같으면 한참 걸릴 일이 눈앞에서 형태를 갖춥니다. 이걸 직접 보면 “앞으로 개발자가 얼마나 필요할까”라는 생각을 안 하기가 어렵습니다.

저도 그랬습니다.

그런데 복잡한 작업으로 들어가니 다른 장면이 나왔습니다. 한 곳을 고치면 다른 곳이 깨지고, 그걸 수정하면 처음의 문제가 돌아왔습니다. 각각의 수정은 설명만 들으면 타당했습니다. 문제는 그 수정들이 한 시스템 안에서 서로 맞지 않는다는 데 있었습니다.

여러 기술이 얽힌 데스크톱 앱을 리팩토링할 때 특히 그랬습니다. 화면이 기억하는 상태, 중간 프로세스가 들고 있는 값, 내부 코어가 판단하는 값이 조금씩 어긋났습니다. 어디가 원본이고 어디가 복사본인지부터 분명해야 했는데, 그 기준을 충분히 잡지 못한 채 각 부분을 개선하고 있었습니다.

AI의 수정안을 따라갈수록 전체 그림을 놓쳤습니다. 솔직히 말하면, 저부터 그 구조를 한 장의 그림으로 설명할 수 없었습니다. 그러니 AI에게 줄 일관된 기준도 만들지 못했습니다.

그때 느낀 건 “AI가 아직 멍청하구나”로 끝낼 문제가 아니라는 점이었습니다. 제가 설명하지 못한 경계와 전제를, AI가 알아서 정확히 채워줄 거라고 기대하고 있었습니다.

모델의 능력 때문에 실패하는 일도 있습니다. 도구가 불편해서 실패할 때도 있습니다. 다만 제 작업에서는 그보다 먼저 확인해야 할 빈칸이 있었습니다. 우리가 무엇을 지키면서 고쳐야 하는지, 그 기준이 분명한지부터 돌아봐야 했습니다.

우리 회사처럼 만들어달라는 말의 빈칸

이건 코드 구조에만 있는 문제가 아닙니다.

쇼핑몰을 만들어달라고 하면 상품 목록, 장바구니, 결제, 배송 같은 기능을 떠올릴 수 있습니다. 그런데 “우리 회사에서 쓰는 쇼핑몰을 만들어달라”고 하면 얘기가 달라집니다.

가령 어떤 회사에서는 특정 상품을 출고 전에 반드시 사람이 확인해야 한다고 해보겠습니다. 겉으로 보면 불필요한 승인 절차입니다. 자동화하면 빨라질 것 같습니다. 하지만 예전에 잘못 출고된 물건 때문에 큰 손실이 났고, 공급업체의 데이터도 아직 믿기 어렵다면 그 절차에는 이유가 있습니다.

결제 실패도 마찬가지입니다. 실패 메시지를 받았다고 곧바로 다시 결제하면 될까요? 실제 승인은 끝났는데 응답만 늦게 도착한 상황이라면, 무턱대고 재시도했다가 중복 결제를 만들 수 있습니다. 화면에 실패를 표시하는 것과 실제 거래가 실패했는지는 구분해야 합니다.

이런 규칙은 기능 이름만으로 전달되지 않습니다. 정책 문서에 있을 수도 있고, 코드에 흩어져 있을 수도 있고, 담당자만 알고 있을 수도 있습니다. 오래된 문서와 현재 운영 방식이 다를 수도 있습니다.

AI도 자료를 읽고 이런 맥락을 파악할 수 있습니다. 그래서 “AI는 도메인을 절대 모른다”는 식으로 말하고 싶지는 않습니다. 다만 제공하지 않은 사정까지 처음부터 알고 있다고 기대할 수는 없습니다. 자료가 서로 충돌할 때 무엇을 현재 기준으로 삼을지도 결정해야 합니다.

개발자는 여기서 관계자에게 묻고, 예외를 확인하고, 서로 다른 요구를 조율합니다. 왜 이 규칙이 있는지 이해한 뒤, 코드와 테스트로 표현할 수 있는 조건으로 바꿉니다.

예전에도 개발의 일부였던 일입니다. 코드가 빨리 만들어지니까 이제 그 앞에 있던 일이 더 선명하게 보입니다.

문서를 만들었는데도 안 됐습니다

저도 처음에는 문서가 있으면 해결될 줄 알았습니다. 설계를 적어두고 AI에게 읽으라고 하면, 다음 작업에서도 같은 기준을 따를 거라고 생각했습니다.

그런데 문서를 만들었다는 사실만으로는 부족했습니다. 어떤 문서가 최신인지 모호했고, 결정한 이유가 빠져 있었고, 코드가 바뀌어도 문서는 그대로 남았습니다. 기준이라고 써놓은 것이 실제 작업에서는 참고 자료 하나에 불과했습니다.

그래서 문서를 쓰는 방식보다 운영하는 방식을 바꾸기 시작했습니다. 왜 이 구조를 선택했는지, 어떤 대안을 검토하고 버렸는지 남겼습니다. 규칙을 어겼을 때 생기는 문제도 사례로 적었습니다. AI가 같은 실수를 반복하면 그때마다 말로 고치는 데서 끝내지 않고, 다음 작업에서도 참고할 수 있는 지침과 검사로 옮겼습니다.

개발에서는 이런 공통 기준을 SSOT라고 부릅니다. 말은 딱딱하지만 제게는 “서로 다른 답이 나왔을 때 어디를 보고 결정할 것인가”에 가까웠습니다. 문서 하나에 모든 걸 몰아넣는다는 뜻은 아닙니다. 적어도 어떤 기준이 유효한지, 무엇이 바뀌면 어디를 함께 고쳐야 하는지는 알아야 했습니다.

그다음에는 AI가 일하는 환경을 손봤습니다. 필요한 자료를 언제 읽게 할지, 진행 상태는 어디에 남길지, 무엇을 통과해야 완료로 볼지, 실패하면 어디서 다시 시작할지.

이런 실행 환경을 설계하는 일을 하네스 엔지니어링이라고 부릅니다. 제 경험에서는 거창한 에이전트 조직도를 만드는 것보다, 완료했다고 말하기 전에 실제 동작을 확인하게 하는 장치 하나가 더 절실했습니다.

역할을 나누고 여러 에이전트를 함께 쓰는 일도 해봤습니다. 하지만 담당 이름을 붙인다고 협업이 저절로 되지는 않았습니다. 각자 그럴듯한 결과를 가져왔는데 서로 맞지 않으면, 결국 연결하는 사람이 다시 일을 해야 했습니다. 어떤 정보를 주고받고 무엇을 같은 기준으로 볼지부터 정해야 했습니다.

아, 그리고 장치를 많이 붙이는 것도 답은 아니었습니다. 작은 수정마다 무거운 검사를 돌리고, 간단한 일도 여러 단계로 나누면 오히려 느려졌습니다. 예전에 필요했던 절차가 지금도 필요한지 돌아보게 됐습니다.

중복 결제를 막아야 한다는 조건은 지켜야 합니다. 하지만 그걸 확인하려고 매번 모든 검사를 돌릴지는 바꿀 수 있습니다. 지켜야 할 규칙과 그 규칙을 지키는 방법을 구분하는 일까지 제 몫이 됐습니다.

그렇다고 개발자의 자리가 보장되는 건 아닙니다

여기까지 말하면 “그러니까 개발자는 안 없어진다는 거죠?”라는 답을 기대하기 쉽습니다.

저는 그 말로 안심시키고 싶지는 않습니다.

구현에 드는 시간이 줄면 같은 일을 더 적은 인원으로 할 가능성도 생깁니다. 판단할 사람이 필요하다는 사실이 지금의 채용 규모와 역할을 그대로 보장해주지는 않습니다. 오래 개발했다는 이유만으로 안전하다고 생각하지도 않습니다.

다만 제 경험에서 분명해진 변화는 있습니다. 직접 작성한 코드가 줄어드는 동안, 제가 이해하고 확인해야 하는 범위는 오히려 넓어졌습니다.

AI가 캐시를 넣어서 빨라졌다고 하면, 값이 언제 만료되는지 봐야 했습니다. 다른 사용자의 정보가 섞일 가능성은 없는지, 원본 데이터가 바뀌면 어떻게 되는지 확인해야 했습니다. 결과가 깔끔해 보인다는 이유로 통과시키면 그 질문들은 사라지는 게 아니라 운영으로 넘어갔습니다.

그래서 제가 말하는 책임은 마지막에 승인 버튼을 누르는 일이 아닙니다. 왜 이 결과를 받아들일 수 있는지 설명하고, 위험하면 멈추고, 잘못됐을 때 고칠 수 있는 상태에 가깝습니다. 조직에서는 그에 맞는 권한과 지원도 있어야 합니다. 개인에게 이름만 올리게 한다고 생기는 능력은 아닙니다.

AI에게 맡기는 일이 커질수록, 어디까지 제가 이해하고 감당할 수 있는지도 같이 물어야 했습니다.

그런데 여기에는 아직 답하기 어려운 문제가 남습니다. 제 판단력 상당 부분은 직접 구현하다가 틀리고, 고치고, 다시 실패하면서 생겼습니다. 이제 그 구현을 AI가 많이 맡는다면, 앞으로 개발을 시작하는 사람은 그 감각을 어디서 기를 수 있을까요?

“설계를 잘하면 된다”는 말은 너무 쉽습니다. 무엇이 위험한지 아직 겪어보지 않은 사람에게 설계부터 잘하라고 할 수는 없습니다.

그래서 요즘은 AI가 틀린 순간을 그냥 지워버리지 않으려고 합니다. 무엇을 빠뜨렸는지, 저는 왜 처음에 맞다고 생각했는지, 어떤 사례를 넣었더니 문제가 드러났는지 남깁니다. 코드를 전부 직접 작성하지 않더라도, 실패를 이해하는 과정까지 건너뛰지는 않으려는 것입니다.

이게 충분한 답인지는 아직 모르겠습니다. 그래도 결과만 받아 쓰고 넘어가는 것보다는 제 안에 남는 게 있습니다.

처음 AI를 쓸 때보다 새 도구가 나오는 간격은 훨씬 짧게 느껴집니다. 익숙해질 만하면 다른 방식이 나오고, 공들여 만든 절차가 다음에는 불필요해집니다. 저 역시 계속 바꾸는 중입니다.

그래도 처음 대화창에서 코드를 복사하던 시간이 헛수고였다고 생각하지는 않습니다. 그때 겪은 실패가 다음 도구를 판단하는 기준이 됐습니다. 지금 만드는 작업 환경도 언젠가는 상당 부분 도구에 흡수될 것입니다. 그때는 또 다른 일을 하고 있을 것 같습니다.

요즘은 새로운 AI 도구를 보면 신기해서 켜보는 마음 옆에 질문 하나가 붙습니다.

이걸로 더 많은 일을 맡길 수 있게 됐는데, 저는 그 결과를 어디까지 이해하고 있을까요?