글 잘 읽었습니다! 쓰실 때의 감정이 글에서 느껴지는 것 같아서 순식간에 읽혔네요. 모든 부분에 대한 답을 하기엔 저도 많이 버거운 것 같아서 내용 중 몇 부분에 대한 제 생각을 적고 가려고 합니
글 잘 읽었습니다! 쓰실 때의 감정이 글에서 느껴지는 것 같아서 순식간에 읽혔네요. 모든 부분에 대한 답을 하기엔 저도 많이 버거운 것 같아서 내용 중 몇 부분에 대한 제 생각을 적고 가려고 합니다. 먼저 회사 구성원들은 아시다시피 모두 각자 영역의 도메인 지식을 가지고 있습니다. 예를 들어 금융권이라고 한다면 내가 IT에 대해 아는 만큼 상대방은 금융에 대해 아는 것 처럼요. 때문에 지금 내부 직원들을 마치 외주업체 쓰는 모양으로 굴러가는 구조를 바꾸려면 아주 큰 노력이 필요할 겁니다. 구체적으로는 안정성이라는 게 얼마나 중요하고 그 안정성에 기여하기 위한 CI/CD 와 같은 인프라작업과 운영에 대한 (아마 모니터링도 없을 것 같아서) 심각성 강조 등의 회의를 나서서 열고 설득해야 할 거에요. 그러려면 먼저 내가 이 회사에 기술적인 신뢰도가 있는 사람인가? 도 따져봐야합니다. 즉, 골치아픈 일이 많아요. 그래서 그 전에, 제가 궁금한 건 어떤 도메인의 회사인가? 입니다. 만약 IT기업이 아니라면 사실 저는 방도가 없다고 봅니다. 심지어는 IT기업일지라도 규모가 작다면 공통의 이해를 가져가기 힘든 상황에서 IT기업이 아니라고 까지 한다면 진짜 답이 없죠. 그러나 불만이 생겼고 나갈 준비를 할거라면 할 수 있는 건 해보고 나가야 맞다는 생각입니다. 저의 경우엔 더 이상 성장의 의지가 없는 개발자분들이 계신 곳에서 첫 직장을 시작했고, 저도 글쓴이분이 말씀하신 것처럼 '어떤어떤 개발자'를 꿈꾸며 열정이 불타오르던 때라 마찰이 생길 수 밖에 없었습니다. 저도 이런 저런 말을 듣고 상황을 보면서 "아 여긴 진짜 아니다" 했던 순간이 많은데, 결국 JPA와 Querydsl 등의 기술을 제안했고, 제안한 만큼 보여주기 위해 퇴근 후에 매일 같이 카페에서 공부했습니다. 세션을 준비해서 참석해달라 부탁드리고 왜 필요한지, 그리고 어떻게 사용할 건지, 베스트 케이스는 있지만 우리 조직의 상황에 맞게 이런식으로 사용할거라던지, 등등의 발표를 2-3차례 진행했었습니다. 모든 개발자분들이 제가 원하는 만큼 100% 따라와주진 못하셨지만, 적어도 이 기술이 더 좋고 결국 해야한다는 것엔 공감해주셔서 기존의 Mybatis 로 작성된 레거시 기술들을 모두 제거하고 JPA 기반으로 전환하는 경험을 가져갈 수 있었어요. 비슷한 상황을 겪어본 사람의 이야기를 듣고 싶어하시는 것 같아서 말씀 드립니다! 그러나 결국 안될거에요. 실패할겁니다. 모든 사람을 움직이게 한다. 이게 진짜 어렵거든요. 그래서 결국은 이직 추천드립니다. 저도 레거시를 제거한 뒤 여기서 할 일은 마쳤다는 생각으로 이직을 했습니다. 그래도 위와 같은 사례를 말씀드린 건, 이직은 하되 할 수 있는 것을 해보고 떠나시라는 겁니다. 게다가 개발자로써 지내면서 인연이 꽤 질길 수 있습니다. 열심히 하는 사람, 동기부여를 해주는 동료, 등의 인상으로 남고 떠나는 게 뭐가 되었건 더 좋습니다. 마지막으로, 개인 공부에 대해 말씀해주셨는데 얼마든지 하세요. 회사가 공부할 시간을 챙겨줘야하냐? 라는 질문에는 찬반이 많이 갈릴겁니다. 그래도 저는 그래야 한다고 생각하는 입장입니다. 어차피 안챙겨줘도 알아서 할건데, 챙겨주면 더 좋아서 할거니까요. 내 성장이 곧 회사의 성장으로 이어지게 할 자신이 있으니까 챙겨주면 좋지요. 업무시간에라도 하세요. 눈치가 보인다면 신들린 알트탭을 선보이면서라도 하세요! 그러다가 누가 뭐라고 한다면 그 때 멈추면 됩니다. 아직 누가 뭐라고 하지도 않았는데 혹시나 뭐라고 할까봐 하고 싶은 걸 안하진 마세요. 전문용어로 '후뚜맞'이라고 하죠..ㅎ 어차피 나갈건데 그냥 하고싶은대로 쭉쭉 하시고 나가십시요! 대신, 내가 마음먹은 만큼 올바른 자세여야합니다. 이미 충분히 알고 계시겠지만 회사에서 막 나가란 얘기는 아닙니다:) 정말 깊은 고민하고 계신 것 같아서 도움을 드리고 싶은 마음에 썼으나 도움이 되셨을 지 모르겠네요. 계속해서 성취를 느끼는 개발자로 남아주세요!