Backstage에서 플러그인을 지속 가능하게 개발하기

원문 보기 위키 갱신 2026.10.07

플러그인은 진공 상태에서 만들어지지 않아요. 보통 고객의 요구를 해결하기 위해 만들어지죠.

출처: 문서

본문

플러그인은 진공 상태에서 만들어지지 않아요. 보통 고객의 요구를 해결하기 위해 만들어지죠.

플러그인이 오래 살아남게 하려면 플러그인을 최신 상태로 유지하는 방법을 찾아야 해요.

사내 개발자 팀이 여러분의 고객이에요. 그들이 플러그인을 매일 사용할 사람들이고, 플러그인이 올바른 문제를 해결하고 있는지에 대한 최고의 진실 공급원이에요. 코드 한 줄을 쓰기 전에 그들과 이야기하는 시간을 들일 가치가 있어요.

먼저, 해결하려는 문제의 영향을 가장 많이 받는 팀이 어디인지 파악하세요. 클라우드 지출 플러그인을 만든다면 클라우드 인프라를 소유한 팀과 이야기하세요. 온콜 정보를 통합한다면 인시던트 대응 프로세스를 소유한 팀을 찾으세요. 그들이 주요 이해관계자예요.

그들과 만날 때 이런 것들을 잘 들어보세요.

불편 사항(Pain points): 어떤 수동 단계가 그들을 느리게 하나요? 여러 도구에 걸쳐 어떤 정보를 찾아다녀야 하나요?
빈도(Frequency): 이 문제를 얼마나 자주 겪나요? 일상적인 불편은 분기별 문제보다 투자가치가 커요.
우회 방법(Workarounds): 지금은 그 대신 뭘 하고 있나요? 기존 우회 방법은 최소 기능 솔루션이 무엇을 커버해야 하는지 드러내는 경우가 많아요.

플랫폼 팀, 엔지니어링 매니저, 팀 리드 같은 2차 이해관계자는 조직의 요구를 더 넓게 보여주고 팀 간 우선순위를 정하는 데 도움을 줘요. 플러그인이 출시된 뒤 도입을 이끌어 줄 챔피언 역할도 할 수 있어요.

이런 대화를 계속 이어가세요. 초기 버전을 출시한 뒤의 짧은 체크인이 앞서 벌이는 긴 요구사항 수집 세션보다 더 가치있을 때가 많아요. 이해관계자는 뭔가 동작하는 걸 본 뒤에 훨씬 더 분명한 피드백을 줘요.

많은 경우 첫 버전의 플러그인은 몇 가지 모서리를 자르게 돼요. 이건 좋은 신호예요. 초기 코드에 지나치게 집중하기보다 강력한 사용 사례를 전달하는 데 초점을 맞추고 있다는 뜻이니까요. 반응이 안 온다면 어차피 임시방편일 수도 있으니까요!

그렇다면 플러그인을 언제 반복할지 어떻게 정할까요?

가장 분명한 신호는 플러그인을 쓰는 팀의 피드백이에요. 앞서 파악한 이해관계자에게 돌아가 보세요. 그들이 정말로 플러그인을 쓰고 있나요? 예상치 못한 마찰을 겪고 있나요? 직접 대화와 사용 패턴은 초기 개발 때의 가정보다 훨씬 많은 것을 알려줘요.

반복을 촉발하는 흔한 몇 가지 신호가 있어요.

이해관계자 피드백이 빈틈을 드러낸 경우: 어떤 팀이 플러그인을 쓰지만 특정 한 가지 때문에 여전히 다른 도구로 전환하고 있어요. 그 빈틈이 다음 반복 대상이에요.
도입이 예상보다 낮은 경우: 팀이 안 쓰고 있다면 기능을 추가하기 전에 그 이유부터 찾아보세요. 문제는 종종 기능이 없어서가 아니라 발견 가능성, 누락된 맥락, 또는 워크플로 불일치예요.
기반 데이터나 서비스가 바뀐 경우: 외부 시스템은 진화해요. 플러그인이 다른 서비스의 데이터를 표시한다면, 그 소유 팀과의 연락망을 열어두어 예상 밖의 상황에 당황하지 않도록 하세요.
분석이 예상 밖의 패턴을 드러낸 경우: Backstage는 분석 이벤트를 기본 지원해요. 플러그인에 계측을 해뒀다면 사용 데이터로 플러그인의 어느 부분이 많이 쓰이고, 어느 부분이 무시되며, 사용자가 어디서 이탈하는지 드러낼 수 있어요. 트래픽은 많은데 방문 시간이 짧은 페이지는 사용자가 필요한 걸 찾지 못하고 있다는 신호일 수 있어요.

모든 피드백이 즉각적인 변경을 정당화하는 건 아니에요. 요청이 얼마나 넓게 적용되는지 저울질해 보세요. 한 팀의 요청이 다른 모든 사람에게 더해지는 복잡성을 정당화하지 못할 수도 있어요. 우선순위를 정할 때도 이해관계자가 최고의 안내자예요.

성공적인 플러그인이란 시간이 지나면서 계속 사용되고, 신뢰받고, 개선되는 플러그인이에요. 그런 건 우연히 일어나지 않아요. 그것에 의존하는 사람들과 계속 연결되어 있는 결과예요.

기본은 단순해요.

이해관계자 관계를 활발하게 유지하세요. 초기 대화를 일회성 이벤트로 취급하지 마세요. 새 버전을 출시한 뒤에도 정기적으로 체크인하세요. 플러그인을 쓰는 팀이 무엇이 잘되고 안 되는지 알아내는 가장 빠른 길이에요.
피드백이 우선순위를 이끌게 하세요. 기술적으로 가장 흥미로운 부분을 반복하고 싶은 유혹이 들 수 있어요. 대신 사용 패턴과 이해관계자 피드백이 로드맵을 이끌게 하세요.
플러그인을 계측하세요. 분석은 대화 사이에 신호를 줘요. 어떤 기능이 무시되거나 페이지 이탈이 높다면, 그 방향에 더 투자하기 전에 조사할 가치가 있어요.
프로젝트가 아니라 제품처럼 다루세요. 출시 후 금방 버려지는 플러그인은 사용자의 신뢰를 잃어요. 작고 규칙적인 개선만으로도 플러그인이 유지되고 의존할 만하다는 신호를 주죠.

이 모든 것에 걸친 공통 주제는 여러분의 개발자가 곧 고객이라는 거예요. 그 관계를 건강하게 유지하는 것이 플러그인을 개발자 포털의 핵심 부분으로 만드는 것과 조용히 우회당하는 것 사이를 가르는 열쇠예요.