오늘 한 개발자가 본인이 커밋한 것 때문에 오류가 발생한다고 revert를 하라고 했더니 본인이 생각하기에는 자기 커밋한 것이 오류의 원인이 아닌 거 같다면서 PM도 부르고 백엔드도 불러서 오류를 찾겠다고 들쑤시게 다니더랍니다. 그래서 제가 그 개발자가 한 부분만 revert해서 파이프라인을 돌려보니 해당 오류가 사라졌죠.

그래서 해당 원인이 아무래도 니 pr인거 같다고 이야기했더니 끝까지 본인 Pr 문제가 아닌 거 같다며 원인 불명이긴 하나 production에 영향을 줄 수 있으니 revert 하겠다고…

와 이거 때문에 하루종일 pm, backend, qa까지 다 모여서 이러쿵 저러쿵 떠든 거 생각하면 참 짜증이 나더라고요.
보통 이런 경우에 어떻게 해야 하나요? 본인만의 좋은 방법이 있으신가요?

저는 개발자는 아니라 그냥 Manufacturing 쪽에서 일하는 Engineer입니다.
하여 말씀하신 내용과 다를수는 있음을 미리 알려드립니다.

우리나라는 단일민족이어서 묵시적인 이해들이 서로 매우 빠릅니다.
딱 보면 누구 잘못인지 아는거죠, 그리고 그런 훈련을 체계적으로 배우지
않았어도 잘 해냅니다 (이건 전적인 저의 의견입니다).

그러나 여기 미국은 수백의 인종이 한데 어우러져 사는 동네입니다.
Requirement를 내주어도 그것을 재현해 내는 방법들이 천차 만별 인 경우가 허다합니다.

그리고 잘못한 부분 속에서도 잘된부분만 가지고 홍보하는 경우도 있습니다.
그래서 아주 가끔씩이긴 하지만 이런 경우가 생기면 먼저 팀웍을 해치지 않는 범위
내에서 일을 원만하게 처리해 놓고 넘어갑니다.

그러면 다음번에 그런일이 반대로 생길경우에 그 친구가 절 도와주기도 하더군요.

조금 저질스럽게 말씀드리자면 다 먹고 살자고 하는 일이니 만큼
서로 서로 양보하면서 함께 걸어가는게 더 중요하지 않을까 생각해봅니다.
(물론 저 개인의 생각이니 불편하셨다면 지우겠습니다)

동감.

만약에 root cause를 찾아서 제시할 수 있다면 그걸 보여주면 좋겠죠. 그런데 상대방의 코드가 잠재적 bug를 expose한 것일 수도 있습니다. 같이 일할 때는 누구 탓이다는 식으로 하기 보다는 언제나 common goal을 내세우며 best course of action을 도모하는 식으로 접근하는게 좋습니다. 즉, 누군가의 잘못에 촛점을 두는게 아니라, 문제가 해결된 상태에 효율적으로 도달하기 위해 같이 노력하는 개념인 것입니다.

그래도 고집스러운 사람도 있을 수 있겠죠. 같이 일하기 힘든 사람이지만, 그래도 그런 사람들이 defensive하게 나오지 않고 같이 일할 수 있도록 구슬리는 것도 지혜로운 기술입니다. 결국 나에게도 그게 편하거든요.

“내가 쓴 코드가 아무래도 그런 에러를 발생시킬 수 없다”는 태도로 버티는 것은 경험이 모자란 경우가 아닌가 합니다. 여러 사람들 불러다 놓고 결론이 그렇게 났으니, 앞으로는 좀 더 조심하지 않을까요? 다른 사람들에게도 별로 좋은 인상을 주지 못했을거고.

제대로된 엔지니어들은 보통 좀 병적이다 싶게 최악의 경우를 걱정합니다. 경험상 성공적 엔지니어링은 luck으로 절대로 나오지 않고, 생각지 못한 곳에서 발목을 잡는다는걸 잘 아니까요. 단번에 빌드에서 테스트까지 성공하면 반드시 심각한 문제가 있는 결과물이라고 의심하고요.

보통은 너 커밋 빼니까 오류가 안난다 정도로 블레임을 하기엔 조금 약합니다. 그럴 경우에는 그거 빼니까 정상으로 돌아오더라라는 팩트를 드라이하게 얘기하는게 낫고, 괜찮은 엔지니어라면 조금 더 확정적인 인과관계를 찾아내죠. 그런 경우에도 public humiliation이 될 수 있는 사안은 굉장히 조심하는 편입니다. 그런 상황이 반복되지 않는한 (그러면 다른 엔지니어들도 보통 알게 되죠), 굳이 개인의 잘잘못을 가리면 서로 피곤해집니다.

누군가 잘못에 대한 책임을 져야 하는 상황에서 님이 남의 잘못을 덮어쓸 필요는 없지만, 그런 게 아니라면 개인에 대한 비난 없이 팀 차원의 learning opportunity로 삼고 넘어가는게 좋습니다.

저도 미국 생활한지 별로 안 되어서요. 좋은 말씀 잘 새기겠습니다. 좀 더 어우러지는 마음가짐을 가지도록 해야 겠네요.

실수와 실력은 구분하는게 좋습니다. 앞선 분 말처럼 네것 빼니까 문제 없더라라는 식의 언급이 네것 넣으니까 문제가 발생하더라보다는 나은 표현일 수 도 있습니다. 또한 그 사람 코드가 문제가 있는게 아니라 다른 hidden bug를 건드리는 조건이 되기도 합니다. 가장 안 좋은 경우로는 코드 몇줄을 여기서 밑의 몇줄로 옮겼을 뿐인데 에러 나는 경우도 있습니다. 이건 바이너리 달라지면서 안 보였던 uninialized variable이 문제가 되기도 했습니다.
그 친구가 실력으로 문제가 없으면 앞선 분 조언처럼 같이 가는게 좋은 것 같습니다. 정말 실력이 부족한데 고집만 있는거라면 실수가 반복될 것이고 그럼 매니저는 금방 알아냅니다.

개발잡니다

올바른 대응은

무슨 커뮤니케이션이나 스펙상 미스한 부분이 있거나 프로세스에 갭이 있거나 예측 못 한 부분이 있나만 봐야 합니다.

저얼대로 니잘못 하면 안됩니다

역시 커뮤니케이션이 제일 어려운 거 같습니다. 근데 다음번에는 좀 더 나은 모습을 보이려고 노력해보겠습니다.

혹시 인도 개발자인가요 허허허

본인들이 약간 공격? 받는걸 병적으로 싫어하긴 하더라구요

본문같은 경우야 제경우가 아니라 모르겠지만 누가봐도 지잘못인데 아닌척 딴청부린다거나
그것만 고치면 1분이면 넘어갈 문제를 뭐 크게 일벌려서 목소리크게 ㅈㄹ하고 cc로 다 쳐걸고 헛소리 하고
아우 피곤합니다.. 뭔 애랑 일하는것도 아니고 각자 돈벌러 직장에 왔으면 일을해야지 저런것도 어르고 달래가며 일할때면 그냥 짜증이 아주

22222

사람들이 정확한 상황도 모르고 글쓴이 비난하네 여기저기 꼰대들 지적질이나 해대고
글쓴이를 나무라는 정신나간것들

떼깔만 좋은 속은 썩어빠진 미국물 쳐먹었다 이거지 뭐. 스포일드 된거지.

결국 위에 보고 해야하기 때문에 RCA는 해야겠죠. 서로 조심해야할거 같습니다. 내 질못 아니라고 버팅디가다 나중에 망신 당할수도 있고, 남 잘못 아닌데 계속 몰고 가다가 이상한 사람될수 있잖아요.

쓰레기 미국

용산에 가면 장모님 10 원 한장 손해준 적 없다고 잘못 인정 안하는 놈도 있음

해당 커밋으로 파이프라인이 막혔다면 당연 작성자가 고쳐야죠 아니면 테스트에 허점이 있다던지요. 같은 팀이라면 대화로 해결하긴 좀 난감하겠지만 그냥 테스트 데이터로 보여주고 딱 넘겨야죠. 커밋이 한 두개가 아니고 pipeline blocker 로 인해 다른 팀원들에 피해도 가고.

다른팀이면 그냥 sev2 티켓 날리던지 아님 pipeline owner가 그냥 revert 하기도 하지요 ㅎㅎ