안녕하세요. 꽤 오랜만에 글을 쓰는 킴스캐슬입니다.
사실 오늘이 입사 1주년은 아니지만, 이제 딱 일주일 후면 입사 1년이 되는 시점이라
그동안의 시간을 돌아보며 오랜만에 회고글을 남겨보려 합니다.
취준 시절의 이야기가 궁금하신 분들은 아래 링크에서 확인하실 수 있습니다.
오늘 글에서는, 비전공자로서 iOS 신입 개발자로 입사 후 1년 동안 느꼈던 점들을 중심으로 이야기해보려 합니다.
1. 회사에 있는 모두가 내 편
사실 취준할 때도 그렇고 회사에 처음 들어갔을 때도 가장 큰 걱정은 이거였습니다.
내가 “개발”을 못해서 폐를 끼치면 어떡하지?
예를 들어,
“킴스님, A 기능을 개발해주세요.”
라고 요청받았을 때, 그게 제가 한 번도 해본 적 없는 일이면
‘못해요… 엉엉 ㅠㅠ’ 하게 될까 봐 그리고 그게 너무 창피할 것 같아
늘 불안했던 기억이 납니다.
그런데 막상 1년을 지내보니 그때 그런 고민을 하던 제 모습이 귀엽게 느껴질 정도였습니다.
돌이켜보면 그 이유는 두 가지였습니다.
첫 번째, 아무도 제가 처음부터 잘할 거라고 기대하지 않았다는 것
두 번째, 회사의 모든 사람들이 “내가 잘하게 되도록” 돕는 사람들이었다는 것입니다
누군가 제 부족함을 들춰내거나 창피를 주려는 사람은 단 한 명도 없었습니다
입사 후 처음 맡은 업무는
기존에 사용하던 API에 bool 값이 하나 추가되었는데
그 값이 true면 알림을 띄워주는 기능을 구현하는 일이었습니다.
지금 생각하면 정말 간단한 일이죠
이미 iOS 취준생이라면 대부분 해봤을 정도로 쉬운 API 연동이었고
기존 함수에 if 문 하나만 추가하면 되는 수준이었습니다
하지만 당시의 저는 모든 게 낯설었습니다
모바일 리드 개발자님은 미팅 자리에서 “어떤 파일을 보면 좋을지, 어떤 함수가 관련되어 있는지” 하나하나 세세하게 설명해주셨습니다.
예상 일정을 하루로 말했더니 웃으시면서
“그럼 3배로 잡아요. 그게 진짜 일정이에요.”
라며 신입에게 꼭 필요한 현실적인 조언도 해주셨습니다.
또 서버 개발자와 소통해야 하는 상황에서도 PM님들이 “입사한 지 일주일 된 신입이 백엔드 개발자와 바로 이야기하는 게 쉽지 않다”며 사전에 조율을 잘 해주신 덕분에 큰 어려움 없이 task를 마칠 수 있었습니다. 그 경험을 통해 긴장도 많이 풀렸고 ‘아, 정말 다들 내가 잘할 수 있도록 도와주는 사람들이구나’라는 걸 깊이 느꼈습니다
2. 결국 사람과 사람이 하는 일
취준중인 개발자들과 이야기하다보면 이런 이야기를 자주 듣습니다
개발자는 개발만 잘하면 되지 않을까요? 심지어 신입이면 실력이 제일 중요하지 않을까요?
현실적으로 저같은 경력없는 생신입 개발자가 면접에서 개발 실력이외의 여러 장점을 이야기한다고해서 그게 면접관 입장이나 실무자 입장에서 크게 와닿지 않을 수 있다고 생각합니다
특히 이런 주제로 맨날 나오는 것이 "커뮤니케이션 스킬"이죠
저도 여러번의 면접에서 "커뮤니케이션 스킬"을 장점으로 이야기했다가 경력 없는 신입이 동아리, 사이드프로젝트에서했던 경험만으로 "커뮤니케이션 스킬"이 뛰어나다, 장점이다라고 말하기는 어렵다는 뉘앙스의 이야기를 듣게됩니다
저도 느껴보니 확실히 동아리, 사이드프로젝트에서의 갈등상황과는 많이다르고 비지니스속에서의 커뮤니케이션은 다른 부분이 많습니다
그래도 말이죠
어쩌면 저는 개발실력보다는 커뮤니케이션이 개발자에게도 더 중요할수도있다고 생각합니다
애초에 지금 시점에서 "순수한 개발"은 AI, 다양한 사람들의 경험(구글링)을 통해서 많은 도움을 받고 조금은 부족한 부분은 있어도 "돌아가게는" 만들수있다고 생각합니다. 예전 보다 훨씬 쉽게 말이죠
그리고 완벽한 코드는 없기에 현재시점에서 문제없이 잘 돌아가게 만드는 것만으로도 의미가있을때가 많습니다. 이후에 코드리뷰에서 다듬는다거나 추가로 중복되는 기능이 추가되면 그때가서 디자인 패턴 적용을 고민하고 좀더 확장성 있는 코드를 고민하는것도 하나의 방법이라고 생각합니다(처음부터 너무 큰 확장성을 고려하거나 이쁜 코드만을 위해서 오랜 시간을 사용하는것 보단 말이죠. 우린 비지니스를 하는 사람들이니까요)
일을 하다보면 그 내가 개발해야할 기능이 확정되고 그 task를 개발하기 전 단계를 오는 과정이 수월하지 않을떄가 훨씬 많습니다
회사에 다니다보면 "그냥 마음 편하게 개발만하고 싶다..."라고 하는말이 들리는것도 다 이런 이유죠
기획을 공유받는 과정에서 문제가 발생하고 그 문제를 고려하기위해서 다양한 이해관계자(디자이너, 백엔드, pm)들 사이에서 여러 이해관계가 충돌합니다
예를들면 예외상황인 A, B상황에 대한 논의를 하고있는데 이것까지 고려하자니 일정을 미뤄야하는 경우가 있다고했을때
크게 두가지 방향이 있습니다
- 기간을 늘리고 A, B를 고려한다
- 기간을 늘릴 수 없으니 A, B는 고려하지 않는다
정답은 없습니다. A, B가 얼마나 자주발생할지에 따라 다를수도있죠
그리고 A, B가 발생한다고 해도 CS채널을 통해서 충분히 처리가능할지에 따라도 다릅니다
게다가 "얼마나 자주 발생할지"라는 것도 굉장히 주관적입니다
매일 평균적으로 1건식 발생한다고 해보죠. 여러분은 이 빈도수를 "자주 발생한다"라고 판단하실건가요?
자주발생한다고 판단했을때 만약, 그 기능을 하루 평균 5000명이 쓰는데 그 빈도로 발생한다고하면 어떨까요? 또 다른 느낌일 수 있습니다
A, B를 고려한다고 하면 추가되는 디자인 리소스가 필요하다고 생각해봅시다. 디자이너는 다시 추가 디자인으 해야하고 이로 인해 개발자가 보고 작업해야하는 디자인 결과물을 받는 일정이 느려질 수 있습니다. 그런데 이때 iOS는 그렇게 하기 쉬운데 안드로이드 개발자는 그 추가기능을 적용하기 너무 어렵다면 어떨까요?
개발자에게 최종적으로 task가 주어지기 전에는 정말 수많은 합의되지 않은 "만약"을 모두가 동의할만한 "만약"으로 만드는 과정이 필요합니다
그 과정에서 필요한게 "커뮤니케이션 스킬"이라고 생각합니다. 이 과정이 없다면 개발은 시작될 수 없습니다.
3. 말 이쁘게 하는 건 "큰" 장점이다
말을 돌려서하는건 좋지 않다고 생각해요
직설적으로 말하는 사람에게 좀 부드럽게 말해달라고 피드백을 하면 자주듣는 답변입니다
이건 순전히 제 개인적인 생각입니다만
- 말을 돌려서 하는 것과 부드럽게 말하는건 다른 이야기입니다
- 돌려말하는게 나쁘거나 틀린 것이 아닙니다
돌려말하느니 그냥 핵심을 이야기하는 것이 시간적으로 효율적이고 어쨋든 나는 맞는말을 한것이니 큰 문제없다가 보통 이 답변의 핵심입니다
그 의견이 틀렸다고는 생각하진 않지만 이러한 커뮤니케이션은 시간이 갈수록 큰 비용이 들게되는 원인이 되는 경우가 많이진다고 생각합니다
물론 누군가 나에게 쿠션어없이 직설적으로 말하기를 원하는 사람도 있겠지만 기분조차 나빠하지 않는 사람은 거의 없습니다. 서로의 기분이 조금이라도 상할 가능성이 매우 높은 커뮤니케이션이다라고 생각합니다(이런 방식으로 커뮤니케이션이 길어지면 길어질수록 말이죠)
그렇게 기분이 서로 상한 상태에서 다른 주제를 논의 한다면 어떻게될까요? 방어적인 자세를 취한 상태로 시작할 가능성이 높아질겁니다. 논의라는것이 서로의 생각을 받아들인 채로 시작해도 어렵고 힘든데 심지어 서로의 의견에 부정적인 필터를 끼운채로 시작한다면 어떨까요?
내 의견을 존중해주고 서로 기분나쁘지않게 배려하며 평소에 커뮤니케이션을 하던 A라는 사람이 있었다고 해보겠습니다
반대로 나에게 피드백을 해줬을때랑 평소에 직설적인 피드백으로 인해 상처를 받고 기분이 나빴던 B라는 사람이 있다고 해봅시다
같은 피드백을 A라는 사람이 헀을때와 B라는 사람이 했을때 우리는 같은 문장이더라도 완전히 똑같이 받아들일 수 있을까요?
결국 감정을 가진 사람인지라 아닐것같습니다
누군가에게 의견을 이야기했을때 긍정적인 마음가짐과 분위기로 시작하는것과 부정적이고 방어적인 마음가짐으로 시작하는건 너무 차이가 큽니다
회사생활을 하면서도 서로 다른 사람이 완전히 같은 의견을 냈음에도 불구하고 다른 반응들이 나오는경우가 많은데 특히 이런경우 서로의 기분을 상하게하는 기분 나쁜 말투로부터 비롯된 경우가 많습니다
말을 이쁘게하기만 해도 내 의견을 다른사람이 혹은 이해관계자가 잘 받아들여줄 확률도, 혹여나 받아들여주지 않더라도 다음 커뮤니케이션에서 긍정적인 영향을 미칠 확률도 높아집니다
4. 개발자는 수 많은 "어쩔 수 없음"과 싸워야한다
현업에서의 개발과 취준생때의 개발의 차이점중에 가장 큰부분이라고 하면 역시 레거시와의 싸움이라고 생각합니다
깨끗한 도화지에서 시작하는 동아리, 사이드프로젝트와 가장 큰 차이점은 이미 누군가가 사용한 도화지 위에다가 그림을 그려야한다는점입니다
사이드프로젝트를할때는 고려하지 않았던 최소지원버전의 제약도 처음에는 적응이 안됩니다. 그동안 당연하게 써왔던 여러 함수들이 회사 프로젝트에서는 버전이 낮아서 못쓴다고할때가 많거든요
그리고 어떤 부분을 보면 "아니 왜이렇게 불편하게 쓰고있는거지?" 싶을때가 많습니다.
제가 느끼기에 크게 두가지입니다
- 강제 업데이트를 하지 못하는 경우 기존 유저들의 앱버전에서 문제가 없게 하기위해서 기존 방식에 추가적인 방식을 분기해놓은 경우
- 너무나 오랫동안 사용해와서 불편함이 익숙해진 경우
1번의 경우엔 정말 어쩔수없습니다. 비지니스를 하는 회사입장에서는 모든 유저가 소중하기때문에 업데이트를 하지 않고 몇달 전 버전을 사용하는 유저도 문제없이 서비스를 사용할 수 있게 해야합니다. 만약에 10년이 넘는 서비스를 개발하는 경우엔 이 부분이 더 심합니다
예를 들어서
10년전 API response응답타입과 7년전 타입 5년전타입 3년전타입 1년전타입이다른경우 모든 유저를 고려해 응답값을 이 5가지 타입중에 하나로 분기를 해서 받아와야하는 경우가 생깁니다
이걸 이거 5개로 분기하는게 너무 더러우니까 서버는 최신 응답방식으로 API를 보내주세요라고 해버리면 10년 7년 5년 3년전 타입의 코드를 하나라도 사용하는 버전을 사용하고 있는 유저는 앱이 죽어버립니다
이게 흔히말하는 용감한 신입이 "이건 코드가 아름답지 않아!"하고 맘대로 작업했다 큰일나는 흔한 에피소드들 중 하나입니다
2번의 경우에도 이미 나를 제외한 개발자는 전혀 불편함을 느끼지 않고있는데 새로들어온 내가 불편하다고 방식을 바꿔버리면 안되겠죠
결국 두 가지 경우 모두 소통이 필요합니다
1번의 경우 이런 방식으로 사용할수밖에없는 이유를 물어보고 주석으로 남겨놓거나 회의에서 안건으로 올려보고 설득하는 방법도 있습니다. 모두의 공감을 받고 다른 이해관계자들도 설득했다면 해결할 수 있습니다
2번의 경우도 대안을 제시하고 그 대안이 충분한 설득력을 갖는다면 개선할 수 있겠죠
두가지 경우 모두 나 하나만의 개발실력 뛰어나다고, 내 논리가 완벽하다는것만으로 해결할 수 있는 문제가 아닙니다. 이런 문제는 개발 시작 전에 우선 넘어야할 산이 많고 그 산은 개발실력이 아닌 커뮤니케이션이 필요합니다
공감을 얻지 못한 해결책은 어떠한 문제도 해결할 수 없다고 생각합니다
5. 모든 정보는 나에게서 끊기지 않게하자
일을 하다보면 중간과정에서 정말 많은 논의가 이루어집니다
개발의 어려움으로 인해서 디자인의 변경요쳥이 있을수도있고 기획단계에서 논의되지 않은 내용이 개발과정중에 생겨날수도있습니다. 원래 기획대로 개발을 하려다보니 레거시나 기존기능들의 이유로인해 어려움을 겪을수도있습니다. 심지어는 기획자는 A를 이야기했는데 개발자 전부가 A'로 이해하고있었을 수도 있습니다
문제는 이런 내용을 알고있는 사람만 알면 시간이 갈수록 정보의 격차가 발생하게되고 이게 가면갈수록 심해지다가 나중에가서 서로 완전 다른 방향으로 일을 진행하게되는 경우가 정말 많아집니다
그래서 저는 개발자만 알아도 될 내용이라 하더라도 모든 내용을 정리해서 공유했습니다
이런 이런 배경속에서 이런 논의를 했고 이런 결론이 났다라는 내용을 정리해서 같이 task를 진행하는 모든 이해관계자들이 공유받을수있도록 공유하는걸 습관처럼 진행했습니다
정보의 격차를 줄이게되면 미팅시 정보 레벨을 맞추는데 시간과 노력을 쏟지 않아도되고 해당 내용을 공유받는 누군가의 질문이나 궁금증을 댓글로 받으면서 놓쳤던 부분이나 우려되는 부분을 바로바로 확인해 실수를 할 확률도 정보의 미스매치로인해 커뮤니케이션 비용이 늘어나는 문제도 예방할 수 있었던것같습니다
생각보다 A라는 기능을 개발자가 보고 개발자의 관점에서 A'로 이해했다가 최종 마감날짜에 qa를 하던 와중에 문제가 발생해서 일정에 차질이 발생한 경우가 있었는데 중간중간 공유를 한 덕에 pm이나 디자이너가 이게 아닌거같다는 피드백을 주게되고 예방을 했던 경험도 있었습니다
생각보다 내가아는걸 다른사람이 모르는 경우가 엄청X100 많습니다
6. 당연히 모두가 내 일이 가장 급하다
한 달 전쯤, 기술 검토를 맡은 적이 있었습니다.
2주 동안 진행 예정이었는데, 3일 만에 불가능하다고 판단을 내려 비교적 일찍 마무리하게 되었습니다. 그래서 “시간이 조금 남았습니다”라고 팀 슬랙에 공유했는데,
그 순간부터 모든 PM분들이 급하게 터진일을 저에게 할당해 주셨습니다
그리고 모두가 이렇게 말씀하셨습니다.
“킴스님, 이거 좀 급한 건인데요…”
결국 제 손에 들어온 “급한 일”이 네 개나 되다 보니,
한꺼번에 처리하려다가 살짝 번아웃이 오고 말았습니다.
하다 하다 안 되겠다 싶어서, 평소에 친하게 지내던 한 PM분께 상황을 털어놨습니다.
그분은 놀라며 이렇게 말씀해주셨습니다.
“PM은 말 그대로 팀원을 매니징하는 사람이고,
일의 우선순위를 조정하는 건 PM이 해야 할 일이에요.
다른 사람들은 킴스님이 지금 어떤 일을 맡고 있는지 잘 모를 가능성이 높아요.
그렇기 때문에, 누구나 ‘내 일이 제일 급하다’고 말할 수밖에 없어요.
이런 경우엔 ‘제가 현재 이런이런 Task를 맡고 있는데,
PM분들끼리 우선순위를 조정해주실 수 있을까요?’라고 요청하시면 됩니다.
그러면 PM끼리 내부적으로 논의해서 정리해드릴 거예요.”
그 조언을 듣고 나서야 많은 걸 깨달았습니다
일이 잘 안 풀릴 때는, 반드시 그 안에 문제가 존재한다는 것이고
그 문제가 정확히 무엇인지 스스로 정의하기 어려울 때는,
그걸 함께 정의해주고 해결을 도와줄 사람이 팀 안에 반드시 있다는 겁니다
결국 일은 혼자 하는 게 아니라 같이 하는 거니까요
처음 회사에 입사했을때 sprint의 회고 미팅에 참여한적이 있었습니다
2주마다 진행하는 sprint가 끝나면 모든 팀원들이 모여서 회고를 진행하고 팀원들의 익명 투표를 통해서 이번 스프린트의 mvp를 뽑습니다
당시에 제가 참여한 첫 회고에서 mvp에 선정된 분은 제가 느끼기에 "너무나 좋은 커뮤니케이션 스킬을 가지고 계신 분"이라고 느끼고 있었기에 mvp에 선정된다는건 모두에게 커뮤니케이션능력을 인정받는것이라고 생각하게되었습니다
여러번의 면접에서 제가 가진 커뮤니케이션 스킬이라는게 "증명되지 않은 장점"이라고 생각하는 사람들을 너무나도 많이 봐왔기때문에 저는 꼭 회사에 들어가면 내가 장점이라고 생각하는 "커뮤니케이션 스킬"을 증명해야겠다고 생각했고 회사에 들어가서 첫번째 목표는 mvp에 선정되는것이었습니다
일년이 지난 지금 회고 미팅 노트를 확인해보니 총 13번의 sprint에 참여했고 mvp에 10번 선정되었더라고요
물론 아직 부족한 점도 많지만, 적어도 제가 믿고 있던 제 강점이 현업에서도 충분히 가치 있었다는 사실이 뿌듯하게 느껴졌던것같습니다
‘내가 어떤 방식으로 팀에 기여할 수 있는 사람인지’를 스스로 증명한 시간이었던 것 같습니다. 앞으로도 이 경험을 바탕으로 팀이 더 잘 연결되고 더 좋은 결과를 낼 수 있도록 노력하고 싶습니다.
