프로덕트 소식은 넘쳐나지만 대부분 이런 게 나왔대에서 끝납니다. 그래서 뭘 어떻게 하라고? 내 작업에 어떻게 써먹지? 거기까진 연결이 잘 안 되죠. 따라서 요즘 프로덕트 메이커는 바로 쓸 수 있는 것, 그 중에서도 주목해볼 만한 것을 엄선해서 매주 금요일에 전달드리려 합니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: Claude Code Routines - 노트북 닫아도 PR 리뷰하고 알림 분류하는 자동화 기능
참고할 것: BOJ(백준 온라인 저지) - 16년간 한국 개발자와 함께한 백준이 문을 닫습니다
적용해볼 것: AI로 만든 환자 관리 앱이 30분 만에 털린 이유

1. 써볼 것: 노트북 닫아도 PR 리뷰하고 알림 분류하는 자동화 기능

Claude Code에 Routines라는 기능이 추가됐습니다. 프롬프트, 레포지토리, 커넥터를 한 번 설정해두면 스케줄이나 GitHub 이벤트에 맞춰 자동으로 실행되는 기능인데요. Anthropic 클라우드에서 돌아가기 때문에 노트북을 닫아도 작업이 계속됩니다. 아직 research preview 단계이지만, Claude Code를 쓰는 개발자들 사이에서 관심을 받고 있습니다.

무슨 문제를 해결해 주나요?

코딩 에이전트는 지금까지 사람이 앉아서 지시하고 결과를 확인하는 방식이었습니다. Claude Code든 Cursor든, 내가 대화창에 뭔가를 입력해야 일이 시작되죠. PR이 올라올 때마다 리뷰를 시키려면 그때마다 직접 세션을 열어야 했고, 매일 아침 이슈를 정리하려면 매번 같은 프롬프트를 붙여넣어야 했습니다. Routines는 이 반복을 자동화하는 기능이죠. 한 번 설정해두면 정해진 시간에, 또는 특정 이벤트가 발생할 때 알아서 실행됩니다.

어떻게 쓰나요?

claude.ai/code/routines에서 만들 수 있고, Claude Code CLI에서 /schedule 명령어로도 생성할 수 있습니다. 설정할 때 필요한 건 세 가지입니다. 실행할 프롬프트, 작업할 GitHub 레포지토리, 그리고 트리거 조건입니다.

트리거는 세 종류를 지원합니다.

스케줄: 매시간, 매일, 평일, 매주 등 주기를 정할 수 있습니다. 커스텀 cron 표현식도 가능하고요. 최소 간격은 1시간입니다.
GitHub 이벤트: PR이 열리거나, 릴리스가 생성되거나 할 때 자동으로 실행됩니다. PR 작성자, 제목, 라벨, 드래프트 여부 등으로 필터링도 가능합니다.
API 호출: HTTP POST 요청으로 실행할 수 있어서, 모니터링 도구나 배포 파이프라인과 연결할 수 있습니다.

하나의 Routine에 트리거를 여러 개 붙일 수도 있습니다. 예를 들어 PR 리뷰 Routine을 만들어서, 새 PR이 열릴 때도 실행되고 매일 밤에도 실행되게 설정할 수 있죠. 실행 결과는 일반 Claude Code 세션처럼 열어볼 수 있습니다. 뭘 했는지 확인하고, 변경 사항을 리뷰하고, PR을 만들 수도 있고요.

공식 문서에서 제시하는 활용 예시를 보면, 어떤 작업에 쓸 수 있는지 감이 옵니다. 매일 밤 이슈 트래커를 읽고 라벨을 붙이고 담당자를 배정한 뒤 Slack으로 요약을 보내는 백로그 관리, 모니터링 알림이 오면 스택 트레이스를 분석하고 최근 커밋과 연결해서 수정 PR 초안을 만드는 알림 분류, 병합된 PR을 스캔해서 API가 바뀐 문서를 찾아내고 업데이트 PR을 여는 문서 관리 같은 것들입니다.

다만 Routines는 완전 자율 모드로 실행됩니다. 중간에 승인 프롬프트가 뜨지 않아요. 셸 명령어를 실행하고, 레포에 커밋된 스킬을 쓰고, 연결된 커넥터(Slack, Linear 등)를 통해 외부 서비스에도 접근합니다. 그래서 필요한 레포와 커넥터만 연결하는 게 중요합니다. 그리고 아직 research preview라서 동작 방식이나 한도가 바뀔 수 있습니다. Pro, Max, Team, Enterprise 플랜에서 쓸 수 있고, 계정당 일일 실행 횟수에 제한이 있습니다.

누구에게 좋을까요?
Claude Code를 이미 쓰고 있으면서, PR 리뷰나 이슈 정리 같은 반복 작업을 자동화하고 싶은 개발자
CI/CD 파이프라인에 AI 코드 리뷰나 배포 후 검증을 붙이고 싶은 팀
매일 아침 또는 매주 돌아오는 정형화된 코드 작업이 있는 사람

2. 참고할 것: 16년간 한국 개발자와 함께한 백준이 문을 닫습니다

BOJ(백준 온라인 저지)가 4월 28일자로 서비스를 종료합니다. 운영자 최백준 님이 직접 게시판에 올린 공지인데요. 한국 개발자 커뮤니티에서 즉시 화제가 됐습니다. 2010년부터 16년간 운영된 이 사이트는 3만 4천 개 이상의 프로그래밍 문제와 73개 언어 채점을 지원하며, 한국에서 알고리즘을 공부하는 사람이라면 거의 다 거쳐갔다고 보아도 무방한 곳입니다. 많은 개발자의 성장을 도운 BOJ가 이제는 추억 속의 사이트가 된다고 합니다.

BOJ가 어떤 곳이었나요?

한국 IT 업계에 있는 사람이라면 백준을 한 번쯤은 들어봤을 겁니다. 개발자가 아니더라도, 코딩 테스트를 준비하는 후배나 동료가 있다면 백준이라는 이름은 익숙하죠. 알고리즘 문제를 풀고 온라인으로 채점받는 사이트인데, 단순히 문제만 있는 건 아니었습니다. 단계별 학습, 문제집, 그룹, 대회, 게시판까지 알고리즘을 중심으로 한 학습 생태계가 만들어져 있었습니다.

solved.ac라는 서드파티 서비스가 문제 난이도와 사용자 티어를 매기면서 게이미피케이션 요소까지 더해졌고요. 백준 티어가 개발자들 사이에서 실력의 지표처럼 쓰이기도 했습니다. 한국 기업의 코딩 테스트 문화와 함께 성장한 플랫폼이라고 볼 수 있습니다.

무엇이 남고, 무엇이 사라지나요?

종료 공지에 따르면, 서비스 종료 시점에 문제 데이터, 제출 기록, 대회 정보는 보존됩니다. 나머지 데이터는 삭제될 예정이고요. 최백준 님은 완전히 사라지기보다는 문제만이라도 다시 볼 수 있는 형태로 돌아올 수 있도록 고민하고 있다고 밝혔습니다. 상황이 달라지면 서비스를 재개할 가능성도 열어두고 있다고요. 서비스 종료 전까지는 정상 이용이 가능하지만, 문제집이나 그룹 생성 같은 일부 기능은 제한될 수 있다고 합니다.

무엇을 얻어가야 하나요?

한 사람이 시작한 사이드 프로젝트가 16년간 업계 인프라 역할을 했다는 것 자체가 큰 의미가 있는 사례라고 생각합니다. 마지막까지 문제 데이터와 제출 기록은 보존하는 결정을 내린 부분에서, 운영자가 생각하는 핵심 가치를 엿볼 수 있을 것 같습니다.

종료 소식을 접한 커뮤니티 반응도 인상적이었는데요. 시대가 바뀌었고 코딩 테스트의 의미가 예전 같지 않다는 목소리가 꽤 있었습니다. AI 코딩 에이전트가 알고리즘 문제를 풀 수 있는 시대에, 알고리즘 문제 풀이 능력이 개발자 역량의 기준이 될 수 있느냐는 질문이죠. 반면에 코드가 무엇을 하는지 이해하는 기초 체력은 여전히 필요하다는 반론도 있었고요. 정답이 있는 논쟁은 아니지만, 이번 주 적용해볼 것에서 다루는 사례를 보면 이 질문이 왜 중요한지 조금 더 구체적으로 느껴질 겁니다.

3. 적용해볼 것: AI로 만든 환자 관리 앱이 30분 만에 털린 이유

스위스의 보안 엔지니어 Tobias Brunner가 3월 28일 블로그에 올린 글입니다. 자기가 직접 겪은 바이브 코딩 호러 스토리라는 제목인데요. 보안 커뮤니티에서 바이브 코딩의 실제 위험을 보여주는 사례로 공유되고 있습니다. AI 코딩 도구로 앱을 만드는 사람이 늘어나는 지금, 무엇이 빠지면 어떤 일이 벌어지는지를 보여주는 글입니다.

무슨 일이 벌어졌나요?

Tobias Brunner가 병원에 갔는데, 접수 담당자가 요즘 AI로 누구나 소프트웨어를 만들 수 있다는 영상을 봤다고 하면서 직접 환자 관리 시스템을 만들었다고 했다고 합니다. 기존에 쓰던 환자 데이터를 전부 가져와서 새 앱에 넣고, 인터넷에 배포하고, 진료 중 대화를 녹음해서 AI 서비스 두 곳으로 보내 자동 요약하는 기능까지 만들었다고요.

Brunner가 며칠 뒤 이 앱을 살펴봤더니, 30분 만에 전체 환자 데이터에 읽기·쓰기 권한을 확보할 수 있었다고 합니다. 모든 데이터가 암호화 없이 인터넷에 열려 있었던 거죠. 바로 담당자에게 알렸더니, 돌아온 답변은 AI가 자동 생성한 감사 메시지였다고 합니다. 기본 인증을 추가하고 접근 키를 교체했다는 내용이었는데, Brunner는 이 사람이 자기가 뭘 만들었는지 이해하지 못하고 있다고 봤습니다.

기술적으로 무엇이 빠져 있었나요?

Brunner가 설명하는 기술적 구조를 보면, 앱 전체가 HTML 파일 하나였다고 합니다. JavaScript, CSS, 모든 구조가 인라인으로 들어가 있는 단일 파일이었고요.

백엔드는 접근 제어가 전혀 설정되지 않은 관리형 데이터베이스 서비스를 썼다고 합니다. 행 수준 보안(row-level security)도 없었고요. 접근 제어 로직이라고 할 수 있는 건 클라이언트 측 JavaScript에만 있었는데, 이건 브라우저에서만 작동하는 거라 curl 명령어 한 줄이면 데이터에 바로 접근 가능한 상태였다고요.

음성 녹음 파일은 외부 AI API로 직접 전송되어 전사와 요약 처리가 됐고, 데이터는 미국 서버에 저장되어 있었는데 데이터 처리 계약(DPA) 없이 운영되고 있었다고 합니다. 환자에게 이런 데이터 처리에 대한 사전 고지도 없었고요. Brunner는 이 행위가 스위스 데이터 보호법(nDSG)과 직업상 비밀 유지 의무를 여러 조항에서 위반했을 가능성이 높다고 판단했습니다.

왜 이런 일이 생기는 건가요?

이 사례에서 빠진 건 코딩 능력이 아닙니다. AI 코딩 에이전트가 코드를 만들어주는 건 잘 했으니까요. 앱은 돌아갔고, 기능도 잘 작동했을 겁니다. 빠진 건 코드가 어떻게 작동하는지에 대한 이해였습니다. 클라이언트 측 접근 제어가 왜 보안이 아닌지, 데이터베이스에 접근 권한을 왜 설정해야 하는지, 환자 데이터를 외부 서비스로 보낼 때 어떤 법적 요건이 필요한지. 이런 판단은 AI 코딩 에이전트가 알아서 해주지 않습니다. 코드를 생성하는 것과 그 코드가 안전한지 판단하는 것은 완전히 다른 영역이죠.

Brunner 본인도 AI 코딩 에이전트를 쓴다고 밝혔습니다. 다만 자기는 코드를 읽을 수 있고, 소프트웨어 아키텍처를 이해하고 있기 때문에 쓸 수 있는 거라고요. 분위기에 취해서 만드는 것(vibing away)만으로는 안전한 결과가 나오지 않는다는 게 그의 결론입니다.

적용해볼 질문

내가 AI 코딩 도구로 만든 코드에서 접근 제어가 서버 측에 있는가, 클라이언트 측에만 있는가?
외부 API로 데이터를 보내고 있다면, 어떤 데이터가 어디로 가는지 파악하고 있는가?
AI가 만들어준 코드의 아키텍처를 내가 설명할 수 있는가?

실행해볼 수 있는 것

AI 코딩 에이전트로 만든 프로젝트가 있다면, 백엔드 접근 제어가 제대로 설정되어 있는지 확인해보기. 클라이언트 측 JavaScript에만 의존하고 있다면 서버 측 인증을 추가하기.
외부 API를 쓰고 있다면, 어떤 데이터가 어디로 전송되는지 한 번 정리해보기. 민감한 데이터가 포함되어 있다면 데이터 처리 계약이 필요한지 확인하기.
AI가 생성한 코드를 배포하기 전에, 최소한 보안 체크리스트 하나를 통과시키는 습관 만들기. 인증, 암호화, 접근 권한, 데이터 흐름

이 네 가지만 확인해도 이 사례 같은 사고는 막을 수 있습니다.

오늘 내용, 이렇게 적용해보세요

AI 에이전트에게 반복 작업을 맡기되, 맡기는 작업의 범위와 권한을 명확히 정해두기. Routines처럼 자동으로 돌아가는 작업일수록 어떤 레포에 접근하고 어떤 서비스에 연결되는지 꼭 확인하기.
AI가 만든 코드를 배포하기 전에, 보안 관점에서 한 번 훑어보는 습관 만들기. 인증이 서버 측에 있는지, 데이터가 어디로 가는지, 접근 권한이 적절한지. 이 세 가지만 확인해도 많은 사고를 막을 수 있습니다. (AI 시대에도 코드를 읽는 능력은 여전히 기반입니다. AI가 생성한 코드가 무엇을 하는지 설명할 수 없다면, 그건 아직 배포할 준비가 안 된 겁니다)

다음 주에도 여러분이 놓치지 말아야 할 프로덕트 메이커 소식을 정리해서 찾아뵙겠습니다. 요즘 프로덕트 메이커 콘텐츠가 도움이 되셨다면, 꼭 작가 알림 설정을 부탁드립니다. 콘텐츠 내용 중 잘못된 정보나 정정이 필요한 부분이 있다면 댓글로 알려주세요. 빠르게 수정하겠습니다. 다음 주에 또 만나요!