현 시점에서 실력이라는 것은 무엇일까

최근 작업하는 사항들이 많아지고 있는데, codex 를 max 구독하여 여러가지 부분에서 테스트를 진행중이었다. 어떤 프로젝트들은 오직 바이브 코딩으로 단 한번도 내부 구현사항을 체크하지않고, 오직 실제 작동을 통해 디버깅하고 개선하는 과정을 거치면서 진행헀고, 어떤 프로젝트는 AI 를 활용하지만 단위를 함수 혹은 도메인 변경사항을 토대로 코드는 AI 가 작업하고, 실제 PR 을 직접 리뷰하면서 진행하였다. 사람의 개입도에 따라서 완성도가 달라진것이 맞냐고 하냐면 맞을 순 있지만 지금까지의 경험으로는 그렇게 하나의 생각으로만 결론지어지지는 않는 것 같다.

AI 에게 지시사항을 전달할 수록 이상하게 의도와 멀어지게 된다.

장담할 수는 없고, 여전히 나는 AI 를 잘 사용한다고 생각하지는 않는다. 아마 나보다 훨씬 AI 를 잘 사용하시는 분들은 신뢰도가 훨씬 높게 사용하고 계실것 같지만, 확실히 나의 경험 상 AI 와의 작업은 많은 소통을 진행한다고 해서 그 프로젝트의 완성도가 높아진다고 생각이 들진 않았다.

처음에는 “AI 가 신경쓰지 못하는 도메인적 사항과 각 사용하는 프레임워크 설계, 주의해야할 점 등을 지속적으로 제시해주고 같이 논의를 진행할 수록 좋은 서비스가 탄생”한다는 믿음이 존재했다. 이런 믿음이 존재했었던 과거의 시점이라면 정확히 1년 정도 전에 cursor 기반으로 자동 완성을 테스트해보고 있었던 시기였는데, 그 시기때는 확실히 자연어로서 요구할 때, 많은 정보와 지시사항을 계속해서 주입할 수록 조금이라도 더 나은 결과를 반환했었다.

회사에서 mvp 모델로서 특정 프로젝트를 만들고 전달받았을 때, 구현된 화면의 모습에 놀랐고, 이후 구현된 코드 상황에 또 한번 놀랐었다. 솔직히 AI 활용이 없다면 리펙토링을 할 자신이 없을 정도의 코드였고 이 경험이 앞에서 말한 믿음으로 이어졌던 것 같다.

믿음이 존재했었다는 표현이니 지금은 믿음이 없는것이냐 라고 하면 그렇지는 않은데, 예전만큼 ‘나 자신이 AI 보다 더 판단력이 좋다’ 라고는 절대 믿지 않는다. 그렇기에 최근에는 AI 를 믿고 어느정도는 맡기는 경우도 많고, 같이 상의할때도 많아지고 있다.

그런데 최근에 많은 토큰을 사용하면서 느낀점인데, 이상하게도 직관적인 설명과 요구사항을 통해 빠르게 수정 배포 후 피드백을 반복한 케이스보다, 처음부터 신중하게 같이 고려하고, 설계를 진행하면서 작업을 진행한 케이스의 결과 효용성이 더 안좋았다는 느낌을 받았다. 단순 느낌을 넘어서 정말로 실제 구현결과도 만족스럽지 않았다.

바이브코딩으로 나 혼자 사용할 서비스를 생성할 때, 딱히 디자인 시안을 자세히 제공한것도 아니고, 도메인 설계를 엄격하게 진행하거나 아키텍쳐를 체크한것도 아니지만 정말 자연어로 원하는 상황만 요구하면서 실제 구현사항을 보면서 피드백을 진행하면서 정말 개발자가 아닌 시점에서 서비스를 생성해나갔고 그 결과가 나쁘지않다. 실제로 지금도 활용을 하고 있다.

그런데 정말 한 3일 이상 같이 설계를 진행하고, 고민을 하면서 함수 단위, 도메인 기능 단위로 계속 리뷰를 하면서 만든 서비스는 (물론 잘 동작까진 하고 예상되는 문제에서 더 대비가 되어있는것은 맞지만) 기대 이하의 구현 결과를 보여주었다. 수 많은 테스트코드와 설계를 기반으로 생성한 코드들인데, 실행하면 의외로 간단한 부분에서 작업 에러가 발생하고, 속으로 ‘이런 간단한 사항도 에러가 발생한다고? 그러면 테스트코드는 왜 작성한거지?’ 라는 짜증이 올라왔다.

AI와의 작업은 기존의 사고 체계에서 좀 더 벗어나야 하는걸까?

하네스 설계가 유행했고, 정확한 설계 문서를 생성하여 이를 토대로 구현을 진행할 수록 좋은 코드가 나오는 예시 영상을 유튜브로 접한 뒤, 앞으로의 AI 활용은 이러한 방식으로 진행해야 겠다 확신이 들었었다. 지금도 AI에게 구현을 요청할 때 더 정확한 지시와 구체적인 아키텍쳐를 제공하고, 지켜야할 도메인 조건과 기능들에 대해서 지속적으로 AI와 논의하면서 설계문서를 개정해나갔다.

그런데 왜 더 생각대로 서비스가 운영되지 못하는 걸까? 오히려 바이브코딩보다 더 속도도 느려서 실제 사용하고 운영하고 있는 서비스는 바이브코딩으로 만든 서비스들이다.

분명 실제 바이브코딩으로 생성한 서비스의 코드 파일을 열어보면 이걸 어떻게 관리해야하지 할 정도로 로직의 분리나 아키텍쳐, 유지보수에 있어서 ‘진짜 구동을 시킬것이야’ 라는 목적 하나만을 위한 코드가 보이긴 한다.이건 내가 예상한 상황이고 이런 상황을 피하기 위해서 바이브코딩을 하지 않은 것인데, 정작 중요한 사용성이나 완성도에서 별로 차이가 없거나 오히려 부족하다면 내가 하고 있는 방식들을 한번 돌아봐야되는게 아닐까 생각이 든다.

멈춰서 생각해보니 한 가지 머리를 스쳐지나가는 생각이 있다.

나는 정말로 서비스를 제대로 컨트롤 하고 있다고 확신할 근거가 있는가? 실제로 제대로 하고 있는가?

AI와의 피드백을 통해 분명히 설계와 계획을 명확하게 가져갔으며 이를 AI 가 코드 구현으로 실행시킬 때, 이 코드를 보고 심지어 리뷰까지 거쳐서 병합까지 한 서비스가 제대로 작동하지 않는다는 것이 AI의 내가 모르는 한계점이 있을 수도 있고 (실제 context 의 비대나 사용을 지속할 수록 성능이 조금 떨어졌다라는 말은 들어본것 같지만) 사용하고자 하는 설계의 문제일 수 있지만, 단순 자연어 요청에도 꽤나 괜찮게 서비스르 생성하는 현 시점의 AI 모델을 고려할 때 차라리 ‘나’를 의심하는것이 더 합리적이라는 생각이 들었다.

내가 가진 검토 사고 체계에는 문제가 없나? 너무나도 빠른 구현 생태계에서 지금의 사고 체계가 과연 유리한가?

답은 아직 모르겠지만 냉정하게 체크해보자

더 정교한 설계와 이를 위한 논의를 거치는 동안, 바이브 코딩을 하면서 거치는 과정들을 생각해보았다.

• 서비스 이용 중 장애 발견
• 즉각적으로 해당 장애에 대한 의견과 수정 부탁
• AI 는 버그 트레킹을 한 뒤 실제로 수정 후 배포 진행
• 다시 서비스 이용 중 장애 발견 후 같은 환경 반복
• 여기에 새로운 기능을 추가하고 싶다면 즉각적으로 자연어로 전달

위 과정을 계속해서 반복하면서 서비스를 수정해나간다.

그런데 어찌되었던 바이브가 아닌 확실한 구조를 설계하고 유지보수성을 확보하면 AI가 없어도 수정이 쉽고, 문제파악이나 새로운 기능 추가가 용이해지기에 미래에는 거진 동일한 수준의 서비스 배포 속도가 나오는게 아닐까 생각했다.

여기서 다시 돌아보았을 때, 확실히 문제가 될 만한 요소들이 생각이 났다.

• 실제 코드리뷰를 할 때, 처음과 달리 시간이 지날수록 꼼꼼한 리뷰를 진행하지 않았다. 정확히는 피로감이 쌓여갔다.
• 테스트코드에 관해서는 오히려 AI 를 ‘어떠한 근거도 없이’ 신뢰하고 그대로 병합했다.
• AI가 작업하기 전 plan 을 보여줄 때, 해당 계획에 대해서 분석적으로 체크하질 못하고 있었다. 줄 글을 읽는것에 이미 지쳐있었다. 다르게 말하자면 같이 논의해서 plan 을 세웠다면 ‘잘 세웠겠지’ 하고 넘어갔다.
• 코드 리뷰를 한다고 해도 명확하게 깔끔하게 작성하지 못한 부분에 한해서 리뷰를 진행했지, 실제 작성된 코드가 실제 다른 부분과의 잠재적 이슈나 코드 자체 내에서의 이슈를 찾아내는 리뷰를 하지 못했다. 정확히는 할 수 있는 맥락을 유지하는것이 힘들었다.
• 그러나 이슈별로 나누어서 구현을 진행하고, PR 에 대한 리뷰를 진행하면서 (동시에 codex 의 코드 리뷰를 진행시키면서) 실제 개발과정은 AI를 사용하기 전처럼 진행

실제 개발 과정처럼 진행하는것 같지만, 의외로 절차만 존재하지 실제로는 “알아서 잘 해줘”의 마음이 깔려있고, 생각 이상으로 그 비중이 컸었다라는 생각이 들었다. 사실상 절차있는 바이브코딩과 크게 다르지 않구나 생각이 들었다. 여기에 속도는 기존 바이브코딩보다 당연하게도 나오지 않으며, 실제로 서비스를 개발하다가 속도가 너무 안나오는것 같으니 속도를 내고 싶을 때는 느슨하게 허락하면서 빠르게 병합을 해 나간 다음에 실제 동작을 진행시킨 다음에 문제점을 디버깅 했었다. 이건 전형적인 앞서 설명한 바이브 코딩의 과정이었다.

사실상 체크는 덜 하게 되는데, 속도는 안나오니 바이브코딩 서비스 결과보다 안좋은것은 당연할지도..

AI를 다루는 실력이라는 것에 진지해져야겠다

인정할 수 밖에 없었다. 유튜브를 통해 AI를 잘 다루시는 분들의 영상을 참고하기도 했고, 실제 바이브코딩의 결과도 살펴보곤 했지만 내심 마음속에서는 직접 AI를 사용해본 경험으로서 불안정함을 느끼고 제대로 서비스를 진행하려면 AI의 책임을 줄이고 실제 사용자의 구현 및 설계 과정에 집중해야지 된다고 강하게 믿고 있었다. 즉, 잘하는 개발자들은 AI는 알아서 잘 쓰게 될 것이라고 믿었다.

여기서 ‘잘하는 개발자’ 라는 정의가 이전의 내 생각과는 다르게 정의되어야 할 것 같다는 생각이 들었다.

개발을 잘한다는 것은 여러 복합적인 측면에서의 ‘잘함’ 이 포함되는것이라 생각이 든다. 그리고 지금까지는 이 ‘잘함’ 이라는 분야를 코드와 아키텍쳐, 탄탄한 컴퓨터 기반 지식과 경험을 갖추고 있는 점이라고 해석했고 믿었다. 그렇기에 내 자신이 이러한 관점에서의 개발을 ‘잘’한다면 자연스럽게 AI의 사용능력이 좋아질 것이라 생각했다.

이러한 사고는 수능과 자격증 시험을 거쳐온 내 오래전 축적에서 비롯된 관점이라는 것을 알게되었을 때, ‘잘함’ 이라는 부분에는 절대로 ‘지식과 상황경험’ 만이 있는것이 아니란 것을 느끼게 되었다. 그리고 정말 잘하시는 개발자들은 기본적으로 갖추고 계실 능력이라는 점에서, 세간에서 말하는 잘하는 개발자들은 AI도 잘 쓴다라는 말이 틀린것은 아닐것 같다.

• 작업의 분배를 적절하게 나눌 수 있는 경계를 보는 능력
• 각 작업의 설계와 이에 대한 검증의 수단까지 모두 고려한 뒤, 실제 행위로 진행할 줄 아는 지식들
• 처음부터 확정적인 설계가 아닌 매 변경되는 상황에 맞게 이슈를 생성 후 필요한 논의만을 거친 뒤 바로 실행에 옮기는 결단
• 변경되는 사항이 어떠한 문제를 야기할 수 있는지 알고 있고, 이를 위한 정확한 테스트를 진행할 수 있는 지식과 실력
• 무엇보다도 긴장과 이완을 잘 조절하는 집중력

이러한 능력이 지식과 경험에 더해 갖추고 계신 분들이 정말로 ‘잘하는 개발자’ 가 아닐까 싶다. 이런 분들은 AI에게 무엇을 위임해야할지, 무엇을 직접 체크하면서 흐름을 이끌어 나갈지 정확하게 경계를 나눌 수 있으실 것이며, 이미 머리속의 지식 및 경험으로 정리된 괜찮은 아키텍쳐를 통해 서비스의 성격에 맞게 속도를 내면서 진행하실것이며, 무엇을 중심적으로 테스트를 해야할지 제대로 체크를 하실 것 같다. 그리고 AI와 함께 일을하면서 느끼는 맥락 교환과 수 많은 코드, 줄글들을 효율적으로 집중해서 처리하는 능력이야 말로 현 시대 내 실력이라고 할 수 있지 않을까.

확실히 시대가 변했다.

대부분의 개발자들이 구현을 직접하지 않는 시대가 왔다. 어려운 문제의 진입장벽이 훨씬 낮아진것도 사실이다. 동시에 우려섞인 목소리도 많이 나온다. 개발 근본을 제대로 공부하지 않으면 제대로 된 개발을 할 수 없다는 영상이 수도없이 나오고 있다.

내 생각에는, 잘 하는 개발자가 되기 위해 실력을 쌓는다는 것은, 결국은 ‘호기심’ 이 아닐까 싶다. 인간의 호기심은 위 요구하는 능력을 키우는 데 핵심적인 요인이 될 것이라 생각이 든다. 집중력, 분석, 판단을 위한 지식학습, 실제 진행력 등등.. 탐구본능이 이끌어낼 수 있는 능력이 아닐까.