협업 업무에서 오는 스트레스 제가 민감한 것인가?

안녕하세요 행님들 다들 디버깅은 잘 되시나요?

요즘 느끼는 작업 중 느끼는 감정이 있는데 저의 생각과 행님들의 생각은 어떤지 궁금해서 글을 써봅니다

저는 개발한지 7년차 정도 됩니다.

물론 모두 장비 제어로만 업무를 시작했고 아직도 하고 있습니다
제가 짠 코드로 장비를 제어할때 느껴지는 그 느낌은 앱을 만들때 보다 홈페이지를 만들때 보다 좋아서 이 길을 계속해서 나아가고 있습니다

모든 행님들도 똑 같겟지만
회사에서 일을 하다 보면 협업을 무조건 적으로 하게 되지요

저는 여기가 3번 째 회사인데
그 전까지는 거의 혼자 일한 느낌이에요 담당 업체 딱딱 정해 지고 그업체 담당으로 장비 셋업, 유지보수, 고객대응을 진행했어요

그리고 신기하게 저의 사수라고 하시는 분들은 기본 15~20년차 정도의 최상급 장비제어 개발자 분들이였어요

그래서 운이 좋게 많은 걸 배울 수 있었습니다

근데 지금 회사에서 새로운 장비 플랫폼을 만들자 라고 해서 각각 모듈에 대한 설계를 하고 함께 공유하고 각자 정해진 모듈 프로그램을 만들었습니다

저 또한 프로그램을 만들때는 반드시 왜 이렇게 만들었고 프로세스는 왜 이렇게 흘러가는지 정확한 신념? 뭐라고 할까요 그냥 딱 저의 개념을 가지고 하나의 프로그램을 만드는 성격입니다

물론 저의 스승님들한테 그런씩으로 배워서 몸에 배인 상태입니다

근데 통합 하는 사람한테 해당 코드를 설명하고 넘겼는데

음… 너무 많이 바꿨드라구요

이렇게 해야지 WPF 법칙?을 지키면서 할 수 있다고

저도 보고 그렇구나 했지만 제가 좋은 아이디어가 생각나서 업데이트를 할려고 해도
너무 많이 바꿔서 손을 대기가 참 힘드네요

분명 제가 만들었을때는 이유가 있고 개념을 확실히 가지고 만든 건데 만든 저도 뭐지 이건? 할 정도로 바꿔나서…(변수명, 폴더 위치 등) 제가 보기에는 많이 복잡 할 정도 바꿔나서…

솔직히 기분 나빴습니다

좀 물어보고 혹은 같이 생각하면서 하지

기분 나쁜 제가 이상한건가요? 제가 너무 쫌생이 인건가요?

그 통합한 사람은 저랑 비슷한 경력이에요 저보다 2년 정도 차이나요 밑으로

근데 하… 뭔가 막 제가 원래 만든 거에서 업그레이드 하고 싶어 수정하고 싶어도 음…저의 개념과 많이 다르다 보니 솔직히 코드를 열었는데 하기가 싫은거죠

내가 너무 쫌생이구나 하고 생각하면서 그사람이 만든 코드를 분석하면서 다시 작업하고 있는데

그냥 궁금해서 이렇게 글을 써봅니다

오늘도 구현하신거 빨간줄 적에 뜨시고 일찍 퇴근하세요

5개의 좋아요

전혀 이상하지 않습니다.

그래서 코드 리뷰 문화가 있는 것이겠죠. git을 쓰더라도 단순하게 하나의 Branch에서 Commit만 하는 게 아니라 Git 정책을 세워서 owner 기준으로 direct push를 못하게 막는 방법도 있고, 기본적으로 작업물에 대해 branch를 나눠 Pull Request 또는 Merge Request를 거쳐, 그 소스코드에 최전선에서 책임을 지시는 분이 꼭 reviewer로 지정되어야 하는 것입니다.

이것은 기분나쁜 것이 맞고, 그래서 협업을 위해 흔하게들 패턴이라고 불리우는 공용화된 지식을 기반으로 개발자들이 소통하는 것입니다.

마치 외국어를 대하듯 말을 못알아들을 수도 있기 때문이죠.

패턴이라는 것은 굳이 GoF 같은 전문적이고 완성된 디자인 패턴만을 의미하는 것은 아니며, 해당 업계에서, 또는 회사에서 사용되는 주된 방식을 의미하는 것입니다.

제가 과거에 흔하게 비유했던 것이 저도 공장에 2년 있어봤지만

sequence라는 개념을 통해 switch case에서 반복문을 통해 1초씩 값을 증가시켜, case에 해당하는 int값이 무엇을 의미하는 지도 모르는 채 반복문을 돌며 case로 들어가더군요. 저는 이걸 시퀸스 패턴이라며 친구들과 추억 팔이로 웃으며 회상했었습니다.

시퀸스 패턴이라고, 구조적이고 Modernization 되지 않은 방법론이라고 해도 그 업계에서 그렇게 그냥 쓰이고 있고 문제가 없다면 그냥 쓰는 것이 사람과 사람간의 소통비용을 줄일 수 있는 가장 큰 비용절약 입니다. 때문에 공용화 된 지식들이 업계에 충분히 녹아들지 않은 상태에서 학교나 커뮤니티에서 배운 최신 기술, 멋진 구조들을 가져다가 업계에 적용하면 이단아가 되는 것이겠죠.

회사는 연구개발을 하는 곳이 아니라는 소리는 이런데서 발생하는 것인 듯 합니다.

추가로, 아마도 학생들이 아마 괴리를 느끼는 것이 바로 이런 부분이 아닐까합니다. 학교에선 취업을 위해 최신기술을 가르치지만, 회사는 비즈니스를 하는 곳이지 최신기술을 도입하는 곳은 아니기 때문이죠. 다른 도메인에서 넘어오신 분들도 마찬가지일 겁니다. 본인의 도메인에서 쓰던 용어와 기술을 경력으로 인정받아서 취업해서 적용했을 뿐인데 회사에선 쓰지 마라고 하면 이해가 안 될 것입니다.

더 좋은 방법론, 더 좋은 기술을 위해선 경영진을 포함한 회사 구성원 모두의 끊임없는 노력이 필요한데 사실 회사는 비즈니스로 이윤만 남는다면 그것을 하지 않아도 되고 안 한다고 욕 먹을 것도 아닙니다.

하지만 질문자님처럼 이런 케이스가 하나씩 생길 때마다 하나씩 기술에 대한 접근이 트리거가 되어 문제의식이 발화되어 좋은 바람으로 될 수는 있다고 생각이 드네요.

3개의 좋아요

코드 리뷰의 경우는 예외지만, 협업의 일방이 상대방의 모듈을 건든다는 것은 협업의 방식이 잘 못 설정된 듯 보입니다.

6개의 좋아요

기술 발전을 위한 내부 토론이나 코드 리뷰는 바람직하나 납품용 장비의 코드를 협의 없이 독단적으로 수정하는 행위는 심각한 문제를 초래할 수 있습니다. 특히 생산 장비의 경우에는 매우 위험한 행위입니다.
회사 내부의 문제이고 직접 본 것이 아니라 전후 사정은 모르겠지만 이러한 문제는 책임자 급에 보고하여 업무를 명확히 하셔야 합니다.

5개의 좋아요

올려주신 고민에 대해서 드는 생각을 조금 냉정하게 말씀드리자면…

지금 상황을 보면 누가 코드를 잘 짰느냐, 누가 많이 바꿨느냐의 문제가 아닌 것 같습니다.

@BigSquare 님 의견에 전적으로 동의합니다.
애초에 협업 체계(역할, 책임, 약속) 없이 프로젝트를 시작한 게 근본적인 문제로 보입니다.

이 부분이 가관인데요, 7년 차 개발자라면 협업을 하면서 공통된 아키텍처 설계, 폴더 구조, 코딩 규칙 등의 공유 없이 작업을 시작하는 게 얼마나 위험한지, 어떤 문제가 생기는지는 협업 경험이 없더라도 어느 정도는 예측할 수 있었어야 한다고 생각합니다.

그걸 미리 지적하고 체계를 만들라고 요구하지 않았고, 결과가 나왔을 때 감정적으로 반응한다면? 글쎄요…


한 가지 더, 글 전반에서 본인의 프라이드에 대해 강조하고 계신데요,

최근 올리신 글들을 보면 WPF를 도입하신 지 오래되지 않았고 MVVM 같은 패턴 적용에도 아직 익숙하지 않으신 것으로 보입니다. 그렇다면, 이해가 충분하지 않은 영역에서 자존심을 앞세우는 것이 과연 도움이 되는가 하는 생각이 듭니다.

새로운 기술을 다룰 때 중요한 건 프라이드보다 숙련도입니다. 본인의 개발 역량이 충분하다면, 낯선 기술 환경에서도 빠르게 학습하고 적응하며 팀을 이끌 수도 있었을 것입니다.
프라이드가 있다면, 새로운 기술 환경에서 먼저 실력으로 증명하고 팀에 기준을 제시하는 쪽이 더 건강한 접근일 것 같습니다.

표현이 다소 직설적으로 느껴졌다면 죄송합니다.
현실적인 관점에서 상황을 한 번 짚어보고자 답글을 남기게 됐습니다.

고민을 정리하시고 앞으로 방향을 잡아가는데 조금이나마 참고가 되었으면 합니다.

4개의 좋아요

으아 매우 냉철하게 핵심을 짚으셨다…

아프다…아프지만 (아프신분들 모두)
아픈만큼 나아 간다 라고 생각 하셨으면 합니다.

2개의 좋아요

제일 먼저 들었던 생각…
=> 문제가 생겼을 때 과연 누가 책임질 것인가?

" 내가 안했어요. 쟤가 했어요. "

1개의 좋아요