왜 시장은 휴머노이드 로봇에 주목하는가

(AI를 활용하여 작성된 글입니다) 1. 구현에서 이동한 비용 코딩 에이전트가 바꾼 가장 큰 변화는 “개발 전체가 쉬워졌다”가 아니라, 코드 작성 비용이 낮아졌다는 점입니다. 예전에는 아이디어를 코드로 옮기는 일 자체가 큰 병목이었습니다. 요구사항을 읽고, API를 찾고, 보일러플레이트를 만들고, 오류를 고치고, 테스트를 붙이는 데 개발 일정의 상당 부분을 써야 했습니다. 이제는 자연어로 요구사항을 설명하면 코딩 에이전트가 초안을 만들고, 테스트 코드를 제안하고, 리팩터링 방향까지 제시합니다. 이 변화는 이미 개발 현장에 깊게 들어와 있습니다. 2025년 DORA 보고서는 응답자의 90%가 업무에서 AI를 사용하고 있으며, 80% 이상은 AI가 생산성을 높였다고 본다고 설명합니다. 동시에 30%는 AI가 만든 코드를 거의 신뢰하지 않거나 전혀 신뢰하지 않는다고 답했습니다. AI가 개발 속도를 높이는 것은 맞지만, 그 결과물이 곧바로 신뢰 가능한 production code가 되는 것은 아니라는 뜻입니다. 그렇다고 소프트웨어 개발 비용 전체가 낮아졌다고 말하기는 어렵습니다. 코딩 에이전트가 주로 낮춘 것은 코드 생성 비용입니다. 좋은 소프트웨어를 만들려면 여전히 요구사항을 정의해야 하고, 코드를 리뷰해야 하며, 테스트와 보안 검토를 거쳐야 합니다. 배포 안정성, 운영 가능성, 제품 판단의 비용도 사라지지 않았습니다. 코드 생성이 쉬워질수록 오히려 그 뒤에 있는 검증과 판단의 부담은 커질 수 있습니다. 한 명의 개발자가 하루에 만들 수 있는 코드의 양이 늘어나면, 팀은 그 코드가 정말 필요한지, 기존 시스템과 맞는지, 오래 유지할 수 있는지 더 많이 확인해야 합니다. 비용은 사라진 것이 아니라 이동했습니다. 구현 비용은 낮아졌지만 리뷰, 통합, QA, 보안, 기획 판단의 비용이 더 크게 보이기 시작했습니다. 강한 팀은 AI로 더 좋아질 수 있지만, 약한 팀은 AI 때문에 기존 문제가 더 선명하게 드러납니다. 특히 자동화된 테스트, 성숙한 버전 관리, 빠른 피드백 루프 같은 통제 장치가 없으면 변경량 증가가 안정성 문제로 이어질 수 있다고 지적합니다. 그래서 코딩 에이전트 시대의 핵심 질문은 “얼마나 빨리 코드를 만들 수 있는가”가 아닙니다. 더 중요한 질문은 “빨리 만들어진 코드를 팀이 어떻게 받아들이고, 무엇을 거절하며, 어떤 기준으로 검증할 것인가”입니다. 코드가 빨리 만들어지는 일은 분명한 진전입니다. 그러나 소프트웨어는 코드가 작성되는 순간 끝나지 않습니다. 코드는 리뷰되고, 병합되고, 테스트되고, 배포됩니다. 장애를 만들기도 하고, 다시 수정되기도 합니다. 몇 달 뒤 다른 개발자에게 읽히고, 몇 년 뒤 기술 부채로 돌아오기도 합니다. 코드 생산비용이 낮아졌다는 사실은 개발 조직에 축복이지만, 동시에 새로운 압박입니다. 이제 팀은 더 많은 코드 후보를 더 짧은 시간 안에 판단해야 합니다. 2. AI가 만든 그럴듯한 코드의 역설 코딩 에이전트의 부작용은 코드가 단순히 “나쁘게” 만들어진다는 이야기가 아닙니다. 더 정확히는 코드가 너무 쉽게, 너무 많이, 너무 그럴듯하게 만들어진다는 데 있습니다. 명백히 이상한 코드는 오히려 쉽게 잡힙니다. 문법 오류가 있거나, 테스트가 바로 깨지거나, 구조가 눈에 띄게 어색한 코드는 리뷰어가 빠르게 거절할 수 있습니다. 더 어려운 것은 겉으로는 자연스럽고, 변수명도 괜찮고, 테스트 일부도 통과하지만 실제 요구사항의 예외 케이스를 놓치거나 기존 시스템의 암묵적 제약을 깨는 코드입니다. AI가 만든 코드는 이런 방식으로 리뷰 비용을 높입니다. 리뷰어는 단순히 diff를 읽는 데서 멈출 수 없습니다. 그 코드가 어떤 가정 위에서 만들어졌는지, 그 가정이 팀의 도메인과 시스템에 맞는지까지 복원해야 합니다. Stack Overflow의 2025년 개발자 설문은 이 긴장을 잘 보여줍니다. 응답자의 84%는 개발 과정에서 AI 도구를 사용하거나 사용할 계획이 있다고 답했고, 전문 개발자의 51%는 매일 AI 도구를 사용한다고 답했습니다. 그런데 AI 도구 결과의 정확성에 대해서는 신뢰보다 불신이 더 컸습니다. AI 결과를 신뢰한다고 답한 비율은 33%였고, 불신한다고 답한 비율은 46%였습니다. 사용은 늘고 있지만 신뢰는 아직 충분하지 않은 상태입니다. 이 간극을 검증 부채라고 부를 수 있습니다. 기술 부채가 “지금은 빠르게 가기 위해 나중에 갚아야 할 구조적 비용”이라면, 검증 부채는 “지금은 빠르게 생성하기 위해 나중에 확인해야 할 불확실성”이라고 할 수 있습니다. 코딩 에이전트는 초안을 빠르게 만들 수 있습니다. 다만 그 초안이 production code가 되려면 요구사항 검증, 테스트 보강, 보안 점검, 기존 아키텍처와의 정합성 확인을 거쳐야 합니다. 이 과정을 건너뛰면 팀은 당장은 빨라진 것처럼 보일 수 있습니다. 그러나 나중에 더 큰 비용을 치르게 됩니다. 버그 수정, 장애 대응, 리팩터링, 온보딩 비용, 코드 이해 비용이 뒤로 밀릴 뿐입니다. 개발자들이 체감하는 문제도 여기에 가깝습니다. Stack Overflow 2025 설문에서 AI 도구를 쓸 때 가장 큰 불만은 “거의 맞지만 정확하지 않은 해결책”이었고, 66%가 이를 언급했습니다. 두 번째로 큰 불만은 “AI가 만든 코드를 디버깅하는 데 시간이 더 걸린다”는 것이었으며, 45.2%가 답했습니다. 즉, AI가 코드를 빠르게 만들어주지만, 그 코드가 애매하게 틀렸을 때 사람은 더 많은 시간을 들여 원인을 찾아야 합니다. 보안 리스크도 같은 구조로 생깁니다. AI가 만든 코드는 기능적으로 동작하더라도 보안적으로 안전하지 않을 수 있습니다. 특히 보안 요구사항은 명시하지 않으면 빠지기 쉽습니다. “파일 업로드 API를 만들어주세요”라는 요청에 인증, 권한, 파일 크기 제한, 확장자 검증, 악성 파일 검사, 저장 경로 제한, 로그 정책을 명시하지 않으면 AI는 기능 구현에 집중할 수 있습니다. 코딩 에이전트는 단순 자동완성 도구와도 다릅니다. 파일을 읽고, 명령을 실행하고, 외부 문서를 참고하고, 패키지를 설치하고, PR을 수정할 수 있습니다. 유지보수 측면에서도 같은 문제가 반복됩니다. AI는 새 코드를 만드는 데 강하지만, 좋은 소프트웨어는 새 코드를 많이 만든다고 완성되지 않습니다. 좋은 소프트웨어는 기존 구조를 이해하고, 불필요한 ...

이제 시작하기 전에 생각했던 기능이 어느정도 완성되었습니다. 하면서도 계속 고민이 되는 부분이 소스에 대한 한계였는데요. 소스로 네이버 뉴스 api를 사용했는데, 이게 뉴스의 요약본을 제공하는 형태라 아무래도 한계가 있을 수 밖에 없다고 생각되었습니다. 그 외에도 중복된 뉴스가 너무 많고 어뷰징을 위한 기사들도 많기 때문에, 일부 신문사(개인적으로 많이 들어본 신문사)를 중심으로 필터링하고 제목이 비슷하면 필터링 하는 등의 과정을 거쳤으나 그래도 여전히 많았습니다. DB에 내용을 잘 쌓아가려면 유의미한 기사를 중심으로 수집하는 것이 중요한데, 그게 어렵겠다는 생각이 많이 들었습니다. 그래서 다음은 텔레그램 메세지를 소스로 해서 비슷한 걸 해볼까 생각 중입니다. 저 같은 경우 텔레그램에서 몇몇 채널에 들어가있는 상태이지만 매일 그 메세지를 읽기에는 시간도 없고...

이번에는 graph DB가 어떤 것인지, graph RAG는 어떤 효용이 있을 지 확인해보고자 진행했으나, graph RAG는 조금 더 공부해보고 이후에 다시 다뤄보려고 합니다. 이번에는 정말 아는 것도 없었고 "graphDB라는게 있다고 하네, 이렇게 해보면 되지 않을까?" 라는 생각에 진행한 것이라 대부분을 antigravity에 의존했습니다. 아래 이미지를 통해 대략적인 느낌을 확인하실 수 있으실 것 같습니다. 간단하게 설명하자면 LLM(Gemini API)을 활용해서 검색어에 대해서 정해진 기간 내의 이 요약본을 찾아보고(네이버 API), 요약본에 대해 엔티티와 관계 정보를 추출해 그래프 DB(Neo4j)로 구조화하도록 하였습니다. 이를 통해 사용자가 특정 기간 동안의 뉴스 흐름과 연관성을 직관적인 그래프 형태로 확인할 수 있도록 구현했습니다. 그래프의 엣지 부분에는 기사 링크가 연결되어있고 클릭 시 원문을 확인할 수 있게 구현했습니다. 기술적으로 이렇게 써보면 되겠다는 느낌은 받을 수 있었고 재미는 있었는데, 그래서 "너 이거 쓸거냐?" 했을때는 아직 많이 부족하다고 느껴졌습니다. 소스도 네이버 뉴스 API를 사용했는데, 이게 뉴스 요약본을 주는 거라 소스도 부족한 부분이 있습니다. graph RAG 등을 공부해보면서 어떻게 나아가면 좋을 지 생각해봐야겠습니다.

https://www.valley.town/space/@steady-raven-mh1bo0kjnaz/articles/698f8dc556a0d7d3a544b63a 이 글을 보고 뭐라도 해봐야겠다는 생각에 진행한 내용입니다. 이번에 개발한 내용은 증권사 리포트를 바탕으로 답변을 제공하는 LangChain, LangGraph 기반 AI Agent 입니다. (https://github.com/mu-jeong/financial-report-agent) 데모 스크린 샷은 아래와 같습니다. GUI CLI 개발의 95%는 antigravity의 챗봇에서 진행한 것 같습니다. 모델은 gemini 3.1 flash/pro, claude sonnet/opus 4.6 의 도움을 받았습니다. 개발하는 것 이외에도 readme 작성, test 코드 작성 및 test도 모두 code assistant를 통해 진행했습니다. 개인적으로 개발을 했다면 지금 정도의 개발을 하는 것에 최소 1~2개월 정도는 걸렸을 것 같은데, 이번에는 순수 개발에 사용한 시간만을 본다면 10일 정도인 것 같습니다. 이번 프로젝트에서는 LangChain, ...

지금까지의 학습은 세상에서 검증된 지식이나 사실을 기억하고 응용하는 것이었습니다. 필요할 때 머릿속 데이터베이스에서 정보를 꺼내 쓰기 위해 우리는 끊임없이 암기하고 이해해야만 했습니다. 하지만 세상의 거의 모든 지식을 담은 거대한 AI를 손쉽게 사용할 수 있게 되면서, 사람들은 '무언가를 새롭게 배우는 것'의 필요성에 의문을 가지기 시작한 것 같습니다. 저는 이러한 의문에 대해, AI 시대의 학습은 단순히 지식을 축적하는 행위를 넘어 '원하는 결과에 도달하기까지의 과정을 최적화하고, 소모되는 리소스(시간과 토큰)를 최소화하는 것'으로 진화했다고 생각합니다.  사전 지식이 전혀 없는 상태에서 AI에게 질문을 해야한다면, 우리는 AI에게 두루뭉술하고 포괄적인 질문을 던질 수밖에 없습니다. 결과는 어떨까요? AI는 일반적이고 평균적인, 즉 '안전하지만 뻔한' 대답을 내놓습니다. 내가 진짜 원했던 문제해결을 위한 날카로운 인사이트나 구체적인 실행 방안은 빠져 있기 마련입니다. 결국 "아니, 그게 아니라 이런 조건으로 다시 해줘", "이 부분은 빼고 저 부분을 강조해 줘"라며 수없이 질문을 반복해야만 합니다.   예를 들어 AI에게 특정 기업에 대한 가치평가(Valuation)를 요청할 때, 단순히 "이 기업의 가치를 평가해 줘"라고 막연하게 묻는 것과, "어떤 거시적 지표와 데이터를 사용하고,...