소유권 및 책임감: 개념부터 프로덕션까지 코드를 직접 소유합니다
Source: Dev.to
소유권이란 어떤 모습인가
소유권은 단순히 코드를 작성하는 것이 아닙니다. 아이디어가 떠오른 순간부터 프로덕션에서 퇴역할 때까지 그 코드를 책임지는 것입니다.
이는 다음을 의미합니다:
- 해결하고자 하는 문제를 이해한다
- 해결책을 설계한다
- 코드를 작성한다
- 테스트한다
- 배포한다
- 모니터링한다
- 문제가 발생하면 수정한다
- 시간이 지나면서 개선한다
코드를 작성하고 그것을 다른 사람이 처리하도록 벽 너머로 넘겨버린다면, 당신은 아무것도 소유하고 있는 것이 아니라 단순히 코딩만 하는 것입니다.
Source: …
두 시간 규칙
내가 자주 보는 패턴
개발자가 버그에 걸려 6시간을 바라보다가 오후 5시에 도움을 요청한다:
“이게 안 되는데, 좀 봐줄래요?”
6시간이 걸렸고, 소통은 전혀 없었다.
더 나은 접근법: 2시간 이상 막히면 바로 알리세요.
하지만 “고장났어요, 도와주세요”라고만 말하지 말고, 시도한 내용을 보여 주세요:
“이 인증 버그에 막혔어요. 제가 시도한 내용은:
- JWT 토큰 만료 확인 – 토큰은 유효함
- 서명 알고리즘 검증 – 우리 설정과 일치함
- Claude로 미들웨어 검토 – 별 문제 없음
- 로그는 여기:
[paste]
토큰‑리프레시 흐름에 문제가 있을 것 같은데, 다른 시각이 필요합니다.”
당신은 작업을 수행하고, 가능한 옵션을 모두 소진했으며, 시도한 내용을 문서화하고 가설을 세웠습니다. 이제 팀원이 실제로 도와줄 수 있고, 당신이 이미 해야 했던 과정을 다시 재현하는 데 시간을 낭비하지 않아도 됩니다.
도움을 요청하기 전에
먼저 사용할 수 있는 모든 것을 활용하세요:
- 문서 읽기
- AI 도구 사용 (Claude, ChatGPT, Gemini, Cursor)
- 정확히 무엇이 고장 났는지 보여주는 실패 테스트 작성
- 코드베이스에서 유사한 이슈 확인
- 오류 메시지를 구글링
위 모든 것을 시도했는데도 2시간이 지나도 여전히 막히면—완벽합니다. 도움을 요청하고 시도한 내용을 보여 주세요.
“도와줄 수 있나요?” — 맥락 없이 묻는 것은 소유권을 갖지 않는 것입니다. 다른 사람에게 문제를 떠맡기는 행위입니다.
프로덕션에서 문제가 발생했을 때
이곳에서 진정한 소유권이 드러납니다.
나쁜 소유권
“배포가 실패했습니다. 누군가 확인해야 합니다.”
좋은 소유권
“배포가 실패했습니다. 제가 책임집니다. 근본 원인: 테이블 크기를 고려하지 않아 데이터베이스 마이그레이션이 시간 초과되었습니다. 지금 롤백 중입니다.
해결 방안: 마이그레이션을 더 작은 배치로 나눕니다.
30분 안에 재배포할 준비가 될 것입니다.
다음 번에 이를 방지하는 방법은 다음과 같습니다…”
차이점을 확인하세요:
- 즉시 책임을 집니다
- 무엇이 잘못됐는지 설명합니다
- 해결 방안을 제시합니다
- 재발 방지 방법을 보여줍니다
- 일정(시간)을 제시합니다
그것이 소유권입니다.
성공을 위한 준비
기능을 배포할 때는 다음을 갖추어야 합니다:
모니터링
- 중요한 지표(지연 시간, 오류, 처리량)를 추적하는 메트릭
- 한눈에 시스템 상태를 보여주는 대시보드
- 실제 디버깅에 도움이 되는 로그
알림
- 배포 전에 설정
- 상황을 포함 – 단순히 “뭔가 고장났다”가 아니라
- 적절한 담당자에게 전달
문서화
- 이것은 어떻게 동작하나요?
- 어떤 문제가 발생할 수 있나요?
- 일반적인 문제를 어떻게 해결하나요?
- 누가 만들었으며, 어떻게 연락하나요?
기능이 새벽 3 시에 다운되고 다른 사람이 온콜이라면, 다음을 할 수 있어야 합니다:
- 알림을 보고 어떤 부분이 고장 났는지 이해한다
- 런북을 찾는다
- 문제를 해결하거나 연락 방법을 안다
만약 할 수 없다면, 배포를 끝내지 않은 것입니다.
배포가 실패한 경우
개발자 한 명이 결제 리팩터를 배포했습니다. 스테이징에서는 철저히 테스트했고 정상적으로 동작했으며, 금요일 오후에 프로덕션으로 푸시했습니다.
토요일 아침: 알림이 울리고, 결제 처리 속도가 현격히 느려졌으며, 사용자는 거래를 완료할 수 없었습니다.
“예전 개발자”라면 “스테이징에서는 잘 작동했어요”라고 말하고 다른 사람이 조사하기를 기다렸을 수도 있습니다.
그 대신:
- 즉시 착수
- 문제 파악: 프로덕션 수준의 데이터 양으로 테스트하지 않았음 확인
- 10분 만에 롤백
- 사후 보고서 작성
- 실제 문제 해결
- CI/CD 파이프라인에 부하 테스트 추가
- 월요일에 자신감을 가지고 재배포
그게 바로 소유권입니다. “내 머신에서는 잘 되는데”도, “주말엔 내 문제가 아니다”도 아닙니다. 단지: 내가 이 일을 책임진다, 내가 고치겠다, 그리고 이렇게 예방한다 라는 자세입니다.
Ownership Makes You Better
What surprised me: taking full ownership made me a better engineer faster.
Why? Because when you know you’re responsible for something in production, you:
- Think through edge cases
- Write better tests
- Set up proper monitoring
- Document your decisions
- Care about performance
- Plan for failure
You can’t just write code and move on. You have to think about the whole lifecycle. This makes you better at every part of engineering.
그걸 이해한 주니어 개발자
나는 팀에 첫 번째 중요한 기능을 맡은 주니어 개발자가 있었다. 그는 배포에 긴장이 되었지만, 모든 절차를 제대로 수행했다:
- 포괄적인 테스트 작성
- 모니터링 및 알림 설정
- 런북 작성
- 기능 플래그 뒤에서 배포
- 첫 한 시간 동안 메트릭 관찰
- 슬랙에 업데이트 게시
기능은 완벽하게 동작했다. 더 중요한 것은 그가 완전히 책임을 지고 있었다는 점이다. 두 주 뒤에 질문이 생겼을 때, 그는 그 기능이 어떻게 동작하는지, 왜 그렇게 구현했는지 정확히 알고 있었다.
이것이 바로 마인드셋이다: “코드를 좀 썼다”가 아니라 “이 기능을 내가 책임진다”.
작게 시작하기
지금 작업 중인 한 가지를 선택하세요. 배포하기 전에:
- 기본 모니터링 설정
- 가장 중요한 장애 유형에 대한 알림 하나 추가
- 간단한 런북 작성: “X가 고장 나면, 이렇게 하세요…”
이러한 작은 단계들을 수행하면, 더 큰 프로젝트로 확장되는 소유권 습관이 형성됩니다.
해결 방법
- 이유를 문서화하세요: “우리가 이렇게 만든 이유”
- 팀에 알리세요: “X를 배포합니다, 주의할 점은 다음과 같습니다”
이것이 소유권입니다.
이를 꾸준히 실천하면, 사람들은 당신의 작업을 더 신뢰하고, 당신은 더 빠르게 성장하며, 코드도 개선됩니다. 완벽해서가 아니라 전체를 책임지기 때문에—코드만이 아니라 전체를 소유하기 때문입니다.
실제 테스트
다음에 당신이 만든 무언가에 문제가 생기면, 첫 번째 반응을 지켜보세요.
- 그것이: “음, 내 환경에서는 작동했어요”?
- 아니면: “지금 바로 살펴볼게요”?
- 혹은: “누군가가 이걸 고쳐야 할 것 같아요”?
- 아니면: “제가 처리할게요, 여기 제 계획입니다”?
그 반응들 사이의 차이는 코드 작성자와 배포하는 엔지니어 사이의 차이입니다.
두 번째를 선택하세요—항상.
그게 바로 소유권입니다.
이 글은 핵심 리더십 원칙에 관한 14부 시리즈 중 2부입니다. 다음 주: 매일 배포하기 – 매일 진전을 이루는 것이 영웅적인 일시적 노력보다 왜 더 좋은지.
당신은 업무에서 소유권을 어떻게 실천하나요? 프로덕션 코드에 대한 완전한 책임을 지게 만든 요인은 무엇인가요?
Follow me on Twitter.
If you’d like to support my work, check my Patreon.
See more at my Linktree.
Photo by Miguel A. Amutio on Unsplash.