지난 며칠 동안 나는 Claude라는 도구를 본격적으로 사용해보기 시작했다.
그동안 내가 가장 익숙하게 사용해온 인공지능 도구는 ChatGPT였다. 궁금한 것이 생기거나 작업 중 막히는 부분이 있을 때면 자연스럽게 창을 열어 질문했고, 대부분은 그것만으로도 충분하다고 생각했다.
프로그램을 작성하는 작업 환경에서도 몇 가지 보조 도구를 사용해본 적이 있다. 코드를 자동으로 완성해주거나, 작성 중인 내용을 바탕으로 다음 코드를 제안해주는 기능들이었다. 처음에는 기대가 컸지만, 실제로 사용해보니 내 작업 방식과는 잘 맞지 않았다.
내가 원하는 방향을 정확히 이해하지 못하거나, 현재 열어놓은 파일의 일부만 보고 제한적인 답을 내놓는 경우가 많았다. 때로는 제안된 코드를 다시 검토하고 수정하는 일이 더 번거롭게 느껴지기도 했다.
결국 그런 도구들은 얼마 지나지 않아 자연스럽게 사용하지 않게 되었다.
그러면서 나도 모르게 하나의 선입견을 갖게 되었다.
‘코드를 도와주는 인공지능 도구는 대부분 비슷하겠지.’
조금 편리할 수는 있어도, 결국 사람이 직접 전체 흐름을 파악하고 판단해야 한다는 생각이었다. 그래서 Claude를 처음 사용하기 시작했을 때도 특별히 큰 기대를 하지는 않았다.
그저 기존에 사용하던 도구와 무엇이 다른지 한번 확인해보고 싶다는 가벼운 호기심에 가까웠다.
하지만 실제로 사용해본 경험은 예상과 상당히 달랐다.
첫 번째 놀라움 — 프로젝트 전체를 읽어내는 눈
Claude를 작업 환경에 연결한 뒤, 가장 먼저 느낀 차이는 코드를 바라보는 범위였다.
기존의 도구들은 대체로 내가 현재 보고 있는 파일이나 선택한 코드 일부를 중심으로 답을 내놓았다. 물론 그것만으로도 간단한 오류를 찾거나 특정 기능을 구현하는 데에는 도움이 될 수 있다.
하지만 프로젝트가 조금만 커지면 이야기가 달라진다.
하나의 파일만 보아서는 그 코드가 왜 존재하는지, 다른 기능과 어떻게 연결되는지, 수정했을 때 어느 부분까지 영향을 미치는지 정확히 판단하기 어렵다.
이를테면 두꺼운 책의 한 페이지만 펼쳐놓고 전체 내용을 설명해달라고 하는 것과 비슷하다. 문장 자체는 읽을 수 있지만, 앞뒤 맥락과 전체 줄거리를 알기는 어렵다.
그런데 Claude는 내가 예상했던 것보다 훨씬 넓은 범위에서 프로젝트를 바라보았다.
각 파일을 따로 떨어진 조각으로 보는 것이 아니라, 프로젝트 전체를 하나의 구조로 이해하려는 모습을 보였다. 특정 기능이 어느 파일에서 시작되고, 어떤 함수를 거쳐 다른 기능으로 이어지는지 살펴보았다.
설정 파일과 실제 기능 코드의 관계를 확인하고, 공통으로 사용되는 함수가 어디에 영향을 주는지도 함께 짚었다. 한 부분을 수정했을 때 다른 부분에서 어떤 문제가 생길 수 있는지까지 연결해서 설명했다.
내가 보기에는 서로 별개처럼 보였던 코드들이 실제로는 하나의 흐름 안에서 이어져 있다는 점도 보여주었다.
이 경험은 단순히 답변의 길이가 길거나 설명이 자세하다는 것과는 달랐다.
Claude가 프로젝트 안의 여러 요소를 하나의 큰 그림으로 조립하고 있다는 느낌에 가까웠다.
기존 도구가 펼쳐진 한 페이지를 읽는 사람처럼 느껴졌다면, Claude는 책 전체를 한 번 읽고 등장인물과 사건의 관계를 정리한 사람처럼 보였다.
이 지점에서 처음으로 생각이 바뀌기 시작했다.
‘어, 이건 내가 전에 사용하던 도구들과 조금 다르다.’
단순히 코드를 대신 작성해주는 기능이 아니라, 내가 만든 프로그램의 구조를 함께 들여다보는 분석 도구에 가깝다는 인상을 받았다.
두 번째 놀라움 — 스스로 팀을 꾸려 분석하다. (하네스)
첫 번째 경험만으로도 충분히 흥미로웠지만, 여기서 한 걸음 더 나아가 보기로 했다.
명령어를 직접 입력해 사용하는 환경을 구성하고, 그 위에 필요한 도구들을 설치했다. 그리고 내가 기존에 만들어둔 소스 전체를 통째로 맡기며 분석을 요청했다.
사실 이때도 기대는 단순했다.
전체 코드를 읽고, 문제가 될 만한 부분을 정리한 긴 보고서 하나를 만들어주겠다고 생각했다.
그런데 실제로 벌어진 일은 예상과 달랐다.
Claude는 혼자서 하나의 답을 만들어내는 방식으로 움직이지 않았다. 작업을 여러 역할로 나누고, 각각의 역할을 맡는 일꾼을 스스로 만들어냈다.
내가 확인했을 때는 네 개의 작업 단위가 동시에 움직이고 있었다.
하나는 전체 구조를 살펴보고, 다른 하나는 코드의 흐름과 품질을 검토했다. 또 다른 하나는 안전과 관련된 문제를 확인하고, 나머지 하나는 다른 관점에서 앞선 분석을 검토하는 식이었다.
더욱 놀라웠던 점은 이들이 단순히 각자 분석한 내용을 따로 내놓는 데서 끝나지 않았다는 것이다.
한쪽에서 어떤 문제를 제기하면 다른 쪽이 그 내용을 다시 검토했다. 하나의 의견에 대해 다른 관점을 덧붙이기도 하고, 놓친 부분이 있는지 확인하기도 했다.
어떤 판단에 대해서는 이유가 충분한지 서로 검증하는 모습도 보였다.
화면을 지켜보는 동안, 마치 실제 개발자 네 명이 회의실에 모여 내 코드를 함께 검토하는 장면을 보는 듯했다.
한 사람은 전체 구조를 설명하고, 다른 사람은 위험한 부분을 지적한다. 또 다른 사람은 수정 과정에서 생길 수 있는 문제를 이야기하고, 마지막 사람은 지금까지 나온 의견을 정리한다.
물론 실제 사람처럼 완전히 독립적인 존재들이 대화를 나누는 것은 아닐 것이다.
그럼에도 사용자의 입장에서 보이는 과정은 충분히 인상적이었다.
하나의 도구에 요청했을 뿐인데, 그 도구가 스스로 작업을 나누고 여러 관점에서 결과를 검토하고 있었다.
그동안 나는 인공지능 도구를 ‘질문을 입력하면 답을 돌려주는 하나의 창’ 정도로 생각해왔다.
하지만 이 경험에서는 하나의 창이라기보다, 여러 명이 역할을 나누어 일하는 작은 분석팀에 가까웠다.
도구 하나가 스스로 팀을 꾸려 일하는 모습은 신기하면서도 낯설었다.
동시에 앞으로 프로그램을 분석하고 정리하는 방식 자체가 크게 달라질 수도 있겠다는 생각이 들었다.
세 번째 놀라움 — 내가 일부러 비워둔 부분까지 찾아내다
전체 분석이 끝난 뒤 나온 결과물은 예상보다 훨씬 구체적이었다.
단순히 코드가 복잡하다거나, 파일 구성이 정리되어 있지 않다는 식의 일반적인 지적에 머물지 않았다. 어떤 파일의 어떤 부분이 문제인지, 그것이 왜 문제가 되는지, 다른 코드와 어떤 관계가 있는지를 함께 설명했다.
그중에서도 나를 가장 놀라게 한 것은 안전과 관련된 분석이었다.
나는 이 프로그램을 만들면서 몇 가지 안전장치를 의도적으로 넣지 않은 상태로 남겨두었다.
몰라서 빠뜨린 것이 아니라, 아직 전체 작업이 끝나지 않았기 때문에 나중에 보완하려고 비워둔 자리였다. 기능을 먼저 완성한 뒤 마지막 단계에서 넣으려고 생각했던 부분도 있었고, 구조를 조금 더 정리한 뒤 적용하려던 부분도 있었다.
그 사실은 코드 안에 따로 기록해두지도 않았다.
오직 나만 알고 있는 작업 순서였다.
나 스스로도 작업을 진행하면서 ‘이 부분은 나중에 반드시 보완해야 한다’고 생각만 하고 넘어간 상태였다.
그런데 Claude는 그 빈자리를 정확하게 찾아냈다.
단순히 코드가 없다고 말하는 것이 아니라, 현재 구조에서는 어떤 안전장치가 필요하며, 그것이 빠져 있기 때문에 어떤 위험이 생길 수 있는지 설명했다.
내가 의도적으로 미뤄둔 부분을 다른 사람이 옆에서 지켜보고 있다가 찾아낸 것 같은 느낌이었다.
더 놀라운 것은 그다음이었다.
내가 알고 있던 빈자리뿐만 아니라, 내가 미처 생각하지 못했던 허술한 부분까지 함께 발견했다.
나는 기능이 정상적으로 작동하는지에 집중하느라 그 부분을 문제라고 생각하지 못하고 있었다. 실제 사용 과정에서 특정한 상황이 발생했을 때 어떤 문제가 생길 수 있는지까지 깊게 생각하지 못했던 것이다.
Claude는 그런 가능성을 코드의 흐름을 따라가며 찾아냈다.
입력되는 값이 예상과 다를 경우 어떤 일이 생길 수 있는지, 사용자의 권한을 확인하지 않은 채 다음 단계로 넘어가는 부분은 없는지, 중요한 정보가 지나치게 쉽게 노출될 가능성은 없는지 등을 짚었다.
프로그램이 평소에는 정상적으로 작동하더라도, 예외적인 상황이나 악의적인 사용을 만났을 때 문제가 될 수 있는 지점을 찾아낸 것이다.
그리고 단순히 “이 부분은 위험하다”는 지적만 남기지 않았다.
처음부터 어떤 방식으로 구조를 만들어두면 더 안전한지, 어느 단계에서 확인 절차를 추가해야 하는지, 현재 코드를 크게 뒤집지 않고도 어떤 순서로 개선할 수 있는지까지 제안했다.
문제를 발견하는 것에 그치지 않고 해결 방향까지 함께 보여준 셈이다.
나는 이 부분에서 꽤 큰 인상을 받았다.
코드를 대신 작성해주는 것보다 더 중요한 것은, 내가 보지 못하는 문제를 찾아내는 일일 수 있다.
특히 오랫동안 혼자 만들어온 프로그램은 작성자가 구조에 너무 익숙해져 있기 때문에 오히려 문제를 놓치기 쉽다.
어떤 코드를 왜 만들었는지 알고 있다는 사실이 때로는 판단을 흐리게 한다. 작성 당시의 의도를 알고 있기 때문에, 실제 코드에 부족한 부분이 있어도 머릿속에서 자연스럽게 보완해버리는 것이다.
반면 Claude는 내가 어떤 의도로 만들었는지를 먼저 믿고 넘어가지 않았다.
현재 코드에 실제로 무엇이 존재하는지, 무엇이 빠져 있는지를 기준으로 바라보았다.
그 차이가 내가 놓친 문제를 발견하게 만든 것 같았다.
감탄 뒤에 남은 한 가지 고민
이렇게 여러 번 놀라움을 경험했지만, 사용을 계속할수록 마음 한편에는 다른 종류의 고민이 생기기 시작했다.
Claude가 너무 많은 것을 빠르게 파악하고, 상당히 그럴듯한 해결책까지 제시해주다 보니 정작 내 코드에 대한 이해가 내 손에서 조금씩 멀어지는 듯한 느낌이 들었다.
예전에는 문제가 생기면 관련 파일을 하나씩 열어보았다.
어디에서 값이 넘어오고, 어느 함수에서 처리되며, 어떤 조건에 따라 결과가 달라지는지를 직접 따라갔다. 잘 이해되지 않으면 출력 값을 확인하고, 코드를 일부 수정해보며 원인을 찾았다.
그 과정은 분명 느리고 답답했다.
때로는 사소한 문제 하나를 해결하는 데 오랜 시간이 걸리기도 했다.
하지만 그렇게 여러 번 실패하고 다시 살펴보는 과정에서 프로그램에 대한 이해가 쌓였다.
어떤 기능이 어디에 연결되어 있는지 자연스럽게 기억하게 되었고, 비슷한 문제가 다시 생겼을 때는 이전보다 빠르게 원인을 찾을 수 있었다.
무엇보다 내가 만든 프로그램을 내가 이해하고 있다는 감각이 있었다.
그런데 Claude를 사용하면 이 과정이 크게 줄어든다.
전체 코드를 맡기면 구조를 정리해주고, 문제가 있는 부분을 찾아주며, 수정 방향까지 제안한다. 필요하면 실제로 변경할 코드의 형태까지 보여준다.
나는 그 결과를 읽고 맞는지 판단한 뒤 적용하면 된다.
당장은 분명 훨씬 빠르고 편리하다.
하지만 결과만 받아들이는 방식이 반복되면, 어느 순간부터 내가 프로그램을 이해하는 것이 아니라 Claude의 설명에 의존해 프로그램을 다루게 될 수도 있다.
코드 안에서 무언가가 궁금할 때마다 직접 확인하기보다 다시 Claude에게 묻게 될 가능성도 있다.
- “이 기능은 왜 이렇게 되어 있지?”
- “이 파일을 수정하면 어디에 영향이 생기지?”
- “이 오류는 왜 발생하지?”
처음에는 보조 도구로 사용했지만, 시간이 지나면 프로그램에 대한 기억과 판단을 점점 도구에 맡기게 될 수도 있다.
편리함을 얻는 대신 스스로 구조를 이해하는 힘이 약해질 수 있다는 뜻이다.
이 점은 단순히 인공지능을 많이 사용하면 공부를 덜 하게 된다는 식의 이야기는 아니다.
오히려 도구가 매우 뛰어나기 때문에 생기는 문제에 가깝다.
설명이 부족하거나 결과가 엉성하다면 사용자가 직접 확인할 수밖에 없다. 하지만 결과가 빠르고 정확해 보일수록 사람은 그 판단을 그대로 받아들이기 쉬워진다.
문제는 그 결과가 항상 옳은가가 아니다.
결과가 옳더라도, 내가 그 이유를 이해하지 못한 채 적용한다면 그 코드는 점점 내 것이 아니게 될 수 있다.
결국 다시 처음부터 읽어보기로 했다
그래서 나는 Claude가 만들어낸 분석 결과를 처음부터 다시 직접 읽어보기로 했다.
단순히 수정할 목록만 확인하는 것이 아니라, 왜 그런 분석이 나왔는지 코드와 하나씩 비교해보려 한다.
Claude가 특정 부분을 문제라고 판단했다면, 실제 코드에서 그 흐름이 어떻게 이어지는지 직접 확인해야 한다.
어떤 구조를 바꾸라고 제안했다면, 기존 구조가 왜 불편했는지, 새로운 구조는 어떤 점에서 나은지를 내가 설명할 수 있어야 한다.
안전장치가 필요하다고 했다면 그 코드를 그대로 붙여 넣는 것이 아니라, 어떤 상황을 막기 위한 장치인지 이해해야 한다.
결국 중요한 것은 Claude가 얼마나 좋은 답을 내놓느냐만이 아니다.
그 답을 내가 얼마나 내 것으로 만들 수 있느냐가 더 중요하다.
Claude를 전혀 사용하지 않고 모든 것을 혼자 해결하는 것이 정답이라고 생각하지는 않는다.
이미 이런 도구는 사람이 혼자 작업할 때 놓치기 쉬운 문제를 발견하고, 복잡한 구조를 빠르게 정리하며, 여러 관점에서 코드를 검토하는 데 큰 도움을 줄 수 있다.
굳이 오래 걸리는 길을 고집할 이유도 없다.
다만 빠르게 답을 얻는 것과, 그 답을 이해하는 것은 서로 다른 일이다.
Claude가 길을 보여줄 수는 있지만, 그 길을 실제로 걸으며 익히는 일은 결국 내 몫이다.
앞으로는 Claude에게 단순히 정답을 요구하기보다, 내가 이해할 수 있는 방식으로 설명하도록 요청하는 것이 더 중요할 것 같다.
코드를 바로 수정해달라고 하기 전에 먼저 구조를 설명하게 하고, 문제를 발견했을 때도 해결책만 받는 것이 아니라 왜 문제가 되는지 확인해야 한다.
제안된 수정 사항을 적용한 뒤에는 내가 직접 다시 코드를 따라가며 전체 흐름을 확인해야 한다.
그렇게 사용한다면 Claude는 나를 대신해 코드를 이해하는 도구가 아니라, 내가 코드를 더 깊이 이해하도록 돕는 도구가 될 수 있을 것이다.
도구의 능력보다 중요한 것
이번 경험을 통해 Claude가 단순한 코드 작성 보조 도구는 아니라는 것을 알게 되었다.
프로젝트 전체를 읽고, 파일 사이의 관계를 파악하며, 여러 역할로 작업을 나누어 분석한다. 내가 알고 있던 문제뿐 아니라 미처 생각하지 못했던 약점까지 찾아내고, 구체적인 개선 방향도 제안한다.
혼자서 오랜 시간 들여 확인해야 했던 일을 훨씬 빠른 속도로 정리해준다.
그 능력은 분명 놀라웠다.
하지만 그 놀라움 뒤에는 새로운 질문이 남았다.
이렇게 뛰어난 도구를 사용하면서도, 어떻게 내 코드에 대한 이해를 놓치지 않을 것인가.
편리함을 받아들이면서도 스스로 판단하는 힘을 어떻게 유지할 것인가.
앞으로의 중요한 과제는 인공지능을 사용할 것인지 말 것인지를 선택하는 일이 아닐지도 모른다.
이미 충분히 유용한 도구를 애써 외면하는 것도 좋은 방법은 아니다.
더 중요한 것은 어디까지 맡기고, 어디부터는 내가 직접 이해하고 판단할 것인지 기준을 세우는 일이다.
분석은 Claude가 더 빠르게 할 수 있다.
문제를 찾아내는 일도 Claude가 더 꼼꼼하게 해낼 수 있다.
그러나 어떤 방향으로 프로그램을 만들 것인지 결정하고, 그 결과에 책임을 지며, 전체 구조를 내 언어로 이해하는 일은 여전히 개발자의 몫이다.
도구가 뛰어날수록 그것을 사용하는 사람의 기준은 더 중요해진다.
이번 경험은 Claude의 능력에 감탄한 기록이면서, 동시에 내가 앞으로 어떤 방식으로 코드를 다뤄야 하는지 다시 생각하게 된 계기이기도 하다.
어쩌면 이런 고민은 새로운 도구를 처음 만난 사람이라면 누구나 거치게 되는 과정일지도 모른다.
도구는 점점 더 많은 일을 대신해줄 것이다.
그럴수록 사람에게 남는 중요한 능력은 직접 모든 것을 처리하는 능력보다, 결과를 이해하고 판단하며 자신의 것으로 만드는 능력이 될 가능성이 크다.
지금의 나는 Claude가 보여준 가능성에 여전히 놀라고 있다.
동시에 그 가능성에 완전히 기대지 않기 위해, 다시 내 코드를 처음부터 들여다보려 한다.
아마 앞으로의 답은 둘 중 하나를 선택하는 데 있지 않을 것이다.
Claude의 속도와 시야를 빌리되, 내 이해와 판단을 놓치지 않는 것.
그 균형을 찾아가는 일이 앞으로 내가 풀어야 할 가장 중요한 숙제로 남았다.