진짜 너무 되고 싶어요...;;
입사 두 달차 후기 겸 제목 그대로 일 잘하는 사람이 되고 싶은 신입 개발자의 주저리 주저리를 담아보려합니다
제가 입사하기 전과 입사하고 나서도 매일 떠올렸던 단어는 1인분이었습니다
대체 어떻게 해야 1인분을 할 수 있는걸까?
라는 생각을 매일매일 했던 기억이 납니다
실수를 한 날에는 오늘은 1인분을 못했다는 생각에 하루종일 안절부절 못하고 죄송합니다를 연발한 날도 있고 괜시리 위축되어서 축처진 미역처럼 퇴근했던 기억들이 스쳐지나가네요...(아마 다음 글은 실수 모음집이 되지 않을까 싶어요 ㅎㅎ..)
한달정도 지났을 때 처음으로 sprint에 참여를 하게 되었고 진짜 실무라고 부를 수 있는 일이라는걸 맡아서 하게되었습니다. 뭐랄까 드디어 1인분을 할 수 있는 기회야! 같은 느낌이었겠네요
sprint가 끝나면 해당 sprint에 참여한 팀원들이 모두 모여 회고를 진행하고 회고 말미에 이번 sprint의 MVP를 선정합니다. 이전에 한번 sprint의 회고에 참관자 느낌으로 들어가본적이 있었는데 그때 MVP에 선정되었던 분을 보면서 정말 부럽다라는 생각을 했었던 적이 있었습니다. 선정되었다는것 자체가 부럽기도 했고 평소에 늘 그분을 보면서 일을 잘하시는거 같다라고 생각했기에 나도 한번쯤은...!이라는 생각을 했었습니다
(부...부럽다...)
누군가는 잠시 박수받고 끝나는 아무런 능력치없는 온라인 게임속 칭호같은 느낌이겠지만 저에게는 그 이상의 가치로 느껴졌던것 같습니다
그렇게 저의 첫 sprint가 끝나는 날...!
MVP로 선정되는 결과를 만들어 낼 수 있었습니다
아마도 처음 참여하는 sprint여서 좀더 열심히하려고하는 모습을 좋게봐주셨을 수도 있고 신입 기 한번 살려준다는 느낌으로 투표를 해주셨을수도 있겠으나 저에게는 정말 기뻤던 순간이었답니다
그러다 문득 이런생각이 들었습니다
내가 이번 sprint때 어떻게 일을 했고 어떤 행동을 했는지를 정리해보면 어떤게 누군가를 일을 잘하는 사람이라고 생각하게 하는 포인트인지를 알 수 있지 않을까?
나는 이번 스프린트때 뭘 했는가?
커뮤니케이션 미스 줄이기
sprint에서 특정 기능을 구현하기 전에 PM에게 기능자체에 대한 설명을 듣습니다. sprint의 시작 시점에서 기획의도와 정돈된 디자인을 보고 개발해야하는 사람들은 우선 왜 개발해야하는지에 대한 이해를 마친 후에는 어떻게 개발해야할지를 고민하게됩니다. 그리고 그 어떻게는 사람마다, 분야마다 달라지게 됩니다
누군가는 기존에 있던걸 살짝만 바꾸거나 혹은 그대로 쓰기만 해도 괜찮겠다고 생각하기도 하고 누군가는 이상적인 방식을 떠올리기도 합니다. 아무래도 각각의 영역의 개발자들이 병렬적으로 작업하다보니 우다다다 개발을 하다가 어느 순간 어긋나게 되는 경우가 많습니다
그리고 그 어긋남을 알게되는 시점은 서로 궁금증을 물어보다 비로소 깨닫게 됩니다. 사실 저도 딱 그랬습니다. 예를들어서 뭔가 예상했던것과 다른점이 생겨서 프론트앤드분께가면 서버에서 이렇게 내려준다고 하고 서버분께가면 또 다른 입장을 알게됩니다. 때로는 프론트앤드분이 뭔가 궁금해서 저에게 오면 저는 또 모르는 내용이라 서버분에게 가면 셋이서 무수한 ?를 만들고 있습니다. 그러다가 합의점을 꾸역꾸역 도출했다 싶으면 갑자기 AOS개발자분이 어쩔수 없었던 비하인드를 말해주면서 기존방식대로 갈 수 밖에없다고 이야기합니다
결과적으로는 아무것도 바뀐게 없음에도 혼란스러운 시간만, 커뮤니케이션하면서 들었던 비용만 그대로 지불한채 맥북 앞으로 돌아오게 됩니다
다만, 저는 특정 부분을 유지하려는 상황 앞으로 계속해서 발생할 수 있는 side effect가 걱정이 되었고 이 문제를 해결할 수 있는 대안책을 만들기 위해서 시간을 투자했습니다. 정말 어쩔 수 없는 부분과 그럼에도 불구하고 바꿀 수 있는 부분을 물어가며 분리했고 현재 상황에서 가능할 수 있는 A안과 B안을 만들었습니다
그리고 정보의 파편화가 발생하지 않도록 PM분께 관련된 모든 개발자분과의 미팅을 제안드렸고 모든 실무자가 모였을 때 각 파트별로 겪고 있는 문제, 문제가 발생한 비하인드, 현재 변경이 가능한부분과 불가능한부분, 현 시점에서 문제를 해결 할 수 있는 두가지 방식, 그렇게 바뀌었을 때 앞으로 쉽게 대응 가능한 케이스에 대해서 말씀드렸습니다
현재 발생한 문제점을 해결하면서 앞으로의 확장성과 잠재적인 커뮤니케이션 비용을 줄일 수 있다는 점에서 모든 파트 개발자분이 공감해주셨고 해당 방식으로 진행하기로 했습니다. 추후에는 비슷한 task의 경우엔 앞으로 이러한 방식으로 진행하자고까지 이야기가 진행되기도 했습니다
나만 잘한다고 장땡인 일도 있겠지만 아닌일도 분명히 있고 그때마다 한 장소에서 이야기를 나누는 것이 더 귀찮아 보여도 때로는 더 효율적이라는걸 알게되기도 했고 오히려 더 빠른 결론을 도출해낼 수 있다는걸 알게되었습니다
히스토리 정리하고 공유하기
제가 회사에서 개발을 하면서 취업하기 전에는 전혀 중요하게 느끼지 못했는데 막상 들어와보니 정말 중요한거구나라고 알게된 것이 있다면 히스토리입니다
처음 코드를 보면 이상적이지 않아 보이는, 효율적이지 않아 보이는코드들이나 로직들이 굉장히 많습니다. 그래서 그 부분들을 내가생각하는 이상과 효율에 빗대어 수정하면 원치 않은 동작을 할때가 대부분입니다
왜 그런가 싶어서 끙끙대고 있으면 히스토리를 알고계신 동료개발자분이 그렇게 할 수 밖에 없었던 이유에 대해서 설명해주십니다. 그리고 듣다보면 왜 이렇게 할 수 밖에 없었는지를 이해할 수 있게됩니다. 그리고 그 상황이라는 건 내 파트만 어떻게 바꾼다고 될일이 아닐때가 90%입니다. 같이 일하는 타 파트의 히스토리때문일 수도 있습니다
회사 프로젝트에는 히스토리에 의한 어쩔 수 없음이 많이 들어가있습니다. 그리고 누구도 예외없이 그러한 코드를 작성할 수 밖에 없을 때가 생깁니다. 때로는 우리파트만 알아도 되는 부분이 있고 때로는 모두가 알아야하는 히스토리가 생기거나 기존에 있었지만 이제서야 드러나는 히스토리가 생기기도 합니다
저는 그런 부분이 발생할때마다 이렇게 된 배경, 이러한 배경에 대해 논의된 내용을 노션으로 정리해서 슬랙에 글을 올렸습니다. 아마도 누군가는 이건 굳이 내가 몰라도 되는 부분이겠네 하고 넘어가신 분도 계실거고 누군가는 아 진짜...? 그랬었구나...하는 분도 계셨을거라고 생각합니다. 아직까지 누구에게 유효한 히스토리일지를 판단하는 경험치가 부족해서 모두에게 매번 정리해서 공유한 부분덕분에 커뮤니케이션 미스를 예방할 수 있었을거라고 생각합니다
내 프로젝트의 히스토리 이해하기
위의 내용이랑 비슷한 내용이지 않을까 싶습니다. 저는 아무래도 신입이다보니 내가 특정 프로젝트의 히스토리를 모르는건 어쩔수 없다!라고 생각합니다. 그때문인지 아마 2~3년차 동료분들은 다 알고 계실거야라고 생각했습니다
(신입이 바라보는 시니어 개발자)
sprint중간에 인력 충원이 필요해서 시니어 개발자분이 중간에 도와주시기 위해 들어오신적이 있는데 저에게 와서 이것저것 물어보셨던적이 있었습니다. 저는 처음에 음...? 왜 굳이 나한테 와서 물어보시지...?라고 생각했었습니다. 뭔가 내가 프로덕트를 잘 이해하고 있다 확인해보시려는건가라는 생각에 제가 개발전에 물어물어 알게된 흐름과 히스토리를 말씀드렸었습니다
그런데 sprint가 끝나고 회고를 할때 그분이 처음 sprint로 들어갔던 프로덕트여서 히스토리를 몰라서 이해가 안되는점들이 많았는데 이 부분을 제가 잘 말해줘서 이해할 수있었다고 말씀해주셨습니다. 그럴 수있다라는걸 그때 처음 깨달았습니다. 아무리 잘하는 시니어 개발자라도 히스토리를 모르면 이해할 수 없는 코드들이 많고 이걸 알려주는 사람이 없거나 알기위한 시간투자를 하지 못하면 개발을 하는데 어려움을 겪는다는걸말이죠. 그리고 질문이라는게 정말 중요하다는것도 알게되었습니다
모르면 물어봐라 그게 훨씬 빠를 수 있다라는 동료 개발자의 조언이 어떤 의미였는지 알게된 순간이었습니다
sprint에서 누구보다 개발을 잘했다!, 코드 퀄리티가 좋다!는 아니었습니다. 내가 짠 코드를 보면서 씁...이게 아닌거같은데...돌아는 가네...라는 느낌을 받을 때가 많았습니다. 오히려 어떤 문제를 코드가 아닌 소통으로 풀었던 sprint가 아니었을까 싶습니다. 처음엔
지금 이 문제를 어떻게 코드로 처리하지 예외를 어떻게 코드로 처리할 수 있게할까
를 고민했습니다. 근데 오히려 그 문제가 미팅 한번으로, 좋은 제안 한번으로 쉽게 해결되었습니다. 개발자는 개발만 하는 사람은 아니지만 개발을 해야하는 사람입니다. 그러다보니 개발로서 모든걸 해결하려할때가 많았습니다. 개발자는 문제를 해결하는 사람이라는걸, 가지고 있는 도구로 코딩이라는 선택지가 하나 더 있는 직업일 뿐이라는걸 알게된 sprint였다고 생각합니다
0.1666666년차 iOS개발자 입니다
입사 두달이 되던 날 같이 일하는 동료평가를 받게되었습니다. 입사 한달차에 한번 진행했던 터라 크게 긴장이 되지는 않았지만 실수했던 순간들이 계속해서 떠올라서 약간의 각오는 하고 있었습니다
회의실에 들어가니 담당자분이 이런말을 해주셨습니다
개인적으로 신입에게 해줄 수있는 가장 큰 칭찬은
1인분을 해내고 있다라고 생각해요. 공통 된 의견으로 1인분을 해내고 있다고 하시니 불안해하지 않았으면 좋겠습니다
듣고싶었던 말이기도 했고 그 동안 불안해했던 제 자신에게 위로가 되는 말이었던것같습니다. 그리고 자신감이 부족하다 충분히 잘하고 있다는 코멘트를 읽어주셔서 진짜 살짝 울컥했던 기억이 나네요
저에게 초심이란 이게 아닐까 싶습니다
커뮤니케이션이 원활한 개발자가 되기 위해 노력할 것
개발자는 코딩도할 수 있는 사람이지 코딩만하는 사람이 아니라는걸 생각할 것
다음글은 신입 개발자의 실수모음집으로 돌아오겠습니다...부끄사할예정입니다...
