기록
OmOCon Seoul 후기
최근 OmOCon Seoul에 다녀왔다.

행사 전체를 한 문장으로 정리하면, “AI 에이전트를 어떻게 더 잘 부릴 것인가”에 대한 이야기였다.
답변하는 AI에서 실행하는 AI로
예전에는 AI에게 주로 답을 물었다.
“이 코드 왜 안 돼?”, “이 글 좀 요약해줘”, “아이디어 좀 내줘” 같은 방식이었다.
하지만 이제 사람들은 AI에게 단순한 답변보다 실행을 원한다.
코드를 고치고, PR을 만들고, 자료를 조사하고, 메시지를 보내고, 문서를 정리하고, 반복적인 작업을 대신 처리해주길 기대한다.
이때 중요한 건 AI 모델 자체만이 아니다.
AI에게 실제로 손과 발을 달아주려면, 그 AI가 어떤 환경에서 움직이고, 어떤 도구를 쓰고, 어디까지 판단하고, 어디서 사람에게 확인을 받아야 하는지가 필요하다.
이번 행사에서 반복적으로 나온 키워드가 바로 이 지점이었다. 에이전트, 하네스, 컨텍스트, 메모리, 워크플로우
CMUX와 에이전트 시대의 작업 공간
CMUX 발표도 흥미로웠다. Claude Code, Codex 같은 코딩 에이전트를 쓰다 보면 기존 IDE나 터미널만으로는 부족해지는 순간이 온다.
여러 에이전트를 동시에 돌리면 어떤 에이전트가 어떤 프로젝트에서 무슨 일을 하고 있는지 헷갈린다.
브랜치, 포트, 디렉토리, 작업 상태, GitHub issue나 PR과의 연결 같은 정보가 흩어지기 쉽다.
CMUX는 이런 문제를 해결하려는 오픈소스 터미널/워크스페이스처럼 보였다.
단순한 터미널이라기보다, 여러 코딩 에이전트의 작업 상태를 관리하는 컨트롤 센터에 가까웠다.
이 부분에서 느낀 건, AI 에이전트 시대의 개발 환경은 단순히 “더 좋은 IDE”가 아니라는 점이다.
앞으로 중요한 건 코드를 직접 치는 화면보다, 여러 에이전트가 어떤 일을 하고 있는지 보고, 작업을 배분하고, 상태를 확인하고, 필요할 때 개입하는 운영 UI일 수 있다.
즉, 개발자는 점점 더 “코드를 쓰는 사람”에서 에이전트가 일하는 환경을 설계하고 감독하는 사람에 가까워지고 있다.
PMF 루프의 변경
OMX, OMC의 Bellman님 발표에서 인상 깊었던 건, AI 제품은 PMF에 도달하는 순서가 바뀌었다는 관점이었다.
예전에는 제품을 만들고, PMF를 찾고, 고객을 락인시키는 흐름이었다면, 이제는 일단 만들고 바이럴시키고, 거기서 나온 반응을 빠르게 제품에 반영하면서 PMF에 가까워진다는 것이다.
특히 AI 제품은 텍스트와 자연어 인터페이스 중심이라 기존 제품처럼 락인이 강하게 걸리기 어렵다.
그래서 중요한 건 완성도 높은 제품을 조용히 만드는 것보다 빠르게 반응을 만들고 그 반응을 다시 개발로 연결하는 루프다.
이때 핵심은 구현량이 아니라 이터레이션 속도다. 바이브 코딩으로 프로젝트를 많이 만드는 것 자체는 큰 의미가 없다.
중요한 건 사람들이 남긴 반응을 이슈나 티켓으로 바꾸고, 실행 가능한 것은 바로 개발에 연결하고, 애매한 것은 걸러내는 구조다.
개발가재의 트리아지는 단순히 상태를 읽는 봇이 아니라, 무엇을 실행할지 판정하는 시스템에 가까웠다.
결국 에이전트가 오래 일하는 것보다 중요한 건 마케팅, 리서치, 개발 사이의 feedback closure time을 줄이는 것이다.
코딩 하네스가 자연어 컴파일러처럼 되어갈수록 진짜 차이는 코드를 얼마나 많이 짜느냐가 아니라 반응을 얼마나 빨리 제품 개선 루프로 연결하느냐가 중요할 것 같다.
메모리와 컨텍스트는 제품의 핵심 인프라가 된다
에이전트가 실제로 오래 일하려면 메모리와 컨텍스트도 중요해진다.
LLM은 긴 문맥을 처리할 수 있게 됐지만, 세션이 바뀌고 작업이 길어지면 여전히 맥락을 잃는다.
단순히 이전 대화 로그를 다 넣는다고 해결되는 문제도 아니다.
필요한 정보를 저장하고, 검색하고, 다시 꺼내 쓰는 구조가 필요하다.
이건 단순 기능이 아니라 에이전트 제품의 핵심 인프라에 가깝다.
결국 좋은 에이전트는 똑똑한 모델 하나로 완성되지 않는다.
작업 상태를 기억하고, 사용자의 선호를 반영하고, 과거 결과를 재사용하고, 현재 맥락에 맞게 판단할 수 있어야 한다. 이 지점은 개인적으로도 많이 공감됐다.
AI를 일상이나 개발 워크플로우에 진짜로 넣으려면, “이번 대화에서만 똑똑한 AI”로는 부족하다.
지속적으로 맥락을 이어가는 구조가 있어야 한다.
AI 시대의 일하는 방식OmOCon Seoul에서 가장 크게 남은 메시지는 이거였다.
AI를 잘 쓰는 팁보다, AI 시대의 일하는 방식을 배워야 한다.
프롬프트를 잘 쓰는 것도 중요하다.
좋은 툴을 아는 것도 중요하다.
하지만 그보다 더 중요한 건, AI와 함께 일하는 구조를 만드는 것이다.
작업을 작은 단위로 나누고, 컨텍스트를 잘 전달하고, 중간 결과를 검증하고, 실패를 전제로 루프를 만들고, 마지막 판단 지점을 설계하는 것.
이건 단순히 코딩에만 해당하는 이야기가 아니다.
리서치, 마케팅, 콘텐츠, 메시징, 업무 자동화, 심지어 일상생활에도 적용될 수 있다.
AI에게 손을 달아준다면,그 손이 아무거나 만지지 않게 해야 한다.
그리고 제대로 된 방향으로 움직이게 만드는 구조가 필요하다.
하네스 에이전트를 잘 쓰게 만드는 구조
가장 많이 생각하게 된 개념은 하네스였다.
하네스는 단순히 “AI 자동화 도구”가 아니다.
OmO 메인테이너인 연규님이 말씀하신 하네스는, AI가 실수할 수 있다는 전제 위에서 AI를 목적지까지 데려가는 운영 구조에 가깝다.
AI는 똑똑하지만 여전히 자주 빗나간다.
의도를 잘못 이해하기도 하고, 맥락을 잃기도 하고, 검증 없이 그럴듯한 결과를 내놓기도 한다.
그래서 중요한 건 “AI가 알아서 다 하게 만들자”가 아니다. 오히려 반대다.
AI가 어디서 실수할 수 있는지 예상하고, 그 실수를 감지하고, 필요하면 다시 시키고, 마지막에 사람이 판단해야 하는 지점을 남겨두는 것.
이게 하네스의 핵심처럼 느껴졌다.
발표 중에 나온 표현 중 인상적이었던 건, 하네스를 일종의 “에이전트들의 오은영”처럼 보는 관점이었다.
에이전트가 왜 지시를 못 들었는지, 어떤 맥락을 놓쳤는지, 어떻게 더 잘 일하게 만들 수 있는지를 관찰하고 교정하는 시스템이라는 뜻이다.
그 표현이 꽤 직관적이었다.
AI를 그냥 “딸깍” 하고 쓰는 게 아니라, 실제로는 AI가 잘 일하도록 환경을 설계하고 키워야 한다는 이야기였기 때문이다.
딸깍을 원하면, 오히려 딸깍이 안 된다
이번 행사에서 계속 떠올랐던 문장은 이거였다.
딸깍을 원하면, 역설적으로 딸깍을 못 한다.
AI 자동화에 대한 기대는 보통 이렇다.
버튼 하나 누르면 AI가 알아서 끝까지 해주는 것.
하지만 실제로 복잡한 일을 맡겨보면 그렇게 단순하지 않다.
작업 목표를 잘게 쪼개야 하고, 중간 결과를 검증해야 하고, 실패했을 때 다시 시도할 기준도 있어야 한다.
특히 코딩, 리서치, 오픈소스 기여, 제품 판단처럼 정답이 명확하지 않은 일에서는 더 그렇다.
결국 AI를 잘 쓰는 사람은 “마법의 프롬프트”를 아는 사람이 아니라 AI가 일할 수 있는 구조를 잘 만드는 사람에 가깝다.
작업을 어떻게 나눌지, 어떤 컨텍스트를 줄지, 어떤 결과물을 통과시킬지, 어디서 사람의 판단을 넣을지 이런 설계가 중요해진다.
파이프라인과 하네스는 분리되어야 한다
또 하나 기억에 남는 포인트는 파이프라인과 하네스를 분리해야 한다는 이야기였다.
파이프라인은 작업의 흐름이다.
예를 들면 이런 식이다. 기획 → 구현 → 테스트 → 리뷰 → 배포
반면 하네스는 각 단계에서 AI가 제대로 일하고 있는지 확인하고, 실패를 잡고, 품질을 유지하게 만드는 제어 구조다. 이 둘이 섞이면 위험해진다.
AI가 만든 코드를 AI가 만든 검증기로 검증하는 식의 자기참조가 생길 수 있기 때문이다.
겉으로는 자동화가 잘 돌아가는 것처럼 보이지만, 실제로는 검증 공백이 생긴다.
그래서 중요한 건 자동화 자체가 아니라
어떤 단계는 AI에게 맡기고, 어떤 단계는 시스템이 검증하고, 어떤 단계는 사람이 판단할지 나누는 것이다.
특히 오픈소스 PR 자동화 사례가 이 관점을 잘 보여줬다.
많은 프로젝트에 PR이나 커밋을 만들 수는 있지만, 그게 곧바로 “완전 자동화”를 의미하지는 않는다.
마지막 판단은 여전히 사람이 해야 하고, 오픈소스 커뮤니티의 맥락과 예의도 고려해야 한다.
속도를 높이는 것과 무책임하게 밀어붙이는 것은 다르다.
마무리
OmOCon Seoul은 “AI가 어디까지 발전했는가”를 보여주는 행사라기보다
AI를 실제 일에 넣기 위해 우리가 무엇을 설계해야 하는가를 생각하게 만드는 행사였다.
모델은 계속 좋아질 것이다.
에이전트도 점점 더 많은 일을 하게 될 것이다.
하지만 그래서 더 중요해지는 건 사람의 역할이다.
무엇을 맡길지 정하고, 어떻게 검증할지 설계하고, 어디까지 자동화할지 판단하는 역할
AI가 사람을 대체한다는 말은 너무 단순하다.
AI를 잘 쓰는 사람은, AI에게 일을 잘 시키는 시스템을 가진 사람이 된다.