2026 상반기 회고 - 나개발자아냐힝

올해 상반기는 기능을 많이 만든 시기라기보다, 개발이라는 일을 다시 정의하기 시작한 시기였다. AI를 코드 생성기가 아니라 함께 일하는 동료로 받아들이기 시작했고, 자연스럽게 관심도 ‘무엇을 만들까’보다 ‘어떻게 개발할까’로 옮겨갔다.

AI가 처음 쓸 만해졌을 때만 해도 학습 도구나 간단한 코드 생성기 정도로 생각했다. 그런데 반년 만에 동료의 자리에 올라온 걸 보면 앞으로는 상사가 될 수도 있겠다는 생각까지 든다. 그때쯤 나는 무엇을 하며 돈을 벌고 있을까. 아직은 상상조차 잘 되지 않는다.

1, 2월의 나는 Flutter 개발자를 넘어 모바일 개발자가 되고 싶었다. 모바일 생태계를 더 깊게 이해하고, 플랫폼 심사라는 큰 벽 앞에서 배포를 더 쉽고 자유롭게 만드는 방법을 고민했다. 자주 사용하는 오픈소스에도 기여해 보고 싶었고, 지난 10년 동안 쌓아온 개발 경험 위에 “모바일도 이렇게 잘할 수 있답니다~”는 걸 증명하고 싶었다.

그런데 세상이 먼저 뒤집혔다.

학교에서 AI가 치와와와 초코칩 쿠키도 구분하지 못한다고 낄낄거리던 시절이 있었다. ChatGPT와 설계 이야기를 하다가 분통을 터뜨리던 때도 있었다. 그런데 Pro 요금제로 Codex를 제대로 사용해 본 어느 날, 무력감에 휩싸였다. 퇴근 후 백엔드 개발자 동료와 CU 주차장에서 담배를 두 대나 연달아 피우며 눈물까지 글썽였던 밤도 있었다.

내가 사랑했던 코드 한 줄이, 며칠 동안 고민하며 쥐어짠 로직이 토큰만 충분하면 순식간에 만들어지는 모습을 받아들이기가 쉽지 않았다.

마침 회사에서도 AX 전환을 위해 큰 비용을 들여 여러 도구와 외부 인력을 도입하고 있었다.

물론 처음 마주한 결과물은 실망스러웠다. “이제 코드 한 줄 안 봅니다💅” 같은 이야기도 들렸지만, 도구를 맹신하는 개발자만큼 위험한 사람도 없다고 생각했다. 실제로 Codex와 Claude도 처음에는 나라면 하지 않았을 선택들을 하고, 돌아는 가지만 삐걱거리는 결과를 가져오는 경우가 많았다.

그런데 재미있는 일이 생겼다.

몇 번의 꾸짖음이 메모리가 되고, 반복되는 잔소리가 스킬이 되고, 훅이 되고, “이건 하지 마.“가 가드레일이 되자 결과물이 눈에 띄게 좋아지기 시작했다.

그때 깨달았다.

‘아, 얘는 똑똑한 신입 개발자구나.’

결국 결과를 만드는 것은 AI 자체가 아니라, AI에게 어떤 맥락을 주고 어떤 기준으로 피드백하느냐였다.

마침 팀에서도 매니저로서의 역할이 조금씩 요구되던 시기였다. 사람을 매니징하는 일은 여전히 어렵다. 사람은 너무 많은 감정과 변수 위에서 움직인다. 하지만 AI는 달랐다. 충분한 맥락과 명확한 피드백을 주면 눈에 띄게 성장했다.

흥미로웠던 건 AI를 잘 다루는 방법을 고민할수록, 오히려 내가 제품과 도메인을 얼마나 이해하고 있는지를 계속 되돌아보게 되었다는 점이다.

이때부터 개발을 보는 관점이 조금씩 바뀌기 시작했다.

예전에는 얼마나 좋은 코드를 얼마나 빨리 작성하는가가 경쟁력이라고 생각했다. 하지만 AI와 함께 일하기 시작하면서 오히려 중요한 것은 무엇을 만들 것인지 정의하고, 좋은 맥락을 제공하고, 결과를 검증하는 능력이라는 생각이 들었다.

코드를 작성하는 일보다 개발이 굴러가는 시스템 자체를 설계하는 일에 더 큰 흥미를 느끼기 시작했다.

그래서 올해 상반기 가장 오래 붙잡고 있었던 주제는 AI Agent를 개발 프로세스 안으로 들여오는 것이었다.

그중에서도 가장 먼저 손대고 싶었던 영역은 QA였다. 우리 팀의 개발 프로세스에서 가장 늦게 문제를 발견하고, 가장 짧은 시간 안에 수습해야 하는 영역이었기 때문이다. 게다가 QA 안뽑아줘서 사용자가 장애겪고 개발자가 후다다닥 고치고.. 주말이나 밤늦게 연락온다치면 스트레스도 어마어마했기에.

처음에는 코드만 이해하면 충분하다고 생각했다. 그래서 Patrol을 검토했지만, 빠르게 변하는 제품과 WebView 중심 구조에서는 유지 비용이 너무 컸다. 결국 YAML 기반으로 시나리오를 수행하는 Maestro를 선택했다.

하지만 그것도 오래가지 않았다.

핵심 기능의 플로우를 작성해 두면 될 거라 생각했지만, 제품과 정책이 계속 바뀌는 환경에서는 시나리오가 시간이 지나면 반드시 낡았다.

그래서 자연스럽게 SSOT(Single Source of Truth)가 중심에 오기 시작했다.

기획과 정책, 그리고 그것을 반영한 코드가 하나의 진실이라면 AI가 그것을 읽고 실제 사용자처럼 앱을 탐색하면 되지 않을까?

이 질문에서 QA Agent의 방향이 바뀌었다.

정해진 시나리오를 반복하는 것이 아니라, SSOT를 이해한 AI가 직접 앱을 탐색한다. 기대와 다른 동작이 발견되면 버그일 수도 있고, SSOT 자체가 잘못되었을 수도 있다. 어느 쪽이든 수정해야 할 대상은 명확해진다.

QA Agent를 만들면서 흥미로웠던 것은 테스트를 자동화하는 방법보다, QA 자체가 결국 사람의 사고 과정을 그대로 따라간다는 점이었다.

사람은 테스트를 수행하고, 결과를 해석하고, 원인을 추론하고, 수정한 뒤 다시 검증한다.

그렇다면 AI도 같은 루틴을 수행할 수 있지 않을까?

이 질문은 자연스럽게 “AI는 어디까지 개발 프로세스에 참여할 수 있을까?“라는 고민으로 이어졌다.

처음에는 QA 브랜치에서 테스트를 수행하는 구조를 생각했지만, 곧 너무 늦다는 걸 깨달았다.

우리 팀은 백엔드와 WebView 의존성이 크고, 모바일 앱은 심사 일정까지 고려해야 한다. 배포 전주에는 개발이 사실상 끝나 있어야 한다. QA와 버그 수정에 사용할 수 있는 시간은 생각보다 매우 짧았다.

결국 QA는 개발이 끝난 뒤 하는 일이 아니라, 개발하는 순간 함께 이루어져야 한다는 결론에 도달했다.

그래서 지금은 PR 단계에서 AI가 기능을 이해하고 탐색하며 테스트를 수행하고, 가능한 수정까지 제안하는 방향으로 계속 설계를 발전시키고 있다. QA를 마지막 단계가 아니라 개발 과정 자체에 녹여내는 것이 지금 가장 실험해 보고 싶은 개발 문화다.

QA Agent를 만들다 보니 자연스럽게 다른 영역도 자동화해 보고 싶어졌다. 그래서 pre-pr-reviewer와 pr-respond 같은 작은 Agent들도 만들기 시작했다.

pre-pr-reviewer는 기존 컨텍스트를 배제한 채 코드 자체만 리뷰하고, pr-respond는 Gemini나 사람이 남긴 리뷰를 분석해 실제 수정이 필요한 피드백을 분류하는 역할을 맡겼다.

AI도 사람처럼 좋은 리뷰를 하기도 하고 엉뚱한 리뷰를 하기도 한다. 그래서 AI가 AI를 검증하도록 만드는 것도 꽤 흥미로운 문제였다.


돌아보면 상반기에는 기능보다 질문을 더 많이 만들었다.

* AI는 어떻게 우리 제품을 이해할까?
* 앱은 왜 서버처럼 자유롭게 배포하지 못할까?
* 테스트는 언제까지 사람이 해야 할까?
* AI는 어디까지 개발 프로세스에 참여할 수 있을까?

아직 답을 모두 찾지는 못했다.

하지만 적어도 예전처럼 좋은 개발자 = 코드를 잘 쓰는 사람이라고는 생각하지 않는다.

코드가 내 경쟁력이라고 생각했던 시절도 있었지.. 지금은 문제를 해결하는 방식이 내 경쟁력이라고 생각한다.

코드도, AI도, 사람도 결국 문제를 해결하기 위한 도구다.
실제로 AI가 잘 이해하게 만드는 과정에서 구조 설계하고 코드 한땀한땀 치던 때의 기분을 느끼기도..그러니까 대충, 열받고 성취감 느껴진다는 뜻이다.

어쩌면 앞으로 개발자의 역할은 코드를 가장 잘 작성하는 사람이 아니라, AI가 만든 결과를 가장 잘 판단하고 책임지는 사람으로 조금씩 바뀔지도 모른다. 적어도 나는 그 방향으로 준비해 보려고 한다.

하반기에는 Flutter 프로젝트를 AI가 더 잘 이해하도록 만들고, QA Agent를 계속 다듬어 보고 싶다. AI가 개발 과정 속에서 자연스럽게 함께 일할 수 있는 환경을 만드는 것이 지금의 가장 큰 목표이다! 연말에는 지금보다 더더 발전한 고민들을 하고 있으면 좋겠다.

물론 그때에도 뭔가로 열받아 있겠지만🫠