→ 필요한 개념이나 기술을 검색하고 → 관련된 문서, 블로그, GitHub를 뒤져보며 아이디어를 얻고 → 구현하고 테스트하고 → 오류가 나거나 원하는 대로 동작하지 않으면 다시 검색하고 → 수정하고 개선하는 과정을 반복했다.
문제 해결을 위해 끊임 없이 검색과 시행착오를 반복하는 이 과정은 프로그래밍을 할 때 자연스러운 흐름이었다.
코드 에이전트가 있기 전에는 이 과정이 너무 익숙해서 시간이 오래걸리고 집중 흐름이 끊긴다는 생각은 해보지 못했었다.
하나의 기능을 만들기 위해 브라우저 창을 수십 번 열고 닫았고
무언가 해결할 수 있다는 가능성으로 수 많은 검색 키워드를 남기며 부딪혀야 했다
반면 코드 에이전트나 AI 개발 도구를 활용할 때는
무엇을 만들고 싶은지만 자연어로 설명하면
→ AI가 필요한 구조를 제안해주고 → 파일과 디렉터리를 자동으로 생성하고 → 관련된 라이브러리와 코드까지 작성해준다.
궁금한 내용이 생기면 검색창을 열어 키워드를 곰곰이 생각하고 검색하지 않고 바로 에이전트에게 물어볼 수 있다.
명령어 실행이나 설정도 Run 버튼 하나로 해결된다.
수정이나 리팩토링이 필요하면 문맥을 이해한 상태에서 그에 맞는 제안까지 해준다.
무언가를 찾고 또 고민하고, 조합하는 데 들던 에너지는
이제 무엇을 만들지에만 집중할 수 있도록 바뀐 느낌이다.
AI가 제안한 내용을 잘 판단할 수만 있다면 개발 시간이 50-70%까지 단축될 것이라고 생각한다.
코드 에이전트가 있기 전에는 내가 모든 걸 직접 찾아 해결해야하는 방식이었다면
코드 에이전트가 있을 때는 내가 원하는 방향을 말하면 AI가 해답을 가져다주는 방식이다.
Cursor와 같은 AI 개발툴에 대한 생각
Cursor는 vscode(IDE)에 AI를 결합한 형태의 개발툴로 볼 수 있다.
직접 로직과 코드를 작성해주는 것 뿐 아니라 검색, 코드 추천, 리팩토링, 문서 작성 등 다양한 개발 보조 작업도 AI를 통해 진행할 수 있다.
실제로 사용하다 보면 개발 속도나 몰입도가 상당히 높아짐을 체감할 수 있다.
코드 에이전트나 AI 기반 개발 환경 툴의 등장으로 SW 개발 방식 자체를 근본적으로 변화시킬 수 있다는 견해가 있다.
개발자는 코드를 작성하는 방식에서 벗어나 코딩 어시스트와 상호작용을 하게 되는 방식으로 변화할 것이라는 것이다.
코드를 일일이 작성하지 않고 무엇을 만들지를 자연어로 표현을 하면 AI가 이를 해석해 코드를 생성하거나 수정, 검증까지 하는 흐름으로 변화할 것이라는 전망이다.
반면, 이는 일시적인 열풍에 불과하며 Cursor와 같은 툴이나 AI에 과도하게 의존하면 개발 역량이 약화된다는 주장도 있다.
로직이나 시스템 설계를 깊이 이해하지 못한 채로 코드만 생성하다 보면
디버깅이나 복잡한 문제 해결 과정에서 한계를 경험하게 된다는 것이다.
AI가 제공하는 편의성에 익숙해져 개발자 스스로가 사고하고 문제를 해결하는 능력이 저하될 수 있다는 점을 시사한다.
한 사례에서는 Cursor에서 사용자에게 "I cannot generate code for you, as that would be completing your work. you should develop the logic yourself"라고 대답한 적이 있다고 한다. (출처) 단순 할루시네이션이었는지 프로 체험판이 끝난 후 안내 문구가 잘못 출력된 버그였는지는 명확하지는 않다. 하지만 이 사례를 계기로 AI가 단순히 코드를 생성하는 수동적인 도구에 머무를 것이냐 아니면 개발자의 사고 과정을 이해하거나 더 나은 전략을 함께 고민하고 제시하는 능동적인 파트너로 발전해야 하느냐에 대한 논의가 이루어지고 있다.
개인적으로는 이 흐름이 일시적인 유행이라고 생각하지는 않는다. 새로운 패러다임이 등장하면 늘 반대하는 의견은 존재하지만 결국에는 더 효율적이고 편리한 방식으로 가는 흐름을 거스를 수는 없다고 본다.
물론 AI 도구의 활용이 개발자의 사고 능력이나 문제 해결 역량을 약화시킬 수 있다는 우려에는 동의한다. 하지만 오히려 이러한 역량의 중요성은 줄고 개발자의 역할이 재정립될 것이라고 생각한다. 단순하고 반복적인 작업의 자동화를 통해 복잡하고 창의적인 문제 해결 능력에 집중할 수 있을 것이다. 지금까지는 기술적인 구현만 잘해도 인정받는 개발자가 많았지만 앞으로는 비즈니스 가치를 이해하고, 사용자와 문제를 정의할 수 있으면서 여러 사람들과 협업하고 커뮤니케이션하는 능력이 더 중요할 수 있다. AI가 제공할 수 없는 영역이 어떤 것이 있을지 생각해보면 사람만이 할 수 있는 창의적인 아이디어와 고유의 통찰력 등이 있다. 이러한 부분에 대한 중요성이 대두될 것 같다.
실질적으로 코드 에이전트와 같은 도구와 방법론을 지속적으로 익히고 빠르게 업무에 적용해야 한다는 사실은 변하지 않을 것이다.
다만 코드 작성 시간이 줄었다고 해서 일이 편해지는 것 만은 아닐 것이다. 코딩 어시스턴트가 누락한 설정이나 조건이 있는지 더 개선할 점은 없는지 스스로 의심하고 찾아보는 역량이 중요해질 것 같다. 이 부분은 경험이 적은 주니어 개발자에게는 어렵게 느껴질 수 있다. AI가 핵심 내용만 추려주기 때문에 무엇을 더 살펴봐야 하는지 조차 모를 수도 있다. 결국 실력이 좋은 개발자는 이를 발판 삼어 더 빠르게 성장할 수 있지만 그렇지 않은 개발자는 AI에 의존하면서 오히려 전체 흐름을 놓치고 더 어려움을 겪을 수 있다. 그래서 개발자 간의 역량 격차는 줄어들기보다는 오히려 더 벌어질 수도 있다고 생각한다.
AI를 활용하여 개발을 하다보면 개발의 주체를 자꾸 AI로 넘기게 된다. 나보다 AI가 더 잘알겠지, 이게 맞겠지.. 하면서
하지만 문제 해결의 주체는 끝까지 나 자신이라는 점을 잊지 않아야 한다. AI가 제공하는 솔루션을 비판적으로 검토하고 이를 더 확장하는 능동적인 자세를 항상 유지해야 한다. 그리고 이제는 앱 개발자, AI 개발자처럼 역할이 명확하게 나뉘던 시대도 변할 수 있다. AI 도구를 통해 다양한 기술 도메인 간의 장벽이 허물어지고 있다. 덕분에 더 복잡하고 도전적인 프로젝트에 접근하기 쉬워졌다. 이 기회를 잘 활용해서 다양한 경험을 쌓는 것이 앞으로의 개발자에게 중요한 과제가 될 것 같다.
블로그 글을 쓰는 것에 대해
개발 블로그를 시작한 지 벌써 6년쯤 되어가는 것 같다. 그동안은 주로 오류를 해결하는 방법, 새로운 기술에 대한 소개, 논문 내용을 정리해서 올려왔다. 이런 글들은 대부분 검색을 통해 다른 사람들에게 닿았고 내가 겪었던 시행착오나 나열된 정보들을 통해 누군가는 문제 해결의 실마리를 얻었을 것이다.
논문 내용을 정리할 때는 개인적인 해석이나 의견을 덧붙이기보다는 되도록 원문 구조를 유지하면서 번역하듯 최대한 자세하게 작성하려고 했었다. 나는 오히려 개발 블로그란 그런 역할을 해야 한다고 생각했기 때문이다. 괜히 오류 가능성이 있는 주관적인 해석을 포함하거나 사람마다 견해가 갈릴 수 있는 내용을 쓰는 것보다는 사전처럼 참고용으로 쓸 수 있는 글이 더 도움이 될 거라고 믿었다.
그래서인지 내 블로그는 검색 키워드에 꽤 잘걸리는 편이었고, 방문자 수도 꾸준히 늘어났다.
그런데 이제는 상황이 많이 달라졌다. 무언가를 하기 위해 검색창을 켜는 사람 보다 AI 챗봇이나 AI 도구를 먼저 켜는 사람이 더 많아지고 있다. 정보를 전달하는 블로그 글은 이제 사람이 직접 읽기보다, AI가 문맥 속에서 참조하는 용도로 쓰이게 될 것 같다. 이런 생각이 들면서 '이제 블로그 글을 쓰는 게 의미가 있나?' 하는 생각도 들었다. 실제로 지금 블로그에 올라와 있는 내용 대부분은 공식 문서나 레딧, 깃허브, 스택오버플로우에 이미 있는 내용들이고 그저 정리된 버전일 뿐이다. 그래서 이 블로그가 AI가 아닌 사람에게 읽히면 좋겠다고 생각이 들었다. 단순히 정보를 나열하는 글 뿐 아니라 나의 생각과 고찰과 고민이 담근 글도 함께 써보려고 한다.