결론적으로 얘기하면 개발 조직 내에서 지식 공유가 제대로 이뤄져야 한다는 내용입니다.
제가 경험한 대부분의 개발팀은 코드에 대해서 얘기하는 경우가 거의 없습니다. 단지 납기일 지켜라, 사고 내지 마라, 들여쓰기 잘 해라 정도일 것입니다. 개발자A와 개발자B가 인수인계를 할 때에도 코드단위로 인수인계하는 것이 아니라, 어느 화면이 어느 파일이다 정도만 알려주면 인수인계 끝입니다.
코드를 샅샅이 취조하는 때가 있기는 합니다. 항상 문제가 터지고 난 다음이죠. 그 소스를 짠 개발자는 마음이 천근 만근입니다. 잘못 짠 소스로 인한 손해가 몇 억이다. 이런 식이죠.
해당 소스는 전문가 그룹이 속속들이 파헤칩니다. 인민 재판에서 자아비판식으로 잘못을 저지른 것에 대해 참회를 하게 됩니다. 누가 시켜서 그런 것도 아닙니다. 자신이 손댄 프로그램에 에고(감정이입)처리가 된 것이죠. 내가 짠 프로그램이 오동작했으니 내가 잘못한거야 같은 의식이죠.
물론 좋은 팀장님을 만났다면 윗선에서 커버를 해줄 것입니다. 더 큰 피해가 가지 않도록 말이죠.
이렇게 사고가 나야 소스를 열어본다면 그 팀의 개발자들은 방어적이고, 소극적으로 변합니다. 그리고 다른 사람의 소스가 잘못되어도 함구하고 있습니다. 점점 애플리케이션은 미궁으로 빠져들어가겠죠.
악순환을 선순환으로 바꾸는 방법은 코드의 공유라고 생각합니다. 코드 리뷰, 짝프로그래밍, 메일링 등 수단과 방법을 가리지 말고 함께 일하는 팀원들끼리 코드는 공유되어야 합니다. 그래야 사전에 버그도 찾고, 개선된 코드도 생각해 볼 수 있고, 남이 짠 소스 있는 줄도 모르고 또 만드는 수고도 덜 수 있구요.
답답한 현실이기도 합니다. 사고 터지면 모두 조용히 모니터 보면서 "휴~ 내 업무영역이 아니네, 빨리 수습되어야 할텐데" 하는 식의 문화가 더 이상 아니면 좋겠습니다.
image from: http://www.jc119.go.kr/home/?doc=bbs/gnuboard.php&bo_table=s2_photo&page=17&wr_id=247
제가 경험한 대부분의 개발팀은 코드에 대해서 얘기하는 경우가 거의 없습니다. 단지 납기일 지켜라, 사고 내지 마라, 들여쓰기 잘 해라 정도일 것입니다. 개발자A와 개발자B가 인수인계를 할 때에도 코드단위로 인수인계하는 것이 아니라, 어느 화면이 어느 파일이다 정도만 알려주면 인수인계 끝입니다.
코드를 샅샅이 취조하는 때가 있기는 합니다. 항상 문제가 터지고 난 다음이죠. 그 소스를 짠 개발자는 마음이 천근 만근입니다. 잘못 짠 소스로 인한 손해가 몇 억이다. 이런 식이죠.
해당 소스는 전문가 그룹이 속속들이 파헤칩니다. 인민 재판에서 자아비판식으로 잘못을 저지른 것에 대해 참회를 하게 됩니다. 누가 시켜서 그런 것도 아닙니다. 자신이 손댄 프로그램에 에고(감정이입)처리가 된 것이죠. 내가 짠 프로그램이 오동작했으니 내가 잘못한거야 같은 의식이죠.
물론 좋은 팀장님을 만났다면 윗선에서 커버를 해줄 것입니다. 더 큰 피해가 가지 않도록 말이죠.
이렇게 사고가 나야 소스를 열어본다면 그 팀의 개발자들은 방어적이고, 소극적으로 변합니다. 그리고 다른 사람의 소스가 잘못되어도 함구하고 있습니다. 점점 애플리케이션은 미궁으로 빠져들어가겠죠.
악순환을 선순환으로 바꾸는 방법은 코드의 공유라고 생각합니다. 코드 리뷰, 짝프로그래밍, 메일링 등 수단과 방법을 가리지 말고 함께 일하는 팀원들끼리 코드는 공유되어야 합니다. 그래야 사전에 버그도 찾고, 개선된 코드도 생각해 볼 수 있고, 남이 짠 소스 있는 줄도 모르고 또 만드는 수고도 덜 수 있구요.
답답한 현실이기도 합니다. 사고 터지면 모두 조용히 모니터 보면서 "휴~ 내 업무영역이 아니네, 빨리 수습되어야 할텐데" 하는 식의 문화가 더 이상 아니면 좋겠습니다.
![초급자를 위해 준비한 인프런 [데브옵스 · 인프라] 강의](https://okdevtv.com/images/inflearn-react-api.webp)
