최근 작업용으로 정리해 둔 메모 한 장을 다시 읽다 보니, 서로 다른 회사 이야기처럼 보이는 두 덩어리가 사실 같은 방향 화살표를 가리키고 있었습니다. 하나는 검색과 앱을 묶는 쪽의 ‘자율형 에이전트 환경’, 다른 하나는 모델 인프라와 개발 도구를 잇는 ‘수직 통합’입니다.

특허 조사와 명세서 작성에 AI를 붙이는 건, 이제 "실험"이라기보다 현업의 기본 옵션에 가깝습니다. 동시에 클라우드 범용 도구에 미공개 발명을 넣었다가 신규성 논의까지 번지는 사고, 발명자 인정과 프롬프트 설계가 얽힌 분쟁은 날로 구체화되고 있죠.

상편(2026년 3월 30일자)에서는 AI 코딩 시장이 범용 완성에서 생태계·런타임 특화로 기우는 세 가지 이유—락인, 하이브리드 과금, MCP 이후의 오케스트레이션—을 짚었습니다. 하편에서는 그 위에 올라탄 네 가지 대표 플랫폼을 실무·아키텍처 관점에서 나란히 놓고, 마지막으로 조직과 보안, 노동 시장까지 연결해 보겠습니다.

특허·상표 실무를 하면서도, 저는 매일 에디터와 AI 도구에 의존해 워크스페이스와 MCP를 붙잡고 있습니다. 그래서 “지금 쓰는 도구가 2년 뒤에도 같은 이유로 쓰일까?”를 자주 떠올립니다. 이번 글은 제가 참고용으로 정리해 둔 글로벌 AI 코딩 시장 조사 노트를 바탕으로, 2026년 전후로 논의되는 흐름을 디지털 아키텍처 관점에서 풀어 쓴 2부작의 상편입니다.

디지털 아키텍처를 설계하다 보면, 설계도보다 먼저 쌓이는 게 있습니다. 바로 삽질 로그입니다.

지난 포스팅에서 MCP(Model Context Protocol)가 AI 통합의 USB-C 같은 역할을 한다고 했습니다. 이론은 알겠는데, 막상 Google Antigravity에서 Gmail·캘린더·구글 드라이브를 MCP로 붙이려 하니 “어디서부터 손대야 하지?”부터 시작해서, 토큰 만료·경로 하드코딩·테스트 사용자 누락까지, 누가 알려주지 않아서 나 혼자 낑낑 대던 기억이 가물가물 떠오릅니다.

지난 포스팅에서 MCP(Model Context Protocol)의 이론과 아키텍처를 다뤘다면, 오늘은 실제로 Notion을 Cursor IDE에 연결하여 사용하는 실전 과정을 공유하려 합니다.

지난 포스팅에서 Cursor의 시스템 프롬프트 구축 전략을 다뤘다면, 오늘은 그보다 한 단계 더 나아간 이야기를 하려 합니다. 바로 MCP(Model Context Protocol)입니다.

지난 포스팅에서 AI와의 협업 경험을 다뤘다면, 오늘은 그 협업의 효율을 극대화하는 구체적인 기술적 방법론에 대해 이야기하려 합니다. 바로 Cursor 에디터의 ‘시스템 프롬프트(System Prompt)’와 .cursorrules를 활용한 개발 환경 최적화입니다.

개발자로서 AI 코딩 도구(Cursor, Copilot, ChatGPT 등)는 이제 선택이 아닌 필수가 되었습니다. 생산성은 비약적으로 상승했지만, 지식재산(IP) 전문가의 관점에서 볼 때 이면에는 ‘보이지 않는 법적 리스크’가 도사리고 있습니다. 바로 AI가 생성한 코드의 저작권 귀속 문제와 오픈소스 라이선스 오염(Contamination) 가능성입니다.

든든한 지원군, Cursor와 제미나이 CLI

팩스 한 장에서 시작된 나비효과

“로컬(내 컴퓨터)에서는 완벽하게 돌아갔단 말이야!” 개발자라면 누구나 한 번쯤 겪어봤을 악몽입니다. 밤새워 코드를 짜고 서버에 올렸는데, 갑자기 에러가 터지고 사이트가 먹통이 되는 그 순간. 식은땀이 흐르죠.

“AI가 생각보다 똑똑하지 않던데요? 엉뚱한 답만 내놓고요.”

“구글 신(God)의 시대가 저물고 있습니다.”

“기억하지 마세요, 기록하세요.”

“블로그 하나 만드는데 왜 이렇게 복잡하게 해?”

“아직도 코드를 직접 짜세요?”

“AI가 밥 먹여주냐고요? 네, 이제는 떠먹여 주기까지 합니다.”

“나 혼자 일하지만, 혼자가 아닙니다.”

“사무장님, 혹시 개발자 출신이세요?”

“문서 작성이 코딩보다 어렵다면?”

“클릭질은 그만, 이제는 타이핑이다”

“이 녀석, 보통 물건이 아니네?”

AI 대항해 시대, 늦깍이 탐험가의 출항

2000년대 웹에이전시 사장님, AI를 만나다