llm-wiki/raw/official-docs/lock-shedlock-issue-899-non-scheduler-use.md

---
title: "ShedLock Issue #899 — Non-Scheduler (General-Purpose) Lock 사용 가능 여부: Maintainer 입장"
source_type: official-doc
url: https://github.com/lukas-krecan/ShedLock/issues/899
archive_url:
related_branches: [feature-distributed-lock-contract]
related_projects: [ca-skeleton-operational-contract]
tags: [official-doc, ca-skeleton, persistence, shedlock, distributed-lock]
created: 2026-06-12
---

# ShedLock Issue #899 — Non-Scheduler (General-Purpose) Lock 사용 가능 여부: Maintainer 입장

> Layer: `raw/` — 외부 자료(GitHub Issue — maintainer 발언 포함)의 **원문 발췌·출처 기록**.
> 검증된 요약은 `/ingest` 후 `wiki/concepts/`에 `source-summary-template` 형식으로 별도 작성. 원본은 raw에 영구 보관.

## Parent / 활용 branch (필수, 최소 1개+)

> 이 자료는 **혼자 존재하지 않는다.** 어느 branch의 구현 결정의 **근거**로서 보관됨.

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-distributed-lock-contract]] | ShedLock 을 scheduler 밖 general-purpose 분산 락으로 쓰는 것에 대한 maintainer (Lukas Krecan) 의 실제 입장 확인 — `distributedLockProvider` 후보에서 ShedLock 을 배제/허용할지의 근거 |

## 출처 / Source

- 원본 URL: https://github.com/lukas-krecan/ShedLock/issues/899
- 아카이브 URL: (미수집)
- 저자 / 조직: GitHub Issue — 개설: holgerstolzenberg / maintainer 발언: lukas-krecan (Lukas Krecan, ShedLock 원저자)
- 발행일: 2022-02-01 (issue 개설)
- 마지막 확인일: 2026-06-12

## 왜 저장했는지 / Why archived

ShedLock 을 `@Scheduled` 없이 일반 분산 락으로 사용하는 것이 안전한지, maintainer 가 공식으로 지지하는지 여부를 판단하기 위해 수집. `distributedLockProvider` 구현체 후보 선정 시 ShedLock 의 적용 범위를 공식 발언 기준으로 확인하는 1차 근거.

## 핵심 인용 / Key quotes (verbatim, 3~5문장)

> [Comment — lukas-krecan] "I do not want to ofically declare that it's possible to use it as a generic \"lock\"... Moreover, I do not know how to call it. It's not a lock. If it's not available, the process does not wait but just skips the execution."

> [Comment — lukas-krecan] "The workaround with the pseudoanotation is a grat idea. I have to think about it."

> [Comment — Aloren] "JFYI We are using shedlock in production without @Scheduled annotation, because we have dynamic jobs. Works amazing."

> [Issue body — holgerstolzenberg] "I know that ShedLock is primarily designed for scheduler based stuff, but I gave it a shot and tried to use it as a 'regular' distributed lock."

## Claims Extracted / 추출된 주장

> 이 자료가 **직접 말하는 것만** claim 으로 분리한다.
> Claim ID prefix: `SHEDLOCK-899-`

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| SHEDLOCK-899-C1 | Maintainer 는 ShedLock 을 generic lock 으로 공식 선언하기를 거부함 | [Comment — lukas-krecan] "I do not want to ofically declare that it's possible to use it as a generic \"lock\"" | `maintainer-statement` | ShedLock 라이브러리의 공식 지원 범위 판단 시 | ShedLock 이 기술적으로 작동하지 않는다는 것을 증명하지 않음; 공식 문서 변경 여부를 보장하지 않음 |
| SHEDLOCK-899-C2 | Maintainer 는 ShedLock 의 동작을 "lock 이 아니다 — 획득 실패 시 대기 없이 실행을 건너뜀"으로 정의함 | [Comment — lukas-krecan] "It's not a lock. If it's not available, the process does not wait but just skips the execution." | `maintainer-statement` | ShedLock 의 의미론적 동작 이해 시 (skip semantics vs blocking lock semantics) | 이 동작이 모든 ShedLock provider 구현에서 동일하다는 것을 보장하지 않음; 공식 표준이 아님 |
| SHEDLOCK-899-C3 | Maintainer 는 pseudo-annotation workaround 아이디어 자체를 긍정적으로 평가했으나, 공식 지원 결정을 유보함 | [Comment — lukas-krecan] "The workaround with the pseudoanotation is a grat idea. I have to think about it." | `maintainer-statement` | ShedLock non-scheduler 사용 패턴의 커뮤니티 workaround 평가 시 | 이 워크어라운드가 공식 지원으로 승격되었다는 것을 증명하지 않음 |
| SHEDLOCK-899-C4 | 커뮤니티(user: Aloren) 는 `@Scheduled` 없이 dynamic jobs 에 ShedLock 을 production 에서 사용 중임을 보고함 | [Comment — Aloren] "JFYI We are using shedlock in production without @Scheduled annotation, because we have dynamic jobs. Works amazing." | `needs-confirmation` | ShedLock non-scheduler 사용의 실 운영 가능성 참고 시 | 이 커뮤니티 사례가 공식 권고가 아님; 특정 환경·버전·use-case 에 한정될 수 있음 |

### Strength 참고

본 자료의 모든 Claim 은 `maintainer-statement` 또는 `needs-confirmation` 등급이다. GitHub issue comment 는 공식 벤더 문서(`official-vendor-doc`) 또는 RFC(`official-standard`) 수준의 출처가 아니며, maintainer 의 의도·입장을 나타내는 비공식 발언이다. 공식 문서 보강 없이 "공식 best practice"로 취급 금지.

## Usage Boundaries / 적용 경계

- 이 자료가 직접 증명하는 것:
  - `SHEDLOCK-899-C1`: Maintainer 가 ShedLock 을 generic lock 으로 **공식 선언하기를 원하지 않는다**는 입장
  - `SHEDLOCK-899-C2`: ShedLock 의 semantics 는 blocking lock 이 아니라 **skip semantics** ("획득 실패 시 실행 건너뜀") 임을 maintainer 가 명시
  - `SHEDLOCK-899-C3`: Pseudo-annotation workaround 는 maintainer 도 긍정적으로 평가했으나, 공식화 결정은 유보

- 이 자료가 증명하지 않는 것:
  - ShedLock 이 non-scheduler context 에서 기술적으로 **작동하지 않는다**는 것 (기술적 불가 주장 없음)
  - 이후 버전에서 공식 지원이 추가되었는지 여부 (2022년 issue; 최신 README/changelog 별도 확인 필요)
  - ShedLock 이 blocking lock semantics (대기 + 획득) 를 제공하지 않는다는 것을 공식 문서에서 보장

- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  - ca-tmpl `distributedLockProvider` 가 blocking semantics (lock 획득 실패 시 대기) 를 요구하는지 — skip semantics 로 충분한지 설계 레벨 확인 필요
  - ShedLock README 최신본에서 non-scheduler use 공식 입장 변화 여부 ([[raw/official-docs/lock-shedlock-readme]] 와 대조)
  - ShedLock 최신 버전의 `LockProvider` API 가 `distributedLockProvider` SPI 요구사항과 호환되는지

## 메모 / Notes

- C1+C2 는 ShedLock 을 general-purpose `distributedLockProvider` 구현체에서 **배제**하는 방향의 근거가 된다. 단, "공식 선언 거부" = "기술적으로 불가"가 아니므로 배제 결정의 최종 근거는 skip semantics(C2) 가 더 강함.
- C3 의 "workaround 긍정 평가 + 유보"는 모호하다. 이 모호함 자체가 claim 이며, 결정 시 이 모호성을 명시해야 함.
- C4 는 커뮤니티 testimonial 이므로 `needs-confirmation`; ca-tmpl 결정의 보조 참고용으로만 사용.
- "scheduler 전용 공식 입장"이라는 선행 요약은 C2 기준으로 부분적으로 지지되나, README 의 "it's just a lock" wording 과는 방향이 다소 다름 — [[raw/official-docs/lock-shedlock-readme]] 와 교차 확인 필요.

## Related / 관련

- 동일 프로젝트 공식 자료: [[raw/official-docs/lock-shedlock-readme]] — ShedLock README 공식 경계 선언
- 대안 구현체 공식 자료: [[raw/official-docs/lock-spring-integration-lock-registry]] — Spring Integration LockRegistry (blocking semantics 지원)
- 이 자료를 인용한 wiki 요약: (생성 전)