1. 📌 코드 리뷰가 없다는 것의 의미

코드 리뷰가 없다는 것은 그 누구도 내 코드에 책임지지 않는다는 뜻일수도 있다고 생각했다.

❗ 그 순간의 깨달음

• 코드리뷰가 존재하지 않는 조직은 빠른 구현만을 미덕으로 여기는 경향이 있음
• 품질, 안정성은 논의조차 되지 않았음
• 코드에 대한 집단적 신뢰 구조가 부재

2. 🔥 장애에 대한 무감각한 대응

시스템보다 문제를 대하는 조직의 태도가 더 무서웠다.

• 충분하지 않은 회귀테스트 및 엣지 테스트 진행, 테스트 코드 미작성 → 애플리케이션 장애 발생
• 장애 후 팀의 회고 : "장애가 되는 부분을 어떻게 해결할지 보다는 서비스에서 빼는 방향으로 생각"

⚠ 조직의 대응 방식

• 근본 원인 분석 없음
• 재발 방지 대책 없음
• “장애에 대해서 해결방안을 제시하거나 생각하기보다는 제거한다”는 임시 방편만 남음

3. 🧱 변화에 둔감한 조직, 무력한 개인

“지금 잘 돌아가는데 왜 고치냐”는 말은 성장을 가로막는 가장 단단한 벽이었다.

• 언제 터질지 모르는 시한폭탄
• 레거시 코드를 리팩토링 하려는 자세가 안보임
• 새로운 기술 제안도 "우린 그거 안 써봤어 또는 두려움"
• 변화에 둔감한 조직에서 도전은 유난으로 취급됨

😞 자존감을 갉아먹는 환경

• 성장이 불가능한 토양 위에 서 있었음
• 이것은 건강한 책임감이 아닌 조직이 만든 가스라이팅

4. 🧭 오너십과 문제 중심 성장에 대한 생각

오너십은 열정과 책임을 요구한다기보다 문제 중심의 성장을 위해 시야를 넓혀주는 말이라고 생각한다.

• 업무를 ‘내 일’처럼 생각하고 주도적으로 접근하는 태도
• 단순한 ‘시키는 일’ 수행이 아니라 전체 맥락 속 역할을 이해하려는 자세

🧠 오너십을 기르는 방법

• 스스로 "왜 이 작업이 필요한가?"를 생각하고 정의해보기
• 전체 업무 흐름 속에서 내가 맡은 작업의 위치와 맥락 이해하기
• 작업을 진행하기 전/후로 사용자 입장에서 시나리오를 상상해보기
• 문제가 발생했을 때 기술적 수정에 그치지 않고 본질을 되짚어보기

5. ❓ '왜'를 묻는 습관

'왜?'라는 질문은 단순한 호기심이 아닌 업무 맥락을 더 깊게 이해하려는 시도다.

• 왜 이 기능이 필요한가?
• 왜 이 방식으로 구현해야 하는가?
• 왜 지금 이 시점에서 이 기능을 진행하는가?

⚠ '왜'를 묻지 않는 개발자의 특징

• 시킨 일만 수행
• 문서만 보고 구현
• 피드백 오면 고치고 끝
• 팀원들과 소통 없이 개인 단위로 개발

6. 🧩 기술보다 맥락을 먼저 이해하는 개발자

기술 중심 사고보다 문제 중심 사고가 우선이다.

• 문제 정의와 문제를 어떻게 해결할지 방법을 생각하면서 기술을 선택하는 자세가 필요함
• 기술 선택은 개인의 흥미나 유행이 아니라 문제를 해결하기 위한 맥락과 필요에 따른 결정이어야 한다.

7. 🌱 성장에 대한 관점

성장은 어느 날 갑자기 오지 않는다.

• 별것 아닌 듯 지나쳤던 요소 하나하나를 주의 깊게 바라보기 시작할 때
• 작은 의문과 고민들이 쌓여 진짜 성장으로 이어진다.

📝 한 줄 결론

좋은 개발자는 “비즈니스 문제를 정확히 인식하고 그 해결을 위한 코드를 고민하고 조직과 커뮤니케이션하며 함께 성장하는 사람”이다.