개발자 준비생들을 위한 조언

저는 올해로 12년 차 개발자입니다.

최근 어떤 계기로 사회에 진출하려는 분들의 고민을 듣게 되었고 조금이나마 도움이 되고자 글을 씁니다.

 

개발자를 위한 조언은 여기저기서 쉽게 얻을 수 있지만,

정보는 많을수록 좋으므로 오늘 그 주제에 하나의 글을 더 추가하려 합니다.

이 역시 개인적인 의견이므로 참고만 하시길 바랍니다. 

 

1. 백문이 불여일타

 

일단, 많이 만들어봐야 합니다.

거창한 거 말고 할 수 있는 것부터 만들어보세요.

아주 간단한 거라도 괜찮습니다.

 

저는 대학 때 게임 제작 동아리에서 활동했습니다.

숫자 3,6,9 게임 같은 것을 시작으로 테트리스도 직접 만들어봤습니다.

나중에는 비행 슈팅 게임도 만들게 되었습니다.

 

물론, 결과물 자체만 보면 하찮죠. 이미 흔한 것이고요.

훈련에 의미를 둬야 합니다.

아무리 흔한 프로그램이어도 본인이 스스로 만들어보면 그렇게 폄하하지 못할 것입니다.

 

사소한 거라도 완전한 소프트웨어를 만들어보는 것이 중요합니다.

코드가 공개되어있는 것이라면, 일단 보지 말고 만들어보시길 권합니다.

그리고 나중에 자신의 코드와 비교를 해보세요.

처음부터 보고 하는 것과 깨달음의 정도가 다릅니다.

 

2. 본질에 집중합시다.

 

특히, 학원 같은 교육기관에서 개발을 배운 분들께 꼭 드리고 싶은 조언입니다.

특정 기관을 폄하할 의도는 아닙니다.

 

각 교육기관은 목적이 있고,

대체로 교육기간이 4년제 대학처럼 길지 않으면, 시간상 깊이 있게 들어가기가 어렵다는 점을 이야기하는 것입니다.

빠르게, 실용적인 부분을 익히게 해야 하므로, 실무위주로 이야기를 할 수밖에 없다는 것입니다.

그래서 스스로 깊게 생각해보지 않으면 사용법만 익히고 취업을 준비해야 될 수도 있습니다.

 

본질에 집중하라는 것은, 끊임없이 의문을 가지라는 말과 상통합니다.

예를 들어, 웹 서비스 개발을 배운다고 해봅시다.

스프링 부트를 이용해서 어찌어찌 돌아가는 서비스를 만들었습니다! 기분이 매우 좋죠.

그럼 여기에 함의되어있는 모든 것을 알게 된 것일까요?

 

예를 들면, 이런 의문들입니다.

> http 는 어떻게 동작할까? 네트워크상으로 어떤 정보들이 흐르는가?

> 지금 상황에서 요청이 더 많아지면 어떤 문제가 생길까?

> 스프링 부트 외에 웹 서비스 개발을 편하게 해주는 것에는 어떤 것들이 있을까?

> 다른 언어에서 대표적으로 사용되는 프레임워크와는 어떤 차이점이 있을까?

> 근데 프레임워크는 뭐지?

 

질문에 답은 어느 정도 정해져 있지만, 질문 자체에는 정답이 없습니다.

호기심과 의구심을 가지고 자신이 만들어가는 것을 지켜보면 꼬리에 꼬리를 물고 떠오를 것입니다.

귀찮을 수도 있지만 호기심의 끈을 놓지 말고 한 번 따라가 보세요.

 

열혈강호라는 만화가 있습니다.

주인공은 상대방의 기술을 흉내 낼 수 있는 엄청난 재능이 있습니다.

자신만 아는 무공인데, 주인공이 자신과 똑같은 공격을 해오면 상대는 당황하는 것이죠.

그런데 이는 고수에게는 통하지 않습니다.

나중에는 주인공도 그것이 의미 없는 동작뿐이었음을 알게 되죠.

 

본질을 잘 모르고 흉내만 내는 것은 금방 깨지기 쉽다는 점을 말하고 싶습니다.

 

왜 이게 중요할까요?

그건 앞으로 만나야 할 상대(기술)가 너무나 많기 때문입니다.

아시다시피 이쪽은 변화가 심한 편입니다. 

그런데 기본기가 잘 되어있으면 앞으로 만나는 상대를 대하기가 수월합니다.

저는 "추론 능력이 훈련된다" 고 표현해보겠습니다.

 

"아, 여기도 이게 필요할 테니 여기 가면 있겠군. 이건 아마 이렇게 동작하지 않을까? 맞구만"

 

이렇게 되면 훈련이 되어있지 않은 상태보다 빠르고 멀리 갈 수 있다고 생각합니다.

 

그러므로, 본질에 집중하세요.

 

3. 포기하지 마세요

 

개발자의 길을 포기하지 말라, 이런 거창한 의미가 아닙니다.

개발을 하다 보면 아주 사소한 갈등을 포함한 수많은 내적 갈등을 마주하게 됩니다.

저 같은 경우에는 특히 코드의 품질면에서 그렇습니다.

 

> 메소드 이름이 좀 구린데

> 이거 메소드가 너무 긴 거 아닌가?

> 여기서 이걸 처리하는 게 맞는 걸까?

> 여기서 이 사실을 알아야 할 필요가 있나?

 

할 수 있는 최대한, 

적어도 지금 본인의 마음에는 찜찜함이 없도록 노력해보세요.

나중에 실력이 늘면 초라해 보일 수 있지만, 적어도 지금 이 순간에 그런 마음이 들지 않아야 합니다.

간절할수록 공부도 많이 하게 되겠죠. 패턴이나 리팩토링 책을 찾아보게 됩니다.

 

아주 귀찮은 일이 될 수 있습니다.

저도 완벽하게 잘한다고 말할 수는 없네요.

하지만 이런 노력이 쌓이면 나중에는 큰 보상으로 돌아올 것입니다.

 

4. 문제 해결 능력을 길러볼까요?

 

hackerrank, leetcode 등 문제 해결 능력을 연습할 수 있는 곳은 꽤 있습니다.

쉬운 문제부터 하나씩 해결해봅시다.

 

기업에서 코딩 테스트를 치기 때문에 연습하라는 것이 아닙니다.

물론, 코딩 테스트 통과도 중요하죠. 그런데 그것이 목적이 되어서는 안 됩니다.

목적은 문제 해결 능력 향상에 있어야 합니다.

 

왜 저런 문제들이 도움이 될까요?

 

먼저, 다양한 입력 값이 존재합니다.

보통 직관적으로 생각할 수 있는 입력 값이 대부분이겠지만, 

아주 크거나 직관적으로는 예상하기 힘든 입력(엣지 케이스)이 주어질 수 있습니다.

실제 서비스에서도 이런 일은 많이 일어납니다. 

 

다음으로, 효율적인 코드를 짜도록 합니다.

엣지 케이스들은 모두 커버하지만 시간이 오래 걸리는 경우가 있습니다.

이럴 때는 다른 전략을 써야 합니다. 그것은 작은 개선일 수도 있고 특정 알고리즘 기법을 이용해야 할 수도 있습니다.

이 역시 실제 업무에서 필요합니다. (난해한 알고리즘을 의미하는 것은 아닙니다.)

 

문제 해결 능력이 좋으면, 다소 어려워 보이는 요청도 처리할 수 있게 되고, 당연히 인정도 더 받게 되겠죠.

 

그러니, 현실 세계의 축소판이라 생각하시고 풀어보시길 바랍니다.

(꼭 이런 목적이 아니더라도 풀다 보면 재미가 꽤 쏠쏠합니다.)

 

5. 이제 지원을 해볼까요?!

 

여러 준비를 거쳐 이제 현업에 뛰어들 준비가 되었습니다.

지원하는 회사에서 요구하는 다양한 것들이 있을 텐데요.

저는 딱 한 가지만 이야기하고 싶습니다.

 

바로 자기소개서입니다.

 

당연하게 여겨지시죠?

많은 지원서를 보게 되는데 의외로 글을 잘 쓰는 분은 찾아보기가 쉽지 않습니다.

 

자기소개서의 전체적인 맥락은

"내가 왜 뽑혀야 하는가? 내가 입사하면 어떤 기여를 할 수 있는가?" 여야 합니다.

이 핵심 맥락을 중심으로 자신의 경험과 지원 동기 등을 곁들여야 하는 것입니다.

경험도 없는데 무슨 기여? 라고 할 수도 있겠지만, 지원 동기에서 그 부분을 잘 어필할 수도 있습니다.

 

비슷한 내용을 한 번 작성해서 여러 부서에 지원하는 분들도 계실 텐데요.

과연 그런 지원서에서 진심이 느껴질까요?

 

또 한 가지 이야기하고 싶은 것은,

잘 설명할 수 없는 경험은 지원서에 없느니만 못하다는 것입니다.

지원서에 작성한 내용은 당연히 질문 리스트에 포함이 되고, 충분한 답변을 기대하게 됩니다.

그리고 질문하는 사람은 현업에서 상당한 경험을 쌓은 실력자들입니다.

그러니 충분히 대답할 수 없는 것들, 자신이 크게 기여하지 않은 부분들은 적지 않는 것이 좋습니다.

오히려 어떤 부분에서 어떤 역할을 했는지 뚜렷이 적는 것이 도움이 됩니다.

 

마지막으로,

지원서를 다 작성했고, 퇴고까지 끝났다면, 맞춤법 검사기를 돌려보세요.

포털에 맞춤법 검사기가 있고, 블로그 서비스에도 기능이 들어가 있으니 어려운 일이 아닙니다.

 

지원서 쓴 지가 꽤 되었지만, 저는 이런 과정을 거쳤습니다.

 

1. 지원서를 쓴다.

2. 다음날 다시 본다. 수정한다. (퇴고)

3. 맞춤법 검사 및 어색한 표현 점검

4. 제출!

---

 

쓰고 나니 처음에 생각한 것보다 꽤 길군요.

모쪼록 좋은 개발자가 되는데 도움이 되었으면 합니다.

 

감사합니다.