티스토리 뷰
본 포스팅은 함께자라기 책을 읽고 작성하였습니다.
자라기 파트에서 감명깊게 본 부분, 다시 찾아봐야 할 것 같은 부분들 위주로 정리하였습니다.
실수를 대하는 자세
책에서 소개하는 실수 문화에는 두 가지가 있습니다. 바로 실수 예방과 실수 관리 입니다.
실수 예방은 실수로 가는 경로를 차단하려고 합니다. 이 말을 실무에 대입하면, 수직적인 조직에서 상사가 부하직원에게 "이번에 실수하면 죽어!" 정도가 되겠습니다. 모든 실수를 예방하는 것은 불가능에 가까운 일입니다. 아무리 전문가라고해도 1시간에 평균 3~5개의 실수를 저지른다고 소개되어있습니다. (개인적인 궁금점인데 여기서 말하는 실수가 어떤 것일까요? 개발자로 따지면 실시간으로 오타냈다가 수정하는 것도 포함이 될까요? 전문가가 1시간에 3~5번 저지를 수 있는 실수의 정도가 어느 수준인지 갑자기 궁금해졌습니다.)
실수가 이렇게 많은데 제대로 굴러가는 이유는 조기에 발견하고 빠른 조치를 취하기 때문입니다. 이렇게 실수가 나쁜 결과로 이어지기 전에 일찍 발견하고 고치는 일을 실수 관리라고 합니다.
실수 예방 문화에서는 실수한 사람이 처벌을 받기 때문에 실수를 감추게 되고 문제가 생겼을 때 협력하려고 하지 않습니다. 이런 문화가 지속되면 실수로 인해 배울 수 없게 됩니다. 반면에, 실수 관리 문화에서는 실수가 나쁜 결과가 되기 전에 빨리 회복하도록 돕고, 어떤 실수를 어떻게 해결했는지 공유하면서 배우는 분위기가 형성됩니다.
요즘에는 트러블슈팅 문서를 따로 만들 정도로 실수 관리 문화가 잘 정착되고 있는 거 같습니다. 하지만 이렇게 "문서화 하자"라는 분위기가 형성되었더라도, 실수를 하고나면 부끄럽고 최대한 남들이 알기 전에 고치고싶어하는 마음은 여전히 남아있는 거 같습니다. 실수로 인해 피드백을 받고 그 결과가 더 나아지는 경험을 몇 번 하다보면 실수한 것을 부끄러워하는 게 아니라, 잘 고치고 해결한 것을 자랑스러워 할 수 있지 않을까 생각하게 되네요.
뛰어난 선생에 대한 미신
요즘 좋은 IT 회사일수록 뛰어난 강사를 섭외하거나, 유명한 강사의 인터넷 강의를 수강할 수 있게 하는 등 회사와 개인을 위한 투자를 아끼지 않습니다. 저도 이전 회사에서도, 현재 회사에서도 강의도 듣고, 컨설팅도 받아보았고, 항상은 아니더라도 대부분 만족스러웠던 경험이 있습니다.
하지만 흥미로운 연구결과가 있는데, 가르치는 교사(강사)의 지식 수준은 150개의 학업성취도에 영향을 미치는 요인 중 꼴지에서 15등 정도라고 합니다. 이 말을 다시 "지식이 많다고해서 꼭 좋은 선생님은 아니다" 또는 "지식이 많은 선생님에게 배웠다고 해서 내가 꼭 실력이 느는 것은 아니다"라고 해석할 수 있습니다.
의료계 전문가를 대상으로 조사한 것 중 수업을 마친 이후 얼마나 빠트린 것이 있는지 질문했을 때 70% 정도는 빠트린다는 연구 결과가 있습니다. 기술을 성공적으로 해내기 위해 30%만 가르쳐놓고 다 가르쳤다고 생각한다는 것이지요. 이렇게 가르치는 원인은 본인에게는 너무 반복적으로 하는 일들이 자동화를 거처 암묵화되기 때문입니다. 이러한 이유로, 전문가에게 배웠다고해도 잘 배웠다고 할 수는 없는 것입니다.
이런 현상을 극복하기 위해서는 메타인지를 높이는 노력이 필요합니다. 어떤 문제를 해결할 때 어떤 과정을 거치는지 생각하며 자신의 머릿속을 관찰하고, 질문하고, 분석하는 과정이 필요합니다. 제가 어떤 업무를 하든 문서화시키면서 노력을 많이 하는 부분인데요, 이 글을 배경지식이 아무 것도 없는 사람이 보게 될지, 아니면 나보다 더 잘 아는 사람이 보게 될지 등을 판단하여 그 사람입장에서 제게 질문하는 방식으로 글을 적습니다. (블로그 역시 그렇게 해야하는데 숙제하듯이 쓰는 경우가 많아 그러지 못하네요.. 반성하고 고쳐야겠습니다.) 인지적 작업 분석에 능숙한 경우, 배우는 사람의 성취도가 가르치는 교사의 지식수준이 끼치는 영향력보다 약 15배 더 높다고 나와있습니다.
제가 배워야하는 입장이고 같이 일할 사수를 고를 수 있다면 이런 부분에 유리한 쪽을 선택하는 것이 성장에 도움이 되겠죠?
전문가의 사회성
예전 회사에서 JPA를 도입하기 위해 1주일동안 하루 2시간씩 팀장님을 설득한 적이 있었습니다. 전 그 당시 실무경력으로는 4년차밖에 되지 않았고, 팀장님은 언어는 다르지만 이미 10년이 훌쩍 넘는 경력을 가지고 있었습니다. 처음으르 자바 백엔드 서버를 구축하는 회사였고, 전 이직해온지 얼마 안 됐지만 회사 전체에서 자바 경력은 가장 많은 쪽에 속했습니다.
그 때 저는 객체지향 언어의 특징과 ORM을 사용해야하는 이유들을 들먹여가며 JPA 도입을 주장하였습니다. 하지만 결과는 JdbcTemplate + MyBatis 조합으로 개발하게 되었습니다. (나름 MyBatis를 도입한 것만으로도 만족했어야 하나 싶기도 하고..)
이 회사에서는 제가 해당 분야의 가장 전문가였습니다. 하지만 제가 하는 설득은 통하지 끝내 않았고, 결과물은 DB에 엄청나게 의존하는, 쿼리 하나가 2~300줄 가까이 되는 게 비일비재한 소스 코드가 되어버렸습니다.
아무리 JPA가 좋고, DB와 비즈니스로직을 분리해야한다는 것이 좋다는 걸 알아도 회사에 전파하는 데는 실패하였습니다. 이것과 관련된 문제를 책에서 다루고 있습니다.
아무리 기술적인 실천법이라해도 사회적 맥락 안에서 실천되어야하며 기술의 성공을 위해서는 사회적 자본과 기술이 함께 필요하다라고 설명하고 있는데, 현실에서는 팀원이 마음에 안 들거나, 혹은 그들이 나를 마음에 들어하지 않는 사회적 맥락이 나쁜 상황의 경우 기술적 측면에만 매몰되고 이는 실패로 이어진다고 합니다.
저의 경우 회사에서 그렇게 나쁜(?) 포지션은 아니었습니다. 오히려 반대로 그 당시 팀장님을 좋아하는 사람이 거의(또는 아예) 없었죠. 제가 봤을 땐 옛날 개발자 특유의 고집같은 것이 있었고, 쿼리로 뭐든 해결하려는 자세 자체가 시간이 지나도 고쳐지지 않았으며, 심지어 쿼리로 뭐든 해내는 것에 자부심을 가지고 있는 분이었습니다. 일단 그 분을 설득하기가 어려워서 팀원들에게 이야기해보면, 공부하는 데 시간이 너무 오래 걸린다든지, 어차피(?) 사용 못하게 될 거 같다든지 등의 피드백이 돌아왔었습니다. 제가 전문가로서 더 인정받는 상황이고 모든 사람과 더 잘 지냈더라면 기술의 도입이 더 쉬웠을 것이라는 건 누가봐도 자명한 일입니다. 하지만 겨우 4년차 개발자였고, 이직한지 얼마 되지 않아 친한 사람도 없었으며, 심지어 회사 분위기가 매우 꼰대스럽고 사무실에는 항상 적막이 가득했었기 때문에 짧은 시간에 더 인정받기는 어려운 환경이었습니다.
책에서 엄청 재밌는 예시를 하나 들고있습니다. 신뢰가 깨져있는 맞벌이 부부가 있었는데, 하루는 남편이 일찍 퇴근해 싱크대에 그릇이 쌓여있는 것을 보고 설거지를 했습니다. 이 부부의 신뢰상태를 모르는 제3자가 봤을 때는 대부분 남편이 선의로 설거지를 했다고 판단합니다. 하지만 부인이 집에 돌아와서 남편에게 화를 내면서 이렇게 이야기합니다. "집안일을 제대로 안 한다고 항의하려는 거냐? 나보고 이렇게 좀 하라는 뜻이냐?" 이 예시에서 알 수 있는 것은 신뢰가 깨져있는 상태에서는 어떤 행동도 악의적으로 보인다는 것입니다.
저와 팀장님의 사이가 좋지 않았기 때문에 제가 객체지향과 ORM을 들먹였을 때 이렇게 생각했을 수도 있습니다. '나보고 저거 공부하라는 거야? 내가 못알아 듣는 다는 거야?' 반대로 비즈니스 로직이 복잡해서 쿼리가 복잡하다는 소리를 들었을 때 저도 마찬가지로 '쿼리만 복잡하게 잘 짜는 게 자랑이야? 설계를 잘못했다는 걸 죽어도 인정하기 싫은 거야?' 라고 생각했으니 말이죠.
그만큼 사회성이 중요하다고 할 수 있습니다. 뛰어난 개발자일수록 타인과 인터랙션에 더 많은 시간을 쓰며, 초보 개발자들에게 조언할 때 사회적인 측면이 포함된다는 연구 결과가 있습니다. 이 부분을 읽으면서 제가 뛰어난 개발자인지는 잘 모르겠지만 다른 개발자들과 인터랙션에 힘쓰고 주니어 개발자들에게 조언할 때도 커뮤니케이션을 엄청 강조하는 편인데 이게 다 빡쎈(?) 곳에서 일해온 게 자연스럽게 녹아든 것이 아닌가 싶었습니다.
뛰어난 개발자들은 약 70%가 동료와의 협업을 언급하고, 실력이 그저 그런 개발자들은 20%도 안 되는 사람들만 언급했다고 합니다. 이 정도 연구결과라면 면접 때 커뮤니케이션 경험만 이야기해도 충분하겠는걸요?😄
결론을 다시 정리하자면, 어떤 기술적인 지식을 전달한다 해도 사회적 맥락 속에서 가르치고 경험하게 하려고 노력하는 것이 중요하다는 것입니다. 기술적 요소 역시 병목현상을 가져올 수 있지만, 사회적 요소가 가져오는 병목현상이 훨씬 더 크기 때문입니다.
'Book > 함께 자라기' 카테고리의 다른 글
함께 자라기: 함께(2) (0) | 2022.07.24 |
---|---|
함께 자라기: 함께(1) (0) | 2022.07.21 |
함께 자라기: 자라기(2) (0) | 2022.07.18 |
함께 자라기: 자라기(1) (0) | 2022.07.17 |
함께자라기 (책 내용 전혀 없는) 초담백 후기 (0) | 2022.07.14 |
- Total
- Today
- Yesterday
- 스프링 부트
- leetcode
- r
- 함께 자라기 후기
- spring boot application
- 헥사고날 아키텍처
- 스프링 데이터 jpa
- Java
- gRPC
- JPA
- spring boot app
- QueryDSL
- 알고리즘
- 스프링 부트 회원 가입
- intellij
- 스프링부트
- 클린 아키텍처
- 스프링 부트 애플리케이션
- Spring Data JPA
- Linux
- Jackson
- 함께 자라기
- 스프링 부트 튜토리얼
- Spring Boot Tutorial
- Spring Boot
- JSON
- spring boot jwt
- @ManyToOne
- proto3
- Spring Boot JPA
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |