brunch

매거진 SW업계 안내서

라이킷 9 댓글 2

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Extreme Code Mar 07. 2020

개발자가 염두에 둬야할 것 들

SW 업계에 처음 발을 들여놓는 사람들을 위한 안내

마지막 글을 쓴 후, 대기업을 떠나 새로 일을 시작하며 많이 바쁘게 지내다 보니 브런치에 글을 썼다는 것을 잊고 있었습니다. 오랫만에 메일을 확인해 보니 많은 상담 메일이 와 있었습니다. 이미 시간이 오래 지나버린 것들이 많아서 일일이 답장을 못 해드려서 지금이라도 죄송하다고 말씀드리고 싶네요. (혹시 상담 메일 보내시면 앞으로는 최선을 다해서 답장 해 드리도록 하겠습니다.)

저번에 몇 개의 SW 업계 취업을 위한 팁이나 개발 분야 등에 관해서 글을 썼는데요, 이번에는 제가 그동안 일 하면서 느꼈던 점들에 대해서 써 볼까 합니다. 이번에도 그냥 두서 없이 의식의 흐름대로 써 보겠습니다.

1. Toy project와 실제 서비스는 다르다

개발자들은 호기심이 많습니다. 열정도 많습니다. 그래서 여러 가지 기술을 배우고 시도 해 봅니다. 물론, 이것은 뛰어난 개발자가 되기 위해서는 필수적인 자질입니다. 보통 개발자가 새로운 기술을 배울 때는 책이나 블로그, 튜토리얼 페이지, 인터넷 강의 등을 보고 뭔가를 해 보게 됩니다. 뭔가 새로운 라이브러리가 나오거나, 새로운 알고리즘, 모델이 나올 때도 마찬가지이죠. 어느 정도 익히고 나면 toy project를 만들게 됩니다.

toy project를 만드는 것은 가장 빠르게 실력을 높일 수 있는 방법 중 하나이고, 제가 주니어 개발자들을 멘토링 할 때도 많이 사용하는 방법입니다. 새로운 기술 습득을 위해서는 가장 효율적이고 좋은 방법이라고 생각하는데요, 여기서 주의할 점은 toy project 만으로 자신이 이 기술을 습득했다고 생각하면 안된다는 점입니다.

toy project 형태의 서비스를, 실제 서비스로 만드려면 무엇이 더 필요할까요? 오토스케일링, 로깅, 복구 프로세스, 보안, 인증, 배포, 개발/테스트 환경 구축, 모니터링, 최적화, 운영 등등 정말 많은 것들을 고려해야 합니다. 한마디로 toy project 와 실제 서비스를 만드는 것은 차원이 다른 문제입니다. 실제로 여러 유저들이 사용하는 서비스를 만들 때 노력이 100이 든다면, toy project 를 만드는데 드는 노력은 5~10 정도 밖에 안 될 것입니다. (경우에 따라 다르겠지만)

따라서, toy project 정도 만들어 봤다고 다 아는 것처럼 떠벌려서는 안 되며, 항상 겸손하게 그 기술의 내부에 관해서 깊이 파고 들어가는 자세가 필요합니다. 그 기술을 안다고 말하려면, 자신이 내부 코드와 기술을 대부분 이해하고 해당 기술을 수정해서 새로운 걸 만들 수 있는 정도까지를 의미합니다.

2. 오픈소스/신기술 활용은 신중하게

지금은 오픈소스 시대입니다. 웬만한 기능은 모두 오픈소스로 공개가 되어 있습니다. 근데 실제 서비스에 오픈소스를 적용하는 것은 신중히 생각해야 할 문제입니다. github star 가 매우 많은 오픈소스도 보안에 문제가 있거나 빌드가 깨지는 경우가 많고, 안정성이 떨어지는 경우도 많습니다.

오픈소스는 절대로 공짜가 아닙니다. 복잡도가 높아지는 프로그램을 만들다 보면, 해당 오픈소스에서 지원 안 하는 기능을 구현하거나, 처음 보는 문제가 생길 수 있습니다. 안정성이 많이 검증되지 않은 오픈소스를 사용하게 된다면 troubleshooting 정보가 적기 때문에 stackoverflow든, google이든, github issue든 아무리 검색해도 문제가 생겼을 때 관련 정보가 안나올 수 있습니다. 그런 경우 직접 오픈소스 내부 코드를 수정해야 할 수도 있으므로, 만일 사용하려면 확실히 아는 것이 좋습니다. 즉, 좋은 기술은 열심히 익히고 공부하되, 무조건적으로 그걸 사용하는 것은 지양해야 합니다.

괜히 큰 회사들이 old tech 라고 불리는 보수적인 tech stack을 고집하는 것이 아닙니다. 누군가는 꼰대같다고 말할 수도 있겠지만 (실제로 회사 규모가 클수록 꼰대들이 많긴 합니다 ㅋㅋ) 새로운 라이브러리나 기술을 사용하는 것은 그만큼 리스크도 굉장히 커지기 때문에 troubleshooting 정보들이 잘 공유되거나 안정성이 검증된 기술을 사용하는 것입니다.

3. 반복 업무는 최대한 줄이자

개발자라면 계속해서 반복되는 업무는 최대한 자동화를 해야 합니다. 그래야 더 중요한 일에 집중할 수 있고, 공부할 수 있는 시간도 더 낼 수 있기 때문입니다. 자동화라 함은 정적/동적 분석, 테스팅, CI/CD, 모니터링 등 여러가지 이슈가 섞여 있는 것이긴 한데요, 제가 강조하고 싶은 것은 어떠한 것이든 반복되는 업무가 있다면 최대한 자동화를 할 수 있도록 노력하라는 것입니다.

자동화를 위해선 여러가지 업무 생산성 향상 툴을 쓸 수도 있겠지만, 커스터마이징이 잘 안 되거나 회사에서 구매해 주지 않는 경우라면, 직접 업무를 자동화 하는 프로그램을 만들 수도 있을 것입니다. 자동화를 하는 프로그램을 가능할 때마다 만들면 여러 가지 장점이 있습니다.

- 자동화 프로그램을 만들며 실력 향상을 할 수 있습니다.

- 반복된 일을 줄여서 업무 생산성을 높일 수 있습니다.

- 다른 개발자들 보다 돋보일 수 있습니다.

이 외에도 여러 가지가 있었던 것 같은데, 또 생각나면 업데이트 하겠습니다. 추가로 궁금하신 내용이 있으시면 메일로 문의 주시면, 시간이 가능하다면 답변 드리겠습니다.

keyword