안녕하세요, 박민재입니다. 기술 블로그에 글을 올리지 않은 지 1년이 넘은 것 같네요. 최근에는 개발 공부보다 개인적인 삶에 집중하는 시간을 잠시 보냈습니다. 제가 글을 올리지 않은 그 사이 가장 크게 발전한 기술을 꼽자면, Claude Code / Codex와 같은 AI Agent가 아닐까 싶습니다. 개발 문화부터 Product 레벨의 활용까지, 저 역시 2~3년 전만 해도 ChatGPT 같은 툴을 간단한 스크립트 작성 그 이상으로는 활용하지 않았는데, 이제는 훨씬 넓은 영역을 커버할 수 있게 되었습니다.
하지만 이와 함께 우려의 목소리도 커지고 있습니다. AI가 개발자의 많은 영역을 대체하면서, 개발자에게 위기가 찾아온 것 아니냐는 이야기가 나오고 있죠. 실제로 아마존 같은 빅테크에서는 대규모 인원 감축이 있었고, 국내 규모 있는 IT 기업들도 개발자 채용을 동결하는 사례가 늘면서, SW 엔지니어를 직업으로 가진 분들의 불안감이 커지고 있는 것은 사실입니다.
하지만 시대는 이미 변했고, 우리는 AI를 활용해 개발자로서 더 크고 좋은 가치를 창출할 수 있어야 합니다. 요즘 드는 생각은, 사람은 새로운 가치를 만드는 데 에너지를 쏟고, 반복적이거나 패턴이 정해진 업무는 AI에게 맡겨야 한다는 것입니다. 기술적인 질문에 답하거나 반복 작업을 처리하는 일은 이제 ChatGPT, Gemini, Claude가 더 잘할 테니까요. 물론 그 결과를 검증하는 것은 여전히 사람의 몫이지만요. (요즘에는 여러 AI를 교차 활용해 서로 검증하게 하는 방식도 많이 쓰이더군요.) 그래서 저도 앞으로 이 기술 블로그는 단순한 기술 정리보다는, Insight를 기록하는 공간으로 활용할까 합니다. 요즘 개발자들은 StackOverflow도 잘 보지 않으니까요.
이제는 Claude Code / Codex를 사용하지 않는 개발자를 오히려 찾기 어려운 시대가 되었다고 생각합니다. 다만, Clean Code 이론처럼 정형화된 AI Agent 사용 방법론은 아직 자리를 잡지 못한 느낌입니다. 그럼에도 많은 분들의 공통적인 사용 패턴을 이야기하자면, Claude Code 기준으로 /init 명령어를 통해 프로젝트 구성을 CLAUDE.md에 기록하고, 반드시 따라야 할 지침들을 정리해 반복 작업을 최대한 표준화하는 방식이 주를 이루는 것 같습니다.
저의 경우에는, 특정 컴포넌트가 왜 이런 아키텍처를 채택하게 되었는지에 대한 ADR(Architecture Decision Record)을 Markdown으로 기록하고 CLAUDE.md에서 이를 참조하도록 하거나, Jira / Wiki의 내용을 연동해 컨텍스트로 제공하는 방식을 쓰고 있습니다. 또한 제가 모호한 질문을 던질 경우, ouroboros와 같은 도구를 활용해 AI가 보다 명확한 질문을 되물어 의도한 Output을 얻을 수 있도록 하기도 합니다. 테스트를 자동으로 수행해 성능 Benchmark 결과를 Wiki에 자동으로 기록하게 하는 것처럼, 반복 작업을 최소화하는 다양한 방법을 시도하고 있습니다.
당연하게도 SRE 측면에서도 AI Agent를 연동해 활용할 수 있습니다. 저희 팀에서는 팀원들이 공통으로 사용하는 Command를 모아서 Markdown으로 관리하고, 이를 기반으로 Grafana MCP를 연동해 서버 상태를 모니터링하거나, 장애 발생 시 Kubernetes Pod 로그가 적재된 OpenSearch 기반 스토어에 쿼리를 날려 원인을 파악하기도 합니다. 혹은 OpenStack API(사내 클라우드를 OpenStack 기반으로 운영하고 있습니다)를 호출해 Kubernetes 클러스터의 이상 여부를 다양한 방식으로 진단하기도 하고요. ADR처럼, 과거에 어떤 문제가 있었는지를 기록해두면 해당 Claude 세션이 어디서부터 살펴봐야 할지 가이드라인을 제시할 수도 있습니다.
AI Agent를 코드 작성에 쓰든 SRE에 쓰든, 공통적으로 필요한 전제가 하나 있습니다. 우리가 다루려는 정보가 AI Agent의 접근 범위 안에 있어야 한다는 것입니다. 이는 두 가지 의미를 가집니다.
첫 번째는 AI Agent 세션에서 물리적으로 도달 가능해야 한다는 점입니다. 사내 보안 정책 등으로 접근이 막힌 정보이거나, MCP는커녕 API 엔드포인트조차 제공받지 못하는 경우라면 활용이 매우 까다로워집니다. 이런 정보는 결국 사람이 직접 확인해 컨텍스트를 AI Agent에 수동으로 삽입해야 합니다.
두 번째는 AI Agent가 이해할 수 있는 형태여야 한다는 점입니다. 아무런 전처리 없이 youtube.com 링크를 던져주고 요약해 달라고 하면 AI도 난감할 것입니다. 원하는 정보를 추출하려면, AI가 이해할 수 있는 형식으로 가공되는 파이프라인이 먼저 갖춰져 있어야 합니다.
AI Agent가 아무리 뛰어나도, 결국 일은 우리가 해야 합니다. 지금 우리가 서 있는 병목 지점은 어디일까요?
첫 번째는, 의사결정에 필요한 모든 정보를 AI Agent가 갖고 있지 않다는 점입니다. 요즘은 Google Meet을 사용하면 Gemini가 대화 내용을 텍스트로 요약해주지만, 실제 맥락은 Slack, Jira, Wiki, 회의, 심지어 오프라인 대화 등 여기저기 흩어져 있는 경우가 많습니다. 그 속에 담긴 비언어적 표현이나 분위기까지 AI가 파악하기는 어렵습니다. 결국 가장 많은 컨텍스트를 쥐고 있는 것은 여전히 사람인 경우가 많습니다.
두 번째는 창의성입니다. AI Agent는 우리가 인사이트를 던져주면 많은 문제를 해결하지만, 그 이상의 창의적인 발상을 스스로 가져오지는 못합니다. 적절한 예시일지 모르겠지만, 엘리베이터 속도가 느리다는 불만을 해결하기 위해 내부에 거울을 설치한 사례처럼, 문제의 본질을 우회하는 창의적인 접근은 아직 사람의 영역입니다.
마지막으로, AI는 책임을 지지 않습니다. 책임이 없기 때문에 AI Agent의 판단은 제약 없이 발산하는 경향이 있습니다. 어떤 선택이 가져올 운영 리스크, 잠재적 위험, 팀 간 이해관계, 비용 문제 등은 고려 대상 밖입니다. 따라서 AI Agent가 무한정 발산하지 않도록, 그 책임의 범위를 명확히 제한하는 것이 중요합니다.
이렇게 보면, 일정 수준 이상의 SW 지식을 갖췄다는 전제 하에, 앞으로 개발자에게 더 중요해지는 건 소프트 스킬이라는 생각이 듭니다. 요즘 업무 방식을 되돌아보면, 마치 주니어 개발자 2~3명을 이끌고 파트를 운영하는 것과 비슷한 느낌입니다. AI Agent가 수행한 결과와 판단 근거를 검토하고, 이를 적용할지 말지 동료들과 논의하는 과정을 반복하고 있으니까요.
결론적으로, 요즘 시대의 개발자는 시키는 일을 하는 사람이 아니라, Product Ownership을 바탕으로 AI Agent에게 일을 위임하고 조율하는 역할로 바뀌고 있습니다. 그래서 이제는 주니어 개발자에게도 상황을 파악하고 조율하는 리더십이 필요해진 것이 아닐까요. 우리는 AI Agent가 작성한 코드에 책임을 지는 사람들이니까요. 최근에는 이러한 흐름에 맞는 새로운 SW 개발론도 제안되고 있고, 어떤 문제를 직접 해결하고 어떤 문제를 위임할지 판단하는 철학이 점점 더 중요해지는 세상이 된 것 같습니다. 이 혼란스러운 시대 속에서 모두가 자신만의 의미를 찾으시길 바라며, 글을 마칩니다.