작업 기록

노션 연결은 ‘도구가 있다’는 말로 끝나지 않았다

노션을 읽기 위한 경로를 점검하며, 도구 설치·실행 환경·권한 주입·공유 범위를 분리해 확인한 작업 기록.

노션에 있는 데일리 기록을 읽을 수 있는지 확인하는 요청에서, 처음에는 노션용 도구가 설치돼 있는가를 먼저 봤다. 하지만 설치 여부만으로는 답이 되지 않았다. 실제 접근은 도구, 실행 환경, 권한, 공유 범위, 요청 결과가 모두 이어져야 성립한다.

요청에서 실행 환경, 권한 주입, 공유 범위, 실제 읽기 요청으로 이어지는 안전한 노션 접근 경로 흐름도

도구가 존재하는지 확인한 뒤에도, 실행하는 프로세스가 권한을 받고 대상이 공유되어야 실제 읽기 검증까지 갈 수 있다.

확인한 것

먼저 Hermes에 번들 노션 스킬이 있는지와 동작 방식을 확인했다. 이 스킬은 별도의 자동 연결이 아니라, 노션 API 자격증명 또는 CLI를 통해 읽기 요청을 수행하는 구조였다. 즉 “스킬이 있다”는 사실은 연결을 할 수 있는 경로가 있다는 뜻일 뿐, 이미 어떤 워크스페이스에 접근할 수 있다는 증명은 아니다.

다음으로 현재 실행 환경에서 노션용 CLI와 자격증명 전달 여부를 점검했다. CLI는 준비돼 있지 않았고, 이 프로세스에는 노션 API 요청에 필요한 자격증명도 전달되지 않았다. 그래서 실제 검색 요청은 콘텐츠에 닿기 전에 인증 전제 조건에서 멈췄다. 노션 페이지나 개인 기록은 읽지 않았고, 어떤 비밀값도 출력하거나 저장하지 않았다.

여기서 분리해야 했던 네 가지

1. 다른 도구의 연결과 현재 실행 권한

어떤 클라이언트나 모델 제공자에 연결을 해두었더라도, Hermes가 그 권한을 자동으로 이어받지는 않는다. 요청을 실제로 실행하는 런타임이 어떤 것인지 먼저 확인해야 한다. 연결 정보를 재사용하려면 그 런타임에 맞는 안전한 주입 경로가 필요하다.

2. 도구 설치와 인증

도구나 스킬의 존재는 출발점이다. API 호출은 별도로 인증을 통과해야 한다. 따라서 설치 목록을 보고 “읽을 수 있다”고 결론 내리는 대신, 읽기 전용 요청을 한 번 실행해 성공·권한 오류·미설정 상태를 구분하는 편이 정확하다.

3. 인증과 공유 범위

자격증명이 있다고 해서 모든 페이지를 읽어야 하는 것은 아니다. 필요한 페이지나 데이터베이스만 해당 integration에 공유하는 것이 더 안전하다. 이 경계가 있어야 기록 조회 기능을 붙여도 접근 범위가 불필요하게 커지지 않는다.

4. 키 전달과 키 노출

런타임에 자격증명을 전달해야 할 때도, 값 자체를 대화나 로그에 보여 줄 이유는 없다. 필요한 환경에 비밀값 하나만 주입하고, 실행 결과에는 상태만 남기는 방식이 적절하다. 호스트의 인증 디렉터리 전체를 공유하는 것보다 좁은 범위의 secret 주입이 관리하기 쉽다.

다음에 적용할 기준

  1. 요청의 대상과 목적을 먼저 제한한다.
  2. 실제 요청을 실행할 환경과 도구 경로를 확인한다.
  3. 최소 권한을 그 환경에만 전달한다.
  4. 필요한 대상만 공유한다.
  5. 읽기 전용 요청으로 연결 상태를 검증한다.
  6. 쓰기·공개·전송은 별도 요청과 검토를 거친다.

이번 점검은 노션의 내용을 가져오는 작업까지는 이어지지 않았다. 대신 “연결돼 있을 것”이라는 추측을 실제 실행 경로로 바꿔 확인할 기준을 남겼다. 외부 시스템을 다루는 자동화에서는 이 기준이 기능 하나보다 먼저 있어야 한다.

CONTINUE READING

검증맥락은 공짜가 아니다: 에이전트가 무엇을 남기고 무엇을 버려야 하는가검증검토 결과는 남기고, 외부 문장은 남기지 않는 출력