coding

Software Engineer

seanlab

May 2, 2022 • 6 min read

어느 덧 시니어 (나이가 많다는 뜻) 엔지니어가 되었는데.

별로 한 일도 없이 평범한 삶을 살다가 나이를 먹어 버려서, 이 나이 먹도록 가진 것도 이룬 것도 없는 것 같아 서글픕니다.
그래도 나이를 먹어서 좋은 게 있긴 해요. 어릴 땐 세상을 넘어야 할 산 또는 이겨야 할 적으로 보고 항상 전투적으로 살았던 것 같은데 (그렇다고 열심히 산 건 아니고 성질만 더럽게 굴었던 것 같지만), 이런 저런 일 겪고 나니 그래도 철이 좀 든 것 같아요. 후배 엔지니어 분들을 보면 제가 도와줄 수 있는 게 조금은 있겠다 싶을 때가 많더라구요. 요즘은, 이런 말 하기 좀 주제넘는 것 같긴 하지만, 후배 엔지니어님들을 보면 귀여워요 :D

가끔 제게 조언을 구하는 분들이 있는데, 제가 조언을 할만한 사람은 못되지만 혹 하나라도 건지실 게 있을까 하여 일천한 제 생각을 두서없이 말씀드려 보면,

젊었을 때, 특히 학생 때, 이것 저것 많이 접해보고 배워 보시면 좋을 것 같아요. 그런 게 습관이 되면 나이 먹어서도 배우는 게 어렵지 않은 것 같아요.
다른 사람한테서 많이 배우려고 해 보세요. 그러려면 열린 마음으로 피드백을 수용하는 자세가 필요한 것 같아요. 십 몇 년을 공부나 일을 해도 별로 발전이 없는 사람이 의외로 많아요. 단지 책 하나 더 읽는다고, 툴 하나 더 쓸 줄 안다고 수준이 올라가는 게 아니에요 (툴도 중요하긴 해요. 저는 Vim과 Git을 잘 써서 코드 만지기가 참 편해요. 프로파일러, 그리고 코드를 어셈블리 혹은 바이트코드 레벨에서 볼 수 있는 도구들도 도움 많이 돼요. lint 및 static analyzer들은 commit 하기 전에 꼭 패스되도록 해야 하고요). 열려 있어야 발전을 하지, 자기 스스로 장벽을 쳐 놓으면 그것을 outgrow할 수 없잖아요. 엔지니어는 꾸준히 발전하지 않으면 나중에 커리어가 꼬일 수 있어요. 여기서 발전이란 건 하드 스킬은 물론이고 소프트 스킬을 기르는 것까지 포함하는 거에요.
그렇다고 남의 말을 다 믿으면 안돼요. 치열하게 고민해 보세요.
우수한 사람들이 주변에 많이 있는 게 좋아요. 그러려면 좋은 집단에 들어가는 게 유리해요. 좋은 집단에 들어가면 물론 남들 보기에도 멋져 보이고 돈도 많이 받고 job security도 높아지고 나중에 딴 데 가기도 좋지만, 가장 중요한 점은 좋은 것들을 배울 수 있다는 게 아닐까 싶어요.
실제로 출시하거나 양산하는 프로젝트를 일찍부터 해 보는 게 좋은 것 같아요. 프로덕션은 proof of concept(컨셉증명)나 prototype(프로토타입)등과는 많이 달라요.
MSA(Micro Service Architecture)같은 유행어 너무 신경 안써도 되는 것 같아요. MSA 얘기 하는 사람 중 그게 뭔지 잘 아는 사람 별로 없는 것 같더라고요. 그게 정말 뭔지 안다면, 여러분의 프로젝트에 그게 별 도움 안 된다는 걸 깨닫게 될 확률이 높아요.
동료끼리 코드 리뷰를 필수적으로 하도록 강제하면 배우는 게 많을 거에요. 설령 내가 동료보다 잘하는 경우라도. Github 등에 온라인 코드 리뷰 툴 다 있잖아요.
코딩 스타일 가이드는 정해 놓고 하세요. 스타일 가이드 안 지킨 코드는 리뷰어가 approve(승인)하시면 안돼요. 첨엔 힘들어도 몇 번 해 보면 나중엔 빨라져요. 스타일 가이드가 없거나 너무 허술하면 구글에서 공개한 것 가져다가 쓰세요.
객체지향이나 방법론(methodologies)에 대해 썰을 푸는 종교 서적을 읽는다든지 스타 강사를 찾아다닌다든지 하는 일은, 정 하고 싶으면 스타일 가이드 완벽하게 지키게 되고 코드 리뷰 문화에 익숙해진 다음에 생각해 보세요. 우리가 해야 할 일은 원하는 대로 잘 작동하는 코드를 깔끔하게 작성하는 거지, 책 저자나 컨설턴트나 강사들 돈 벌게 해 주는 게 아니에요.

제가 어디서 뭐 하는지 아시는 분은, 댓글에 그런 얘기가 드러나지 않게 해 주세요.

출처:

Sign up for more like this.