시대의 변화를 느끼며

요즘 나는 어떻게 개발을 하는가

요즘 나는 Codex를 두 계정으로 사용하면서 개발하고 있다. 원래는 Plus 계정 하나만 사용했는데, 토큰이 부족한 경우가 꽤 자주 있었다. 그렇다고 바로 Pro로 넘어가기에는 당시 구독 모델이 내 기준에 딱 맞는 중간 선택지가 없었다. 그래서 결국 Plus 계정 두 개를 쓰는 쪽이 그때는 가장 현실적인 선택이라고 판단했다.

그런데 두 계정을 쓰기 시작하니 다른 불편함이 생겼다. 터미널에서 매번 로그인과 로그아웃을 반복해야 했고, 작업하다가 계정을 바꿔야 할 때마다 흐름이 끊겼다. 그러다 자연스럽게 이런 생각을 하게 됐다.

“터미널마다 계정을 더 편하게 오갈 수는 없을까?”

이 고민 끝에, Codex CLI를 한 번 더 감싸는 래퍼 CLI를 만들면 되겠다고 생각했다. A 계정 정보와 B 계정 정보를 각각 저장해두고, 브라우저 로그인 방식까지 활용하면 계정을 훨씬 자연스럽게 전환할 수 있지 않을까 싶었다. 그렇게 해서 만든 것이 바로 codex-mux다.

codex-mux를 만들면서 가장 크게 느낀 점은, 이제는 내가 불편한 것을 내가 바로 해결할 수 있는 시대가 왔다는 것이다. 예전 같았으면 CLI 하나를 만들기 위해 블로그를 한참 뒤지고, 공식 문서를 읽고, 시행착오를 여러 번 겪었을 것이다. 그런데 지금은 그런 과정이 훨씬 짧아졌다. 필요한 것을 떠올리고, 바로 만들고, 곧바로 써볼 수 있다. 이 점이 정말 좋다.

그리고 여기서 끝이 아니다. 지금은 Codex만 지원하는 것이 아니라, Gemini와 Claude Code까지 함께 지원하는 새로운 래퍼 CLI도 만들고 있다. 예전에는 도구를 익히는 데 많은 시간이 들었다면, 이제는 내가 원하는 방식으로 도구를 재구성하는 쪽으로 사고가 바뀌고 있다.

나는 이제 직접 코드를 거의 치지 않는다

요즘 내 개발 방식은 이전과 꽤 많이 달라졌다. 이제 나는 거의 직접 코드를 치지 않는다. 체감상 99%는 AI 에이전트가 코드를 작성하고, 내가 손대는 부분은 1% 정도다. 그것도 주로 간단한 UI 수정이나 애니메이션 수치 조정 같은 마무리 작업에 가깝다.

이렇게 개발하다 보면 문득 이런 생각이 든다.

“내가 코드를 치는 법을 잃어버리고 있는 건 아닐까?”

그런데 곰곰이 생각해보면, 꼭 멍청해지고 있는 것은 아닌 것 같다. 오히려 사고의 방향이 달라졌다고 보는 편이 더 맞다. 예전에는 내가 직접 구현하는 방식으로 문제를 풀었다면, 지금은 어떻게 해야 AI 에이전트가 이 일을 더 잘하게 만들 수 있을까, 어떻게 지시해야 더 정확하고 부작용 없이 결과를 낼 수 있을까를 더 많이 고민하게 된다.

즉, 손으로 코드를 치는 비중은 줄었지만 문제를 구조적으로 바라보는 시간은 오히려 늘어난 것 같다. 어떤 접근이 더 좋은지, 어떤 맥락을 먼저 줘야 하는지, 어떤 방식으로 명령해야 원하는 결과가 나오는지를 계속 생각하게 된다. 그런 의미에서는 사고 능력이 떨어진다기보다, 사고의 초점이 구현에서 조율과 설계로 이동하고 있다고 느낀다.

그런데 동시에 소프트웨어 공학적 사고는 약해지고 있는 것 같기도 하다

이런 개발 방식이 편한 것은 사실이지만, 한편으로는 경계해야 할 부분도 분명히 있다. 요즘 들어 나는 예전보다 소프트웨어 공학적인 사고를 덜 하게 되는 것 같다. 기술 관점에서 왜 이렇게 설계해야 하는지, 추상화 레벨을 어떻게 나눌지, 클린 코드를 어떻게 유지할지 같은 고민을 예전만큼 치열하게 하지 않는 순간들이 있다.

이건 분명히 좋지 않은 습관이다. 편해진 만큼 나도 모르게 나태해지고 있는 것일 수도 있다. AI가 너무 많은 것을 대신해주다 보니, 내가 기본기를 놓치고 있는 것은 아닌지 자주 돌아보게 된다.

그래서 요즘은 다시 개발 책을 읽고, 기술 블로그도 더 의식적으로 보려고 한다. 단순히 작동하는 코드를 만드는 데서 끝나는 것이 아니라, 왜 이 코드가 좋은 코드인지, 왜 이 설계가 더 나은 선택인지를 계속 생각하려고 한다. 시대가 아무리 빨리 바뀌어도, 결국 이런 기본적인 소프트웨어 공학적 사고는 계속 중요할 것이라고 본다.

지금은 개발자가 꽤 특별한 시대를 살고 있다고 생각한다

나는 지금이 개발자에게 꽤 특별한 시대라고 생각한다. 구현은 이전보다 쉬워졌고, 성능 개선도 훨씬 빠르게 시도해볼 수 있다. 예전 같았으면 며칠 걸렸을 작업이 이제는 훨씬 짧은 시간 안에 가능해졌다. 그런 의미에서 지금은 개발자가 이 변화를 직접 체감할 수 있는 드문 시기라고 느낀다.

이제 코딩은 더 이상 소수만 할 수 있는 어려운 일이 아니게 되어가고 있다. 누구든 AI의 도움을 받아 어느 정도는 만들 수 있는 시대가 왔다. 나는 이 흐름을 부정적으로만 보고 싶지는 않다. 오히려 이 좋은 시기를 즐기면서, 동시에 미래를 준비하는 것도 충분히 의미 있다고 생각한다.

우리는 아날로그, 디지털, 그리고 AI까지 이어지는 큰 변화를 빠르게 체감하고 있다. 나 역시 아직까지는 이 흐름을 따라잡으려고 애쓰고 있지만, 가끔은 이런 의문도 든다.

“앞으로 10년 뒤에도 나는 지금처럼 변화를 따라갈 수 있을까?”

이 질문은 쉽게 답할 수 없다. 앞으로 우리가 어디로 가야 하는지, 무엇을 준비해야 하는지 사실 아무도 정확히 모르는 것 같다. 아니면 어쩌면 이미 다들 어느 정도는 알고 있는데, 너무 빨라서 모르는 척하고 있는 것일 수도 있다. 그 정도로 시대의 속도가 빠르다.

AI와 일할 때는 맥락과 문제 정의가 정말 중요하다

요즘 느끼는 것은, AI는 결국 앞뒤 맥락을 충분히 알아야 문제를 더 잘 해결한다는 점이다. 그리고 막연하게 “알아서 해결해줘”라고 할 때보다, 먼저 원인을 분석하고 해결 방향을 정리한 뒤 작업을 시킬 때 훨씬 더 정확하게 움직인다.

예전에는 그냥

“문제 파악해서 알아서 해결해”

이런 식으로 많이 던졌다. 그런데 그렇게 하면 내가 원하던 문제가 정확히 해결되지 않는 경우가 꽤 많았다.

반대로 지금은 먼저 문제의 원인이 무엇인지 보고, 해결 방안을 어떻게 가져갈지 생각한 뒤, 그 다음에 작업을 실행하게 하는 방식이 훨씬 낫다고 느낀다.

결국 AI도 문제를 잘 풀기 위해서는 문제 정의가 분명해야 한다. 사람에게 일을 시킬 때와 크게 다르지 않다. 아니, 어쩌면 더 그렇다.

테스트 코드는 AI 시대에 더 중요해진 것 같다

한 프로젝트를 계속 작업하다 보면 이런 일이 생긴다. A 문제를 해결해달라고 했는데, 정작 해결 후에는 B 문제가 새로 생기는 경우다. 나는 특정 조건만 만족시키고 싶었을 뿐인데, 그 조건 때문에 기존 기능의 전후 동작이 망가지는 식의 사이드 이펙트가 발생하는 것이다.

이 문제를 겪으면서 더 강하게 느낀 것이 있다. AI 시대일수록 테스트 코드가 더 중요하다는 점이다.

테스트 코드를 작성하면 개발자가 원하는 동작을 더 명확하게 정의할 수 있다. 그러면 AI 에이전트가 코드를 수정하더라도, 마음대로 구조를 흔들거나 예상치 못한 부작용을 만드는 것을 어느 정도 막을 수 있다. 왜 이런 문제가 생기냐고 생각해보면 결국 단순하다. AI가 이해한 조건과 내가 생각한 조건이 다르기 때문이다.

그래서 테스트 코드는 단순히 품질을 위한 도구를 넘어, 이제는 내 의도를 AI에게 정확히 전달하는 안전장치처럼 느껴진다.

프로젝트 문서는 이제 사람만을 위한 것이 아닌 것 같다

요즘 나는 새로운 에이전트로 개발을 시작할 때, 먼저 내가 작성한 문서를 읽고 프로젝트를 파악하라고 알려준다. 그리고 이런 프롬프트도 반복해서 쓰지 않도록 스킬 형태로 정리해 바로 사용할 수 있게 만들어두었다.

이게 중요한 이유는, 프로젝트를 먼저 이해한 상태에서 작업하면 에이전트가 훨씬 효율적으로 움직이기 때문이다. 내 추측이지만, 이렇게 하면 불필요한 파일 탐색을 줄일 수 있어서 토큰도 아낄 수 있다고 본다.

특히 내 프로젝트는 모노레포 구조인 경우가 많아서, 어떤 패키지가 문제의 원인인지 바로 찾기 어려운 경우가 있다. 이때 에이전트가 탐색 범위를 좁혀서 접근할 수 있게 해주는 문서는 꽤 큰 도움이 된다. 문제가 생겼을 때 원인이 있는 파일을 더 빠르게 찾을 수 있고, 불필요한 수정도 줄일 수 있다.

나는 요즘 웹게임도 만들고 있는데, 웹게임에서는 규칙과 연출 순서가 굉장히 중요하다. 그래서 이런 흐름과 규칙이 정리된 파일이 따로 있는 것도 매우 유용하다고 느낀다. 결국 문서는 사람만을 위한 것이 아니라, 이제는 AI 에이전트와 함께 일하기 위한 운영 매뉴얼에 가까워지고 있다.

AI 에이전트를 쓰며 잃었던 재미를, 다른 방식으로 다시 찾고 있다

처음 AI 에이전트를 강하게 체감한 건 Cursor를 사용할 때였다. 내 프로젝트에서 프롬프트를 입력하면 알아서 코드를 수정해주는 경험이 꽤 신기했다. 그런데 시간이 지나면서 예상하지 못한 감정이 생겼다. Cursor에 점점 의존할수록, 코딩 자체의 재미가 사라지고 있다는 느낌이 들었다.

그냥 프론트엔드 개발자가 아니라 프롬프트 엔지니어가 된 것 같은 기분도 있었다. 예전처럼 직접 코드를 치면서 문제를 해결하고, 구글링해서 원인을 찾고, 시행착오를 거쳐 해결하는 과정이 줄어드니 재미가 덜해진 것이다. 그리고 그 과정에서 나도 모르게 나태해지고, 소프트웨어 공학 공부에도 소홀해지고 있다는 사실을 깨달았다.

그런데 이 문제는 시간이 지나면서 조금 자연스럽게 해결됐다. Codex, Claude Code, Gemini CLI 같은 도구들을 더 깊이 쓰기 시작하면서, 고민의 결이 바뀌었기 때문이다.

이제 나는 어떻게 하면 이 문제를 더 정확하게 해결할 수 있을까, 어떻게 프롬프트를 짜야 사이드 이펙트 없이 원하는 결과를 얻을 수 있을까, 어떻게 여러 에이전트를 도입해 개발 속도를 더 높일 수 있을까 같은 고민을 더 많이 하게 되었다.

이런 고민을 하다 보니 다시 개발이 재미있어졌다. 다만 예전처럼 “코딩하는 재미”라기보다는, “개발하는 재미”에 더 가깝다. 어차피 이미 우리는 코딩 그 자체만으로 승부하는 시대에서 조금씩 벗어나고 있다. 그렇다면 차라리 나는 개발의 본질적인 재미, 즉 문제를 해결하고 무언가를 만들어내는 재미를 붙잡는 편이 더 맞다고 느꼈다.

결국 내가 좋아했던 것은 코딩이 아니라 창작이었던 것 같다

이런 생각을 하다 보면 중학생 때가 자주 떠오른다. 그때 나는 게임을 만들 때 노코드 기반 도구를 많이 사용했다. 돌이켜보면 그 시절에도 내가 진짜 좋아했던 것은 코드를 친다는 행위 자체가 아니었다.

노코드를 통해서라도 내 작품을 만들고, 그걸 다른 사람에게 보여주고, 나만의 창작물을 세상에 내놓는 것에서 큰 재미를 느꼈다.

요즘 다시 그 감정을 느끼고 있다. 이제는 AI 시대가 오면서, 예전 같았으면 공부를 많이 해야만 만들 수 있었던 창작물을 지금은 생각만으로도 훨씬 빠르게 현실로 옮길 수 있는 시대가 되었다. 그래서 나는 이 시대가 정말 좋다고 느낀다.

결국 내가 좋아했던 것은 코딩 그 자체라기보다, 무언가를 만드는 일, 그리고 내 머릿속의 생각을 실제로 꺼내는 일이었던 것 같다.