목차
안녕하세요. 너무 오랜만에 블로그에 글을 쓰는 듯 합니다.
작년 11월말에 운좋게 취업을 하게 됐고, 직무는 macOS 개발자입니다.
원래 iOS개발자가 되고 싶었지만, macOS 개발자가 됐습니다. 그때 당시에는 고민이 되긴했지만, 지금은 전혀 후회되지 않네요.
어느덧 3개월이란 시간이 지났는데, 정말 쏜살같이 지나갔네요. 3개월동안 정말 많이 배웠고, 발전했다고 느낍니다.
그래서 그냥 제 느낀점을 적어보고 나중에 몇개월 뒤, 몇년 뒤에 보려고 작성하려고 해요.
지금은..!
우선 지금, 정말 재밌다. 이제 실무에 투입돼서 나의 코드를 적용하고 있는데, 너무 너무 너무! 재밌다. 친구들 만나서 "나는 월요일이 기대된다"라고 말하면 이상한 사람처럼 쳐다보기는 하는데, 근데.. 정말 재밌다. 애초에 개발자가 되려고 한 이유도 개발하는게 너무 재밌어서였는데 아직까진(?) 예전에 밤새면서 작업할 수 있었던 열정이 지금도 있는 것 같다.
앞으로 어떤 프로젝트가 생길지, 또 어떤 코드를 보게 될지, 너무 기대가 된다.
🥲 사실.. 처음부터 재밌지는 않았다.
워낙 iOS에 공부를 많이 했었고, 앱도 출시했었고, macOS도 iOS처럼 공유하는 프레임워크도 많고 해서 굉장히 자신감이 있었었다. 그래서 하루빨리 부서에 도움이 되는, 1인분하는 개발자가 되겠다고 마음먹었다.
그래서 소스코드를 보는데 처음에는 굉장히 낯설었다. 앱의 시작점이 어딘지도 모르겠더라. 로그인화면이 구현된 코드를 찾으려고 해도 쉽사리 찾아지지 않았다. 그때 좀 큰 벽을 느꼈던 것 같다. 프로젝트에 폴더가 잘 나뉘어져 있긴 하지만 폴더를 열어보면 무수히 많은 파일과... 파일을 열어보면 무수히 많은 코드들... 하나의 메서드에도 굉장히 많은 코드... 굉장히 당황스러웠다.
당찬 자신감과 다르게 갑자기 내가 과연...이해할 수 있을까? 라는 생각이 꽤 컸다.
( 사실 지금 생각해보면 늘 혼자 또는 둘이서 개발해오다가 정말 실제로 몇년동안 서비스 되고있는 소스코드앞에서는 당연한 기분이었겠다. )
- 이겨내기
- 멘토가 계속 부담갖지 말라. 이해못하는게 당연하다. 시간이 걸리는게 당연하다. 라고 말씀해주셔서 어느정도 마음을 다잡을 수 있었다.
- 또 나는 늘 정말 괜찮은 개발자가 되고 싶다라고 생각했고, 비록 천재는 아니지만, 그만한 용기와 끈기가 있어 가능하다라고 늘 생각했다. 그래서 이번에도 끈기있게 살펴보자라고 다짐했다.
- 또, 워낙 우리 부서에는 실력높은 시니어 개발자분들이 많이 계셨고, 신입에게 시니어 개발수준을 전혀 기대하지 않는다라고 이따금씩 말씀해주셔서 부담감을 덜어낼 수 있었다.
멘토가 원하는 뷰의 코드 찾는 꿀팁도 알려주셨고, 어느순간 정말 코드가 하나씩 이해가 가기 시작했다..!! ( 많이 오래된 레거시 코드를 볼 때는 흠칫하곤 하지만 ) 점점 구조가 눈에 들어오기 시작했다! 이때 굉장히 재밌었는데, 개발의 즐거움보다 나에게 어려웠던 것을 이해하는데 있어서 즐거움이었다. 이제는 확실히 기존코드에 대해 자신감이 생겼다! 여전히 아직 보지 못한 코드가 훨씬 많지만, 이렇게 지금처럼만 하면 점점 더 많이 알게될거라고 믿어 의심치 않는다.
😎 코드를 모국어처럼!
3개월동안 코드를 많이 봄으로써 이전보다 더 코드를 빠르게 이해하게 된 것 같다. 공고글에 가끔 지원 조건에 "코드를 모국어처럼 바로바로 이해할 수 있는사람 ? "을 기재한 경우를 본적이 있는데, 이제야 그 문장이 조금 이해가 갈 것 같다. 정말 1년전과 비교하면 이제는 정말 코드를 읽고 이해하고 있다라고 느낌이 든다. 예전에는 다른 사람이 쓴 코드를 어떻게 이해를 할까, 라는 생각이 들었는데, 스터디하면서 코드리뷰도 하고, 하다보니 조금씩 코드를 읽을 수 있다라는 것을 느끼게 됐고, 부서안에서 코드를 계속 보다보니 ( 정말 술술 읽히는 정도는 아니지만 ) 해당 코드가 무엇을 의미하는지 좀 더 빠르게 이해가 되는 것 같다.
물론 여기서 코드이해가 잘 되는 요인은 내가 성장한 걸 수도 있겠지만, 그것보다 선배 개발자분들이 써놓은 코드가 너무 깔끔한게 크다.
네이밍이 너무 훌륭해서 이해가 잘되고, 그러다보니 자연스럽게 내부 코드 흐름도 이해가 되고..
🧐 코드 언어의 수준보다는 경험이 더 중요한게 아닐까?..
나는 늘 코드 언어가 굉장히 중요하다라고 생각했다. 그렇기 때문에 나는 Swift언어가 제일 익숙했고, Swift언어가 아니면 굉장히 불안했고, 거부감이 상당히 컸다. 어쩌다보니 부서안에서 swift언어 말고도 다른 언어 ( Objective C, python, 쉘 스크립트 .. ) 를 봐야하는 경우가 생겼는데, 굉장히 불안했다. 근데 사실 언어는 프로그램이 동작하기 위한 명령어이고, 큰 틀 ( 반복문, 함수, 변수.. )은 어떤 언어든 비슷하다. 그렇기 때문에 특정 행위에 대해 그저 다른 언어로만 작성한 것일 뿐, 코드를 이해하는데 있어서 크게 어려움은 없었다. ( 물론 세부적인 디테일은 공부해야하지만! )
코딩테스트 같은 경우는 시간이 굉장히 중요하기 때문에, 익숙한 언어를 사용할 수 밖에 없지만, 실제 업무에서는 코딩테스트처럼 코드를 빠르게 작성할 필요는 없다라고 생각이 든다. 시니어 개발자들의 경험담에서는 실제 코드를 타이핑하는 시간보다, 코드를 이해하고 고민하는 시간이 더 많은 비중을 차지한다고 한다. 그러므로, 언어를 얼마나 깊이있게 아느냐도 중요하겠지만, 얼마나 효과적으로 구조를 짤지, 어떻게 해결할지는 경험과 지식이 더 중요하겠다라고 생각이든다. ( 그래서 당연히 다들 시니어 개발자를 모셔가는 이유겠지만! )
그러다보니 자연스럽게 언어에 대한 불안감과 거부감은 크게 사라졌다.
🥶 사이드이팩트를 조심하자...!
이짤을 처음봤을 때 굉장히 웃겼다 ㅋㅋ 아직까지 짤만큼 심각한 상황은 겪어보지는 않았는데, 그래도 어떤 느낌인지는 살짝 맛봤다.
위와 같이 거슬리는 부분을 없앤건 아니고, 내부적으로만 리디자인을 진행하는데, 나름 잘 구현했다라고 뿌듯해하면서 테스트를 진행해봤다. 근데 전혀 생각치 못한 이슈가 발생했다. 크래쉬나거나 그런 심각한 이슈는 아니였고, 뷰가 살짝 이상한점?.
한참을 고민한뒤에야 깨달았는데, 내부적으로는 문제가 없었고, 외부에서 이 객체를 사용할 때 문제가 발생했다. ( 나름 이 이슈의 원인을 찾은 나에게 대견하다는 생각도 들었다. ) 그때, 체감을 했는데, 기존에 존재하던 것을 수정할 때는 항상 조심해야겠다라고 다시한번 느꼈다.
이제는 코드를 수정하고 싶은 기분이 들때는 짤처럼 어떤 사이드이팩트가 나타날지.. 겁나기도 한다. 나는 지금 쓰여진 코드들에 대해 굉장히 경외롭게 생각하기 때문에, 내가 미처 생각하지 못한 분명..무슨 이유가 있을테니까.
책임감
처음으로 회사를 다녀보면서 실제 개발을 하다보니 느낀게 있었다. 회사를 다니기 전에는 어떤 기능을 구현하고자 한다면, 그게 가능하다고 생각이 들면 나는 그냥 하면 됐었다. 하지만 여기서 회의를 몇번 참석을 하면서 느낀게, 가능할 법해도 무작정 오케이하면 안되는 것을 알게됐다. 그 기능이 실제 서비스되고 있는 핵심에 크게 벗어난 건 아닌지, 그 기능을 구현하려면 다른 클라이언트도 고려해야되는 건 아닌지, 추후 유지보수도 신경써야한다. 특히나 서비스가 오래되다 보면은 자연스럽게 히스토리가 옅어질 수 밖에 없고, 겉보기에는 작아보이는 기능이 실제로 어떤 사이드이팩트가 생길지 모른다. 즉 가능할 것 같은데..~? 라는 섣부른 판단으로 인해 결과가 좋지 못한다면 그동안 다른 프로젝트에 사용될 수 있었던 리소스의 비용도 무시못할 것이고, 성공한다 한들, 추후 비용도 무시못할 것 이다. 물론 실패가 무조건적으로 나쁘다는 건 아니지만, 그만큼 주변 현재 상황을 많이 고려하는게 중요한 것 같다.
그리고 이러한 의견들을 적극적으로, 어떻게 얘기할 수 있는 자세도 중요한 것 같다. 특히 회의에 리더가 적극적으로 자신의 주장을 얘기하는데, 그 얘기가 전혀 기분이 나쁘지 않았다. 오히려 멋있었다.
이 부분은 비단 개발자라는 직업에 국한된게 아니라 모든 직종의 책임감이지 않을까 싶다.
🧐 좋은코드란...?
계속 코드를 보다보니, 내가 생각하는 1순위는 잘 읽히는 코드여야할 것 같다. 잘 읽히긴 위해서는 네이밍도 굉장히 중요하겠다. 네이밍이 좋다면, 내부 코드가 네이밍대로 흘러가는지도 굉장히 중요하다라고 생각한다. 예를들어, A라는 행위를 하라고 했는데, 슬쩍 A + 𝜶 라는 행위는 안좋다라고 생각이 든다.
그다음에는 2번째로는 위의 짤처럼 특정 코드를 수정했을 때 사이드이팩트가 적은 코드가 좋은 코드인 것 같다. 예시를 들어보면, 하나의 객체안에서 다양한 메서드들이 많은데, 이 메서드들이 공통으로 사용하는 변수는 최대한 줄이는게 좋다라고 생각이 든다. ( 어쩔 수 없이 사용해야하는 경우도 있겠지만 ) 당장 구현할 때는 이 변수가 얼마나 중요한지, 이 변수로 인해 어떤 변화가 생길지 알겠지만, 나중에 보면, 또는 다른 사람이 볼 경우, 그리고 리팩토링 또는 추가 구현을 해야할 경우, 굉장히 난감하다. 이 변수를 내가 수정해도...괜찮을까? 특히 오래된 코드일 수록, 다르게 보면 굉장히 안정된 코드라고도 볼 수 있으니까 말이다. 그러다 보니 가급적이면 매개변수로 전달하려고 하고, 매개변수는 최대한 변경하지 않으려고 하고 있다.
다른 예시로는, 외부에서 특정 객체를 사용할 때는 해당 객체가 언젠가는 변화할 수도 있다는 것을 염두에 두어, 강한 연관성이 있다면 어떻게서든 해당 객체에 알려두면 좋을 것 같다. 좀 더 정리하면, 내부 객체가 어떻게 변화해도 외부 객체에는 변화가 없도록 하는 것이 중요할 것 같다. 내가 겪었던 바로는, 외부에서 특정 객체의 사이즈를 기준으로 다른 뷰의 위치를 결정하고 있었는데, 내부 객체에서는 전혀 이러한 연관성을 알 수가 없었다. 그래서 이러한 연관성이 있는 것을 해당 객체에 알리면 좋을 것 같다. 예로들면, protocol을 이용하거나, 해당 객체에 특정 메서드를 추가하거나...하면 좋을 것 같다.
😡 언제까지 너가 신입이겠니??
부서내의 시니어분들에게는 내가 무엇을 해도 마냥 귀엽게 보일 것이다. ( 실제로 귀여워보이지는 않겠지만 ) 실수를 해도, 못해도 당연하게 보일 것 이다. 프로젝트를 잘 마무리 해도 그건 당연한 것이다. 왜냐하면 리더분께서 신입인 나에게 할 수 있는 프로젝트를 맡겼기 때문이고, 리더분의 통찰력이라고 생각한다.
하지만 어느순간 부터는 실수는 당연한게 아니게 될테고, 내가 늘 감당할 수 있는 프로젝트만 하지 않을 것 이다. 나도 언젠가는 누군가를 알려줄 수 있는 주니어 개발자가 될것이고, 신입이라는 방패는 언젠가는 벗겨질 것이다.
언젠가는 그 상황이 올텐데, 두렵기도 하다. 과연 주니어 개발자라는 타이틀을 가질 수 있는 개발자가 될 수 있을지..
우리 부서에 하나의 프로젝트를 몇달씩 하고 계신 시니어 개발자가 많은데, 굉장히 경외롭게 느껴진다. 또 어떤 이슈가 발생할 때 굉장히 빠르게 분석을 하시고 찾아내시고, 특정 프로젝트에 대해 촥촥 얘기하실 때, 굉장히 멋있어보인다. 아직까지 나는 옆에서 멀뚱멀뚱... 보고있지만.. 언젠가는 나도 그렇게 되지 않을까..?
그러므로 늘, 지금처럼, 열심히 해야겠다. 프로젝트에 도움이 되면서, 회사에 도움이 되면서, 나도 이곳에서 배울 수 있는 것은 다 쏙쏙 흡수하여 배워야겠다. 👊
앞으로 목표
- 코드를 모국어처럼!!
- 이미 작성된 코드들을 구조화 시켜보면서 더 많이 알아가기!!
- 네트워크 지식 더 쌓기!
- 굵직한 프로젝트를 담당할 수 있는 개발자 되기!!
- 좀 더 다양한 시각으로 바라보고, 자신의 의견을 주장하기!
댓글