최고의 개발자가 되는 방법이라니.. 최고의 개발자란 무엇인가?
5년 차 개발자가 쓴 최고의 개발자가 되는 방법입니다.
지금까지 경험했던 실수와 그로 인해 얻었던 지식을 바탕으로 공유하는 글입니다.
여기에 제 경험을 녹여 함께 작성해보고자 합니다.
1. 개발 관련 개념 배우기
개념을 배우는 것과 문법을 배우는 것은 다릅니다.
면접을 생각해보면 답이 나옵니다. 우리에게 문법을 물어보지 않습니다. 해당 언어가 가지고 있는 개념을 물어봅니다. 즉, 우리는 개발과 관련하여 개념을 배워야 합니다. 개념을 익히면 다른 언어에서도 사용할 수 있습니다.
OOP 개념은 관련 모든 언어에 동일하게 적용됩니다. Java, C#은 비슷하다는 말을 많이 듣는 언어입니다. 비슷하다는 가장 큰 이유는 OOP 개념 때문입니다. OOP를 적용한 다른 언어도 Java나 C# 한 가지만 알아도 금방 적응할 수 있습니다.
우리는 암기할 코드가 매우 많습니다. 문법은 계속해서 나오고, 다양한 기능과 라이브러리 문법들이 나옵니다. 이걸 외우려 하지 말고, 동작하는 방식을 이해하고, 외우세요. 그러면 중요한 프로젝트를 만들 때 금방 찾아서 적용할 수 있습니다.
예시 개념 목록입니다.
- OOP(객체 지향 프로그래밍)
- DDD
- 시스템 디자인
- 동기화 대 비동기화
- 버전 관리
- 자료구조와 알고리즘
- 등등
우리가 위와 같은 개념들을 먼저 배워야 하는 이유는 어떤 언어를 사용하고, 어떤 프레임워크를 사용하더라도 활용 가능하기 때문입니다. 하나의 메인 언어와 프레임워크를 공부하면서 다양한 언어에서 사용하는 개념을 공부해야 합니다.
2. 주석 사용 및 깨끗한 코드 작성
간혹 어려운 코드를 작성하면 좋은 코드라고 착각하시는 분들이 있습니다. 이해하기 어려운 코드는 유지하기가 어렵습니다. 특히, 다른 사람이 보기 힘든 코드를 작성하면, 개발자 사이에서 이야기가 돌 수 있습니다.
왜냐하면 함께 협업하는데 자기 자신만 아는 코드를 작성하면 다른 프로젝트에서 배제시키기 때문입니다. 이 글을 읽는 독자가 혹시 내 코드가 너무 쉬워서 다른 사람으로 대체되면 어쩌지?라는 생각을 가지고 있다면 걱정 안 하셔도 됩니다. 다른 모든 개발자 분들이 당신을 원하기 때문이죠. 깔끔하고, 주석도 알기 쉽게 작성하는 개발자를 싫어하는 사람은 없습니다.
처음 깨끗한 코드를 작성하다 보면 익숙하지 않아 오래 걸릴 수 있습니다. 하지만 다시 유지보수를 위해 코드를 보면 그때 쓴 시간이 헛된 시간이 아니라는 것을 알 수 있습니다. 쉽게 읽히고, 좋은 글처럼 술술 읽히는 코드는 개발자가 가져야 할 최고의 자질입니다.
사실 깨끗한 코드와 주석 사용에 가장 큰 이유는 버그를 잡기 쉽기 때문입니다. 어디서 버그가 발생한다면 그것을 찾는데 많은 시간을 써야 합니다. 깨끗한 코드는 그 시간을 엄청나게 줄여줍니다. 디버깅 능력이 중요한 개발자에게 깨끗한 코드는 더욱 날개를 달아줍니다.
3. 좋은 원칙 습득 및 실천
클린 코드 작성과 유사하게 좋은 원칙을 구축하면 불필요한 작업을 줄일 수 있습니다. 앞서 말한 깨끗한 코드 작성과 일맥상통합니다. 결국, 우리는 유지보수하기 좋고, 남들이 보기 좋은 코드를 짜야한다고 귀결됩니다.
좋은 원칙들은 깨끗한 코드 작성법에 대한 가이드를 안내해줍니다.
다양한 원칙들이 있지만 아래 원칙들은 꼭 지켜줍시다.
- K.I.S.S(단순하고 알기 쉽게 유지하라)
- D.R.Y(복사 붙여 넣기를 통한 자가 복제 금지)
- 질문이 있을 땐 망설이지 말고 하자
- 하드코딩 금지
- 의미를 알 수 없는 매직 넘버 사용 금지
좋은 원칙은 면접에서도 유리합니다. 많은 개발자들은 좋은 원칙을 사용하는 개발자를 좋아합니다. 2번과 동일한 이유입니다. 함께 일하는 개발자가 자기만 아는 코드를 작성하면 머리가 아픕니다. 이해하는데 오래 걸리고 해당 개발자가 휴가라도 가면 대응이 매우 어렵습니다. 그렇기 때문에 우리는 좋은 원칙으로 좋은 코드를 작성해야 합니다.
원칙을 지키는 것은 쉽지 않습니다. 노력을 통해 원칙을 지키기 시작하면 성장된 자신의 모습을 볼 수 있습니다.
4. 버그의 최소화. 최대한 많은 테스트를 진행해야 합니다.
모든 것을 테스트 하자.
모든 것을 디버깅해야 한다.
버그가 발생할 수 있습니다. 버그가 사용자가 발생시키면 원치 않은 방향으로 문제가 생길 수 있습니다.
해킹의 시작은 버그에서 시작됩니다. 기본적인 버그는 테스트와 디버깅을 통해 초반에 잡아야 합니다.
특히, 사용자가 돈을 지불한 프로세스에서 버그가 발생하면 돌이킬 수 없는 사태가 발생합니다.
애플리케이션에 대한 신뢰도가 깨지면 사용자는 전부 이탈합니다.
은행 사이트를 이용하다가 돈을 잃게 된다면 어떤 기분일지 생각해보죠. 돈을 이체했지만 오류로 인해 돈이 사라진다면 어떤 기분이 들까요? 우리는 귀찮은 테스트를 전부 해야 한다는 것을 알 수 있습니다.
제가 게임 회사에서 일했을 때 하나의 버그로 많은 사용자가 불편을 겪은 것을 옆에서 본 적이 있습니다. 개발자 입장에서는 사소한 에러였지만 그로 인해 이탈한 유저수는 무시할 수 없는 숫자였습니다. 개발자는 기본에 충실해야 하지만 경험도 많아야 합니다. 다양한 경험에서 얻는 체크 리스트는 중요한 자산이 됩니다. 그 이후 해당 개발팀은 체크 리스트가 정교해지고 동일한 이슈는 발생하지 않았습니다.
우리는 서비스를 이용할 때 잠깐의 오류에도 불쾌한 경험을 겪습니다. 이 글을 보는 사람들은 더욱이 개발자로서 누가 이따위로 만들었을까?라고 생각한 애플리케이션을 본 적이 없으신가요? 서비스를 이용하다가 그런 상황이 발생했을 때 불쾌감을 기억한다면 버그는 사용자까지 안 가야 합니다.
5. 프로젝트를 꼭 완성하기. 새로운 것을 자꾸 도전하지 않기
이것은 필자도 많이 실수했던 항목입니다. 필자는 새로운 도전을 좋아합니다. 새로운 기술을 사용하기 좋아하고, 새로운 것을 만드는 것이 즐겁습니다. 그러다 보니 완성된 작품을 만드는 것이 얼마나 어려운지를 잘 몰랐었습니다.
과거 회사에서 만든 프로젝트를 시간과 노력을 갈아 넣어 완성했을 때, 소프트웨어 제품 하나를 만드는 것은 쉽지 않다는 것을 깨달았습니다. 완성된 프로그램은 제대로 동작했고, 그것이 다양한 서비스를 제공하면서 많은 이득을 소비자에게 제공했습니다.
개발자를 고용하는 고용주는 개발자가 프로젝트를 완성하기를 기대합니다. 우리가 부족하게 코딩하더라도 시간 내에 프로젝트를 “완성” 한다면 좋은 개발자라 생각합니다. 여기에 버그가 없다면 말이죠. 우리가 시간상 이슈로 기능을 많이 만들지 못하더라도 완성을 시켜준 개발자를 신뢰합니다. 우리가 고용된 가장 큰 이유이기도 합니다.
사이드 프로젝트를 진행할 때도 완성을 목표로 해야 합니다. 그다음에 기능들을 하나씩 추가하는 방식으로 작업해야 합니다. 1 ~ 4번까지의 조언을 기억하면서 프로젝트를 견고하게 다져야 합니다. 그렇게 쌓여간 하나의 프로젝트는 여러분의 좋은 포트폴리오가 됩니다.
꼭 기억하세요. 새로운 프로젝트가 개발자의 실력을 올리지 않습니다. 프로젝트를 마무리하면서 많은 것을 배웁니다. 그리고 이력에도 크게 남길 수 있습니다. 여러분은 프로젝트를 완성해 본 경험을 가졌기 때문입니다.
6. Structure를 따르자.
큰 프로젝트를 시작할 때 우리는 구조를 잡고 시작을 합니다. 구조는 다양한 가능성을 두고 결합도를 낮추고, 응집도를 높여줍니다. 즉, 좋은 설계를 따라가야 합니다. 프로젝트를 진행하기 전에 설계를 하는 이유는 앞서 말한 2,3번의 이유 때문입니다.
초보 개발자는 이러한 구조가 어렵게 느껴질 수 있습니다. 이것도 다양한 경험과 지식을 쌓아야 가능한 영역입니다. 즉, 계속 공부하고, 경험하면 늘어나는 스킬입니다. 작은 프로젝트를 진행할 때는 이러한 구조 세우는 게 귀찮을 수 있습니다. 구조를 세우는 걸 연습하다 보면 큰 프로젝트를 진행할 때 매우 편합니다. 하나의 기준점을 만들고 코드만 작성하면 되기 때문입니다.
우리가 코드를 작성할 때 가장 힘든 것은 방향성을 잡는 것입니다. 사용자가 어떤 요구사항을 요청할지 모르기 때문에 어떻게 작성해야 추후 유지보수를 줄일 수 있는지 고민합니다. 이것은 중급 이상의 개발자가 된다면 가장 많이 하는 고민입니다. 필자 주변의 개발자들도 이런 고민이 많습니다.
그러면 어떻게 공부해야할까요? 다른 사람들이 프로젝트를 진행한 후기와 그들이 설계한 설계도를 많이 봐야합니다. 왜 이렇게 구성했고, 어떤 결과물이 나왔는지 많이 본다면 여러분의 프로젝트에도 적용할 수 있게 됩니다.
좋은 오픈소스 코드를 보는 이유가 여기에 있습니다. 어떤 Structure를 활용했고, 왜 사용했는지, 어떤 이슈가 있는지를 확인하면서 추후 비슷한 문제를 직면했을 때 빠르게 구조를 잡을 수 있습니다. 쉽지 않지만, 해냈을 때 얻는 이익은 상상을 초월합니다.
결론
최고의 개발자가 되는 방법에 대해 적어봤습니다.
배달의 민족 CEO이신 김범준 대표님이 이야기했던 말입니다.
“개발자는 우리에게 주어진 비즈니스 문제를 해결하는 사람이다.”
비즈니스 문제를 해결하기 위해 우리는 코딩만 하는 사람이 아닌 문제를 해결해야 합니다. 사람들이 원하는 해결 방법을 제시하기 위해 프로젝트를 꼭 완성해야 하고, 완성된 프로젝트에는 버그가 없어야 하며, 마지막으로 완성된 좋은 프로젝트를 위해 프로젝트 구조를 세워야 합니다.
위에 나온 이야기는 이제 막 코딩을 배우는 개발자 지망생에게는 바로 와닿지는 않습니다. 하지만 미래에 좋은 개발자가 되기 위해서 어떤 것들이 중요한지 미리 알 수 있는 내용입니다. 그리고 좋은 개발자는 많은 사람들이 가진 소프트웨어와 관련된 문제를 해결하는 해결사가 된다는 것을 알 수 있습니다. 이것은 미래에 내가 어떤 사람이 될지 꿈을 가질 수 있다는 것을 의미합니다.
좋은 개발자가 되어 해결사가 되십시오.
감사합니다.
보면 좋은 글
참고