DeepSeek로 Feishu Base의 기존 레코드를 수정하려면 대상 테이블을 읽고 편집할 수 있는 연결 도구가 필요합니다. 주문 번호가 정확히 일치하는 레코드를 한 건 찾은 뒤 변경안을 검토하세요. 승인된 필드만 수정하고 같은 레코드를 다시 읽습니다. Tabbit Browser의 공개 사례는 브라우저를 이용해 CSV를 가져온 과정을 보여 줍니다.
Yingdao의 한 사용자는 상품 ID로 Feishu 레코드 ID를 찾은 뒤 필드 쓰기에서 오류가 발생했다고 보고했습니다. Yingdao 게시물
핵심 요점
업무 키가 대상 테이블에서 하나의
record_id와 일치해야 합니다.이전 값과 새 값, 필드 유형, 빈 셀 처리 규칙을 미리 확인합니다.
정기 작업에는 권한을 부여한 API를 우선합니다. 사람이 지켜보는 일회성 작업이라면 브라우저도 쓸 수 있습니다.
승인된 필드만 수정하고 같은 레코드에서 저장 값을 확인합니다.
요청 시간이 초과되면 먼저 현재 값을 읽고 재시도가 필요한지 판단합니다.
연결 방법 선택
| 방법 | 적합한 작업 | 먼저 확인할 사항 |
|---|---|---|
| Feishu API | 권한 있는 통합으로 반복하는 작업 | 대상 테이블을 검색하고 ID로 수정한 뒤 다시 읽을 수 있는지 확인 |
| 브라우저 | 사람이 감독하는 일회성 작업 | 로그인한 계정으로 편집하고 같은 레코드를 다시 열 수 있는지 확인 |
브라우저는 로그인한 계정의 권한을 사용합니다. API, MCP, 브라우저 비교와 기존 브라우저 세션에 연결하는 방법을 참고하세요.
1. 주문 번호로 정확히 한 건 찾기
대상 Base와 테이블, 검색 범위를 확인합니다. 00018처럼 앞에 0이 있는 주문 번호는 텍스트로 처리합니다. 결과의 모든 페이지를 확인하고 한 건만 일치하면 record_id를 기록하세요. 브라우저에서 ID를 볼 수 없다면 같은 상세 화면을 열 수 있는 고정 링크를 사용합니다. 행 번호는 정렬에 따라 바뀝니다. Feishu 레코드 검색
보기 필터나 고급 권한 때문에 일부 레코드가 숨겨질 수 있습니다. 일치하는 행이 없으면 조회 범위를 확인하세요. 예외를 추적할 수 있게 CSV 원본 행도 함께 기록합니다. Feishu Base FAQ · 원본을 추적할 수 있는 CSV 추출
2. 쓰기 전에 변경 내용 확인하기
가상의 예로 00018의 상태를 Pending에서 Reviewed로, 수량을 2에서 3으로 바꾼다고 가정해 봅시다. 미리보기에 테이블, 주문 번호, 레코드 ID와 변경 전후 값을 보여 줍니다. 같은 키에 대한 요청이 두 개면 동일한 요청은 합치고 값이 충돌하면 검토합니다.
Reviewed가 기존 단일 선택 옵션인지, 3이 숫자인지 확인합니다. 날짜는 단위와 시간대를 맞춰 비교합니다. 빈 셀은 기존 값 유지, 값 삭제, 입력 오류 가운데 무엇을 뜻하는지 미리 정하세요. Feishu API는 ID로 지정한 레코드에서 요청에 포함된 필드를 수정합니다. 과거 Lark CLI에서는 명령 옵션과 API 매개변수가 다르다는 보고가 있었습니다. 실제 연결 도구가 받는 옵션을 확인하세요. Feishu 레코드 업데이트 · Lark CLI 이슈
수정 직전에 이전 값을 다시 읽습니다. 미리보기를 만든 뒤 누군가 값을 바꿨다면 멈추세요. 다시 읽어도 조회와 쓰기가 하나의 원자적 작업이 되지는 않습니다. 첫 브라우저 작업 체크리스트를 참고해 한 건으로 범위를 좁힙니다.
Tabbit의 공개 사례는 CSV 가져오기였다
2026년 9월 3일에 녹화한 Tabbit 공개 사례에서 DeepSeek Harness는 DeepSeek V4 Flash High로 CSV를 Feishu Base에 가져왔습니다. 당시 실행 환경에서 처음 선택한 API를 사용할 수 없어 로그인된 Tabbit 세션과 페이지가 제공하는 구조화 도구를 썼습니다. 영상에 나온 가져오기 결과는 레코드 200개, 필드 26개이며 날짜를 정규화한 후 차이는 0건이었습니다.
기존 레코드를 수정하려면 현재 세션에서 검색, 편집, 결과 읽기가 가능한지 확인하세요. Harness 브라우저 플러그인 가이드와 브라우저 권한 가이드에서 각각 연결 방식과 권한을 다룹니다. DeepSeek Harness 공식 저장소 · Tabbit 공식 플러그인
3. 같은 레코드를 다시 읽고 재시도 판단하기
같은 ID나 상세 링크로 레코드를 다시 열고 업무 키와 정규화된 값이 승인된 미리보기와 일치하는지 확인합니다. 업무 키, ID, 변경한 필드와 검증 결과를 기록하세요. Feishu 레코드 조회 · 브라우저 자동화에서 결과 검증하기
| 확인 결과 | 처리 |
|---|---|
| 일치하는 행이 없거나 여러 개 | 건너뛰고 범위, 권한, 중복을 확인 |
| 한 건이 일치하고 이미 목표 값 | 검증 완료로 기록하고 쓰기 생략 |
| 한 건이 일치하고 이전 값이 그대로 | 승인된 필드를 수정한 후 다시 읽기 |
| 시간 초과, 읽기 실패, 예상과 다른 값 | 작업을 멈추고 같은 레코드를 다시 읽은 뒤 재시도 판단 |
예시의 00018이 이미 Reviewed와 3이면 종료합니다. 여전히 Pending과 2라면 먼저 이전 요청이 진행 중인지 확인하세요. 두 상태와 모두 다르면 다른 편집이 있었는지 살펴봅니다. 같은 쓰기를 반복하면 후속 자동화가 다시 실행될 수 있습니다.
브라우저 경로를 선택했다면 한 건을 읽기 전용으로 미리 확인하세요. 같은 레코드를 다시 열고 값을 읽을 수 있을 때 변경을 승인할지 판단합니다.
자주 묻는 질문
DeepSeek가 Feishu Base를 업데이트할 수 있나요?
대상 레코드를 찾고 편집하고 다시 읽을 수 있는 연결 도구가 있으면 가능합니다. Tabbit의 공개 사례는 CSV 가져오기입니다.
업무 키와 record_id는 같은가요?
주문 번호 같은 업무 키는 입력 데이터에 있고 record_id는 Feishu가 부여합니다. 업무 키가 한 건과 정확히 일치하는지 확인한 후 해당 ID를 사용하세요.
키가 없거나 중복되면 어떻게 하나요?
수정 전용 작업에서는 두 경우를 기록하고 건너뜁니다. 행을 만드는 작업에는 별도의 승인과 중복 검사가 필요합니다.
언제 API를 쓰나요?
권한 있는 연동으로 같은 작업을 반복할 때 사용합니다. 사람이 감독할 수 있고 페이지와 계정이 편집을 지원하면 브라우저도 사용할 수 있습니다.
중단된 쓰기는 어떻게 다시 시도하나요?
먼저 같은 레코드를 읽습니다. 정규화한 값이 일치하면 검증 완료로 기록합니다. 다르다면 다른 편집이 있었는지 확인한 후 다시 시도하세요.