4월 12, 20262026-04-12
요즘 회사 안에서 일의 경계가 빠르게 흐려지고 있습니다. 예전에는 기획자가 기획을 하고, 디자이너가 화면을 설계하고, 개발자가 코드를 구현하는 식으로 비교적 역할이 또렷했습니다. 하지만 이제는 AI 도구와 에이전트 환경이 발전하면서, 한 사람이 여러 영역의 일을 직접 해보는 장면이 점점 더 흔해지고 있습니다.
특히 회사 내부 시스템을 AI가 다룰 수 있게 해주는 하네스 환경이 잘 갖춰지면, 비개발자도 데이터 조회, 화면 수정, 기능 추가 같은 일을 훨씬 빠르게 시도할 수 있습니다. 예전이라면 여러 사람을 거쳐야 했던 일이, 이제는 한 사람이 AI와 대화하는 것만으로도 상당 부분 해결되는 경우가 많아집니다.
5월 10, 20262026-05-10
최근 회사의 업무 프로세스가 AI 에이전트 도입으로 빠르게 바뀌고 있습니다. 필자가 속한 회사는 기술 기반 광고 운영 회사이고, 크게 광고 운영 조직과 프로덕트 개발 조직으로 나뉩니다.
광고 운영 조직은 고객사의 광고를 대행하여 운영합니다. 최근 이 조직은 GitHub 기반으로 광고 운영 지침, 스킬, 브랜드 데이터를 프로젝트화하고, Claude Code 또는 Hermes 같은 AI 에이전트와 대화하며 업무를 처리하는 방식으로 전환했습니다. 이 변화는 비교적 자연스럽게 받아들여졌습니다.
6월 28, 20262026-06-28
회사의 웹 서비스 저장소에서 한 가지 실험을 해본 적이 있습니다. 협업자들이 각자 작업 브랜치를 만들고 PR(Pull Request, 변경을 본 브랜치에 합치기 전 검토를 거치는 단위)을 올리는 전통적인 과정 없이, 모두가 기본 브랜치(develop)에 직접 push하는 방식이었습니다.
전통적인 개발에서는 지양하는 방식이지만, AI 에이전트가 개발의 상당 부분을 담당하는 환경에서는 브랜치와 PR을 만드는 절차 자체가 불필요한 병목일 수 있다는 가설이었습니다. 사람이 일일이 리뷰하지 않아도 CI(Continuous Integration, 코드가 합쳐질 때 자동으로 빌드·테스트를 돌리는 시스템)가 품질을 보장해 줄 것이라는 기대였습니다.
7월 3, 20262026-07-03
Claude Code 같은 코딩 에이전트에게 웹 서비스 디자인을 맡기면 웬만큼 괜찮은 결과물이 나옵니다. 그런데 뭔가 아쉽습니다. 어디서 본 듯 비슷비슷하고, 디테일이 다소 어설픕니다. 필자는 진행 중인 프로젝트의 디자인 시안을 뽑으면서 이 아쉬움을 해결할 방법을 찾아보았고, 스킬·MCP·하네스 지침을 하나씩 조사하여 최종 디자인 스택을 결정했습니다. 이 글은 그 조사와 결정의 과정을 정리한 것입니다.
조사하면서 가장 먼저 확인한 것은, 이 현상이 에이전트의 능력 부족 때문이 아니라는 점입니다. LLM(Large Language Model, 대규모 언어 모델)은 방향 지시가 없으면 가장 확률 높은 답을 냅니다. “괜찮은 버튼"의 최빈값은 Inter 폰트, 보라색 그라데이션, 카드 그리드, 흰 배경입니다. 모든 AI 생성 디자인이 닮아 보이는 이유가 여기에 있습니다.