개발자로써 끄적끄적. 난 누구인가?

그냥 끄적거려 보는 글이다.

10년 차 안드로이드 개발자이다. 다양한 회사에서 하고 싶은 거 다 해 보면서 충분히 좋은 경험을 해보았다고 생각한다. 그에 비해 좋은 코드를 만들었다고 생각하지는 않는다. 오류도 많았고, 부족한 부분이 여실 없이 드러나는 코드이다. 그런 코드들 덕분에 조금 더 성장할 수 있었고, 수많은 오픈소스와 다른 좋은 분들의 코드를 통해 성장할 수 있었고 앞으로도 성장할 수 있다고 생각한다.

내가 아는건 아직 1/10이라고 생각하니 아무리 잘한다고 하더라도 중간이라고 나 스스로를 평가한다.
스스로 중간이라고 평가하는 이유는 나보다 잘하는 사람은 세상에 넘치고, 내가 부족하더라도 남들에게 경험한 내용을 전달할 수 있고, 서로 배울 수 있는 사람이 반은 있다고 생각하기 때문이다. 날 너무 낮게 평가한다면 사실 존재의미가 없는 것 아닐까?

블로그를 시작한지 12년이 넘었고, 회사 생활도 10년이 넘었고, 커뮤니티 활동도 6년이 넘었고, 최근 시작한 멘토링 활동도 2년이 넘었다. 누군가를 알려줄 수 있다는 즐거움, 새로운 것을 학습할 수 있는 즐거움 모두가 즐거움이다.

 

꾸준함

내가 봐도 가장 어려운 주제다. 꾸준한 게 뭘까? 매일 어떤 식으로 정리하면 꾸준함일까? 그럴 수도 아닐 수도 있다. 그렇다고 매일 뭔가를 해야 하느냐? 아니다. 1년이 지나고 2년이 지나고 시간이 지나면 자연스럽게 꾸준함이란 키워드가 생긴다. 1년에 글을 하나 쓰더라도 10년이면 10개이다. 엄청난 양이다. 당장 어떠한 성과를 내야 한다면 당연히 부족한 양이겠지만 10년으로 본다면 많은 양이 아닐까?

 

블로그를 하는 이유?

블로그를 작성하는 이유는 명확하다. 내가 아는걸 누군가에게 전달하기 이전에 내가 스스로 이해하지 못하고 정리하지 못한 내용을 글로 표현하는 것일 뿐이다. 결국 내가 이해하지도 못하고 사용하는 부분을 글로 정리해 보는 습관을 하나 가진 것일 뿐.

누군가에겐 도움이 될 것이고, 누군가에게는 아무런 의미 없는 글일 수 있다. 누군가에게 항상 보여주고, 누군가가 내 글을 보고 실망하지 않을까? 란 생각은 내 머릿속에 존재하지 않는다. 그냥 내가 모르는 거 정리하고, 이왕 정리하는 거라면 첨부터 끝까지 쭈욱 정리해 보는 것일 뿐이다. 내가 나중에 머리에서 기억하지 못하는 것이 생겼을 때 그냥 첨부터 보기 위함의 글이다.
생각보다 다시 보는 일은 없고, 구글 검색이나 StackOverflow를 통해 해결하지만.

블로그를 시작하려 한다면 최소한 이렇게 생각했으면 좋겠다.

• 누군가 내 글에 오류가 있다고 말하지 않을까?
  • 해주면 정말 감사하다.
  • 보통 그런 사람 없다.
• 남에 블로그를 보니 정말 잘 써야 하고 시간도 많이 든다.
  • 내가 스스로 공부하는데 들인 비용 중 일부가 아닐까?

 

GitHub 관리

블로그를 하면서 자연스럽게 github 관리를 한다. 아주 가끔이라도 최신 업데이트를 해두고, 리펙토링을 날 잡고 한다. 나에게 꾸준함이란 GitHub 관리는 포함하지 않는다. 보통 라이브러리 배포도 글을 써보고 싶고, 정리해두고 싶어서 하는 것이지 뭔가 이쁜 코드를 배포하고 이걸 설명하려고 하는 것은 아니다.

 

블로그든 GitHub이든

꾸준하게 하나라도 해보는 것을 추천은 하지만 그게 어렵다는 건 알고 있다. 그래서 가장 쉬운 방법은 누군가 써주는 것이 아니라 나라도 쓰고 나라도 이해하기 위함으로 시작하는 것이 가장 좋다. 취업하려고 블로그 한 적은 없다. 그냥 쌓아둔 데이터가 많아지니 누군가는 좋게 봐주고, 좋은 결과를 안겨주시니 감사할 따름.

 

멘토링

F-Lab에서 멘토링 활동을 하고 있는데 어느덧 2년이 흘렀다. 현재 진행하는 분을 포함해 5분의 멘티분들의 멘토링을 진행하였고, 모두 마친 3분은 최종합격까지 하고 회사를 다니고 있다.

당연히 모두 좋은 회사를 가고 싶어 한다. 네카라쿠배에 가고 싶어요.라고 한다. 그럼 어떠한 노력을 하고 있는지 질문한다. 그리고 현실적인 이야기를 조언한다. 가려면 어떤 친구들과 경쟁하는지와 같은. 그걸 알고 공부하라는 의미이다. 못 가는 것이 아니라 그것보다 더 노력하고 있다면 충분히 갈 수 있지만 그런 부분에 필요한 학습을 추가로 하라는 의미로 알려준다.

그리고 지금까지 내가 봤던 것은 그곳에 가지 않더라도, 내가 함께 하는 동료분은 그런 회사에서 오신 분일 수 도 있다. 오히려 더 좋은 것이 아닐까 싶다. 지금 당장은 그곳에 가서 일하지 못하지만 내가 함께 하는 동료분이 그런 큰 시스템을 경험해 보고 오신 분이라면 함께하더라도 충분히 좋은 경험이라고 생각한다.

F-Lab에 관심 있으시다면 아래 링크를 확인해 보시길, 개인적으로 진행했던 인터뷰도 있다.

F-Lab - 상위 1% 개발자들의 멘토링

 

코드리뷰

코드리뷰는 대학교 다닐 때 학교 선배로부터 배운 코드 리뷰 방식을 사용한다. 더 좋은 방식이 있으니 이것도 참고하라는 식의 코드 리뷰이다(그렇다고 내가 잘하는 것과는 거리가 멀다 여전히 코드 리뷰는 어렵다). 뭐 이걸 항상 하는 것은 아니지만 조금 더 발전 가능한 형태라 가급적 이런 방식으로 리뷰하려고 한다.

예를 들면 다음과 같다.

이 코드 진행 흐름상 이 코드가 맞는 것 같아요. 가 아닌 이 코드도 괜찮아 보이는데 이런 식으로도 작성해 보실 수 있을 것 같아요.

어차피 이렇게 쓰나 저렇게 쓰나 받아들이는 입장에선 둘 다 지적이라고 생각될 수 있다. 누구는 생각 못한 코드는 아닐 것이니 말이다. 그런데 코드 리뷰 자체란 서로 다름을 이해하는 것부터 시작인데, 사실 나도 이게 어렵다. 나도 잘 돌아가는 코드 누구가 저렇게 달았다고 하더라도, 지적이지 않을까 생각이 든다. 생각보다 이런 식으로 생각하는 거 어려운 거 알기 때문에 이런 식으로 접근하더라도 쉬운 것은 아님은 알고 있다.

 

이력서

이력서 쓰는 것이 가장 어렵다. 이력서 관련은 다음 글에서 참고해도 좋다.

이력서를 위한 이력 관리는 어떻게 하는 것이 좋을까? |

 

그렇다고 나의 이력서가 잘 쓴 것인가? 그렇지는 않다. 고연차가 많은 안드로이드 개발자들이 대부분 관심 있어 하는 내용은 상향 평준이라고 생각할 수 있는데 기술적인 관점에서 얼마나 많은 학습을 하였고, 기술적인 고민을 해보았나이지 않을까 싶다.

그래서 보통 이렇게 쓰는 것보단

• 계산기를 만들어보았습니다.

좀 더 구체적으로

• 컴포즈 UI 학습을 위해 계산기를 만들어보았습니다.
  View와 ViewModel을 통해 로직을 분리 학습하였습니다.
  Hilt를 통해 매뉴얼 주입을 하지 않도록 설계해 보았습니다.

어느 것이 좋을까는 당연히 후자겠지만 결론은 구체적으로 적어보라는 이야기다. 내가 열심히 한 프로젝트가 있는데 이를 잘못 표현해서 서류 탈락을 하는 것보다 이왕이면 최대한 적고, 개발 용어도 적어 어필하는 것이 필요하다.

가장 중요한 건 내가 하지 않은 작업을 했다고 표현하지는 말 것. 이력서 검토시간이 짧더라도 적힌 블로그 링크, 적힌 깃헙 주소, 다른 분들과 함께 한 프로젝트에서 정말 본인이 한 것인지 사람들은 확인한다는 것이다. 깃 이력까지 확인하여 정말 본인이 한 것인지 꼼꼼히 확인해 주신다. 그러니 거짓말 쓰지 말 것. 어차피 이력서든 면접이든 최소한 안 한 것을 했다는 것은 금방 탈로 난다.

 

이 글의 의미?

의미는 없다. 그냥 지금까지 나란 사람이 생각해 본 것을 적은 것일 뿐이다.

이제까지 작성했던 글이 누군가에게는 매우 도움이 되었다면 감사한 것이고, 와서 인사도 해주신다면 더 좋은 것이다. 그 인사도 상대방이 날 알아보고 쉽게 하는 것이 아니란 것도 안다. 나도 그렇게 가서 인사를 하지는 않으니 말이다.

커피챗을 요청하면 쉽게 Yes 하는 편이다. 그 말에 도달하기까지 얼마나 많은 고민을 해봤을지 알고 있다. 나조차도 하지 않는데 그게 그렇게 쉬운 생각이 아님을 안다.

이게 누군가가 특별해서가 아니며, 내가 특별해서 커피챗을 Yes 하는 것이 아니다. 누군가에게 도움이 될 수 있는 이야기를 전달해 주고 이왕이면 얼굴도 보고 이야기해 볼 수 있는, 그것만으로도 충분히 좋은 커피챗이 아닐까 싶다.

 

더 성장하기

더 성장하려면 어떻게 해야할까? 이에 대한 답은 이 글의 처음에 적었다고 생각한다. 자만하지 말고, 적당히 못하지도 않고, 배우고 내가 모르는 부분 계속 끝없이 배우고, 내가 안다고 모든 걸 아는 것은 아니다. 상황에 따라 다른 상황이 나온다. 이론을 아무리 많이 안다고 해도 모든 케이스에 적합할까? 그건 아니다.

다른 사람들의 발표를 들어보면 또 다른 해답이 존재한다. 그 내용이 내가 모두 다 아는것이라도 한들 발표 해주신 분 덕에 내가 아는 거 잘 학습했구나를 검증할 수도 있으며, 10개 중에 9개는 아는 것인데 1개는 새로운 사실을 알 수도 있다.

 

추가로 이건...

기억법?

나의 기억법은 그림을 통해 이루어진다. 내가 가장 사람들에게 미안한 부분은 사람을 여러 번 만나야 이름을 기억한다는 것이다. 텍스트 기억력이 좋지 않다. 그래서 보통 얼굴을 기억하고, 그림으로 기억하려고 한다. 그림을 통해 추론하는 형태의 기억법을 사용한다.

이렇게 하면 개발에서 매우 재미있는데 팩토리 패턴을 매우 좋아한다. 팩토리 형태의 코드를 잘 조합하면 하나 뚝딱 나온다. 이런 상상력 풍부한 개발법은 그림이 많은 클라 개발자로서 재미있다.

 

공부법?

지금까지 90%는 회사에서 일하면서 습득하면서 이 내용이 너무 아까우니 다시 정리하는 것일 뿐이다. 당연히 회사와 관련한 코드는 없다. 그때 찾았던 블로그, 샘플 코드를 다시 기억해 다시 정리한다. 아무리 회사에서 학습하고 습득한 내용이라도 내가 다시 봤을 때를 기준으로 평범하게 정리한다. 그러면서 더 좋은 코드도 만들고 다음에 실수의 횟수를 줄여간다.

그래서 별도로 블로그와 샘플 코드를 작성해 공유한다.

failbook.dev 도메인 사두고 뭔가 하지는 못하는데, 언제 활성화할 것인가.

fail < 실패를 답습하지 않기 위한 book으로 도메인을 샀지만 아직 아무것도 없다.