6명 참석 - BE 5명, 디자인1명
네트워크를 주로 하고 계시는 백엔드 개발자분이 오셨어요.
백엔드 개발자가 네트워크 지식을 알고 배워야 할까요?
Q: 실무에서 접점이 없다보니, 크게 알아야 하는지 잘 모르겠어요.
A: 어떻게 쓰는지 정도만 하고 너무 깊게 알 필요는 없어요.
덧붙여서 간단하게 말하자면, 서브 마스크란 구역을 나누는거. 우편서비스를 예로 들자면, 다른 지역에 우편을 전달할때 주소 체계가 00도 00구 00동 00번지 00호 이렇게 나뉠텐데, IP 숫자도 그런 체계로 이루어져 있어요. 어느 영역까지 몇개를 쓰겠다. 예로 몇개의 250개의 동을 쓰겠다 라는 의미로 쓰이고 숫자가 더 붙혀지면 바이너리(binery)로 나가게 되요. 이걸 Longest Prefix Matching이라고 불리고, 한 단계로 더 가면 라우팅으로 됩니다.
후임관리의 기준이 있을까요?
A: 급한 업무 상황에서 후임에게 주는 업무는 리스크가 적은 것들 위주로 전달하고 후임에게 기회를 줘보는 건 어떻까요? 후임 이외에 같이 업무를 하는 사람들일 수 있고, 자신보다 윗사람들에게 “이거 한번 해보실래요?”하고 전달하는 것도 방법일 수 있어요. 나중에 작업물을 같이 보면서 상대와 본인의 산출물을 비교하여 개선하는 것도 좋아요.
후임에게 부탁한 업무가 어떻게 될지 모르니, 선임이 후임의 업무까지 중복으로 하고는 경우가 종종 있는데,
후임이 잘 배우려는 의지가 있다면 선임이 한 작업물을 보여주며 가르치는 것도 방법이에요.
사실 깃을 제대로 쓰는 방법을 하는 사람이 많지 않아요.
회사의 상황에 따라 후임을 아예 방치하는 경우도 있나요?
A: 회사의 상황마다 다 다를 것 같지만, 아무대로 회사 입장에서는 신입의 방치는 사내 관리가 되지 않는다는 반증이자 인력 낭비이기 때문에 손실일 수 밖에 없어요. 따라서 보편적으로 신입/후임들을 내버려두기 보다는 실력을 키워갈 수 있는 기회를 제공하려 해요.
신입을 키우고자 하는 선임들을 자신이 신입이었을때 나를 이끌어 준 선배들의 좋은 경험 덕에 반대로 신입이 들어왔을때 동일하게 이끌어 주고 경우가 있어요. 그렇지만, 실제로 그렇게 하고자 하는 사람들은 많지는 않은 듯 해요.
뭐라도 주려고 하는 것 같아요. 하다못해 구현된 소스코드만 봐도 배울 수 있는 점이 많아요.
팀문화에서 반대 의견을 내기 어려워하는 수용적인 팀원들이 걱정됩니다. 적극적인 의견을 낼때 팀원들이 너무 수용만 하는 것 같아 눈치가 보여요.
A: 회사 입장에서는 소통을 하는 기회를 줬음에도 말을 안하면, 정해진 규칙대로 따를 수 밖에 없어요. 너무 개개인의 말 못하는 사정을 봐주는 것도 과한 듯 해요.
2개자 부류로 나뉘는 듯 해요- 휴양 스타일, 무작정 수용 하려는 사람과 여행 스타일, 적극적으로 의견을 내어주는 사람
여행스타일: 팀장님의 역량이 중요할 것 같아요. 기본적인 건 지키돼, 그 이상에 것을 해온다면 칭찬을 해주는 것 과 같은 방식으로 분위기를 조금씩 개선하나가는게 어떨가요. 그러나 의견을 조율할때 감정이 드러나지 않게 조심해야겠죠.
휴양스타일: 네네, 그렇게 하시죠. 이슈없이 가늘고 길게 (월급루팡) 가는게 좋은 사람들.
2년 정도의 시간이 지나면 업무적으로 티키타카가 잘 맞을 수도 있어요.
팀 내에서 의견이 좁혀지지 않았는데 이미 대표의 요청사항을 응한 팀원이 있어요.
Q: 직접적인 통화를 해서 팀 내에서 의견이 모아지지 않은 상태에서 팀원들 각자 말이 달라져서 기간산정을 맞출 수 없고, 인력도 쓸 수 없어서 문제가 됩니다.
A: 문제의 원인은 성급한 피드백이에요. 그래서 개발검토 기간이 꼭 필요해요. 추후에 나온 의견이 있는 경우, 요청사항에 대한 피그백은 “새로 나온 의견까지 고려해서 다시 검토하고 말씀드리겠다” 라고 팀 전체의 의견을 대변해서 말해야해요. 따라서 소통창구를 1개로 모으는 프로세스가 필요합니다. 유선 전화로 팀원 개인에게 물어봐도 팀원들과 합의를 보고 피드백을 드리겠다 해야합니다.
사내의 개발언어/툴가 있는데 바꾸고 싶어요.
Q: 이클립스→인텔리제이로 변경하고 싶은데, 그로 인한 설정값이 달라 생기는 경우 저한테 책임을 져야 한다고 하세요.
A: 자신의 의견에 따라 나오는 사이드이팩트는 감안하고 의견을 내세우는게 옳아요. 본인의 일에 책임을 지는 것은 당연하니까요. 툴을 바꾸고 싶은 과정도 결국은 설득일텐데, 상대를 설득 시킬때 좋은 방법은 자신의 불편함보다 회사 입장에서의 효율을 어필하는게 방법일 수 있어요.