라이브러리 탓을 하고 끝내는 사람인지, 영향도와 복구 동선까지 직접 잡아본 사람인지를 가른다. 기술 판단과 이해관계자 커뮤니케이션을 같은 호흡으로 다루는지 본다.
외부 라이브러리 버그 대응은 '우리 코드인지, 라이브러리 결함인지'를 먼저 가른다. 재현 최소 케이스를 만들어 경계를 명확히 한 다음, 사용자 피해가 크면 feature flag 차단이나 버전 pin/rollback으로 출혈부터 막는다. 그 뒤 업스트림 이슈·PR로 근본 수정 경로를 열고, 수정이 늦어지면 포크나 패치 패키지를 두되 제거 시점을 문서로 박아둔다. 기술 디버깅과 릴리즈 리스크 관리가 한 절차 안에서 같이 굴러가야 한다.
재현 최소 케이스를 만들어 '우리 코드가 아니다'를 증명했던 경험이 있다면, 어떤 가설을 어떤 순서로 깎아냈는지 분리 과정으로 풀어낼 수 있다
feature flag나 버전 pin으로 출혈을 먼저 막은 경험이 있다면, 사용자 영향과 롤백 비용을 어떻게 저울질했는지 의사결정 기준으로 연결할 수 있다
patch-package·포크·upstream PR 중 하나라도 직접 들고 가본 경험이 있다면, 단기/장기 대응을 같은 타임라인 위에서 어떻게 배치했는지 설명할 수 있다
PM·CS·다른 팀에 상태를 공유하며 사고를 관리했던 경험이 있다면, 같은 사고를 두 번 터뜨리지 않기 위한 커뮤니케이션 루틴으로 일반화할 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.