일단 환영합니다. 좋은 선택을 한 거예요. 여기가 기회의 땅입니다. 여러분의 숨겨진 재능을 발견할 기회이기도 하고, 좋은 직업을 찾을 기회이기도 하고, 여러분의 영향력이 다른 사람에게 닿는 것을 느끼는 기회이기도 하고, 결국 세상을 바꿀 수 있는 기회이기도 합니다.

 

물론 백만 가지 이유로 소프트웨어 개발 영역을 떠날 수도 있습니다. 그때도 여러분은 빈손이 아닐 것입니다. 그래서 여기가 기회의 땅입니다.

(Jordan Messenger from Gold Coast, AU, CC BY-SA 2.0)

 

이 글은 소프트웨어 개발 동네에 처음으로 발을 들이신 분들을 위한 글입니다. 처음이라 함은 아직 여러분이 만든 소프트웨어로 규모가 있는 사용자를 경험하지 않은 상태를 의미합니다. 아직 배우고 있는 분들, 신입 수준으로 개발자의 경력을 시작하는 분이 해당됩니다. ‘배우고 있는 분‘ 가운데 아직 어떤 프로그래밍 언어의 문법 에러 때문에 힘들거나 좌절하고 있는 분들은 그 ’처음‘에 이르지 않은 단계로 아직 이 글을 읽지 않으셔도 됩니다.

 

개발을 꽤 하게 되어도, 코딩이 잘 되던 날 잠들기 전에는 엘도라도가 보이다가, 아침이 되면 미처 해결하지 못한 버그들 생각에 긴 하루가 되겠다는 생각이 들기도 하고, 세상을 바꿀 아이디어로 대박 꿈을 꾸다가, 깨어나면 나의 보잘 것 없는 실력에 기운이 빠지기도 합니다. 그 때도 이글이 유용하게 읽히면 좋겠습니다.

 

비교적 처음 소프트웨어 개발을 접하고 계신 분들에게는 늘 다음과 같은 의문이 밀려왔다 갑니다. 이 의문들에 대한 제 생각을 이 글에 적었습니다.

 

  • 소프트웨어 개발이 재미는 있는가?
  • 내게 소프트웨어 개발자의 재능이 있는가?
  • 나는 언제 저들처럼 개발을 잘 하게 될까?
  • 이런 질문을 하면 창피하지 않을까?
  • 내 실력으로 취업이 가능할까?

 

각 질문에 대한 저의 답을 보시기 전에, 난 어쩌다가 소프트웨어 개발자가 되려고 했는지, 그것이 내 스스로의 선택이었는지, 지금은 뭘 어떻게 하고 있는지, 진로나 학습 또는 어떤 프로젝트 계획을 가지고 있는지 그리고 어떤 경로로 이 글을 읽게 되었는지를 먼저 생각해보면 좋겠습니다.

 

늘 그렇듯이 모든 이야기는 라떼로 시작합니다. 저의 라떼와 여러분의 지금 상황을 비교해보겠습니다. 소프트웨어를 그냥 배울 수 있는 환경은 지금이 훨씬 좋고(+1점), 소프트웨어를 써먹으면서 배울 수 있는 환경은 나빠졌고(-1점), 배워야 할 것은 너무 많아졌습니다(0점). 배울 수 있는 환경이 좋아진 이유는 책과 동영상, 그리고 인터넷에서 얼마든지 자료를 찾을 수 있기 때문입니다. 소프트웨어를 써먹으면서 배울 수 있는 환경이 나빠진 이유는 지금은 웬만한 건 다 만들어져서 새롭고 유용하면서도 상업적인 쉬운 아이템이 별로 남아있지 않기 때문입니다. 배워야 할 것이 많아진 것은 좋고 나쁨의 가치 판단이 없습니다. 어느 시대를 살던 좁고 깊게 배워도 쓸모가 있고 넓고 얕게 배우도 쓸모가 있기 때문입니다. 그래서 +1점, -1점, 0점을 더해보면 예나 지금이나 처음 이 바닥에 발을 들인 사람의 상황은 별로 다르지 않다고 볼 수 있습니다.

 

이제 질문을 살펴보겠습니다,

 

1. 나는 소프트웨어 개발이 재미있는가?

 

이 질문이 떠오르는 상황: 초기에는 문제가 너무 어려워 어떻게 해야 할 지 아무 생각도 없을 때, 조금 지나면 뭔가 창의적인 아이디어가 담기지는 않은 코드가 길어지고 소소한 버그들이 이어질 때, 더 나중에는 코드를 짜면 당연히 될 것이 너무 뻔해서 동기 유발이 안 될 때 등입니다.

 

재미는 어떤 주제에 대한 흥미와 그 주제 탐구 결과에 대한 만족감을 말합니다. 이 정의에서의 키워드는 ‘흥미’가 아니라 ‘만족감’입니다. 만족감이 없으면 재미도 없습니다. 만족감은 코드로 어떤 문제를 해결하려는 욕구가 충족되었을 때 느낄 수 있습니다. 문제를 풀면서 의식적으로 또는 무의식적으로 학습한 내용들이 지식으로 체화됩니다. 현실 세상의 모든 문제는 물론, 우리가 배우는 과정에서 접하는 문제도 단계별로 어려워집니다. 따라서 우리가 소프트웨어 개발이 재미있다고 하려면 어떤 문제를 코드로 해결하고 그 다음 단계 어려운 문제에 대한 호기심이 생길 때 소프트웨어 개발이 재미있다고 이야기 할 수 있겠습니다. 호기심은 새로운 것을 알고 싶어 하는 마음으로 지금까지 학습한 내용의 응용, 다음 단계의 지식을 원하는 상태입니다.

 

우리가 개발이 재미있는가? 라는 질문을 하게 되는 상황의 핵심은 어렵거나 지루해서 진도가 잘 안 나가고 있다는 것입니다. 흔히 작은 성취를 이루면서 성장을 하는 것이 좋다고들 합니다. 과정이 계속될수록 그 작은 성취의 단위가 당연히 커집니다. 그리고 새로운 지식의 난이도도 올라갑니다. 당장 성취처럼 보이지 않는 노력도 필요합니다. 운동선수들이 스트레칭과 기초 체력 훈련을 오래 하고 근육을 단련하는 것과 같은 이치입니다. 그 결과들이 모여서 성과가 만들어지고, 다음 단계의 성취 목표를 다시 설정합니다.

 

출처: MBC 레전드 짤

 

결론적으로 개발이 재미가 없다면, 지금 작성하고 있는 소프트웨어에서 충분한 지식을 쌓고 있지 못하기 때문입니다. 그리고 그 지식이 자동으로 생기는 것이 아니라 늘 힘들고 지루한 과정, 즉 엉덩이 무게를 더해서 얻어진 성취를 통해 체화되는데, 아직 충분한 시간을 보내지 않았기 때문이죠.

 

재미에는 늘 몰입의 시간이 필요한 법입니다. 거꾸로 재미가 있으면 몰입도 잘 됩니다. 배우는 과정, 즉 커리큘럼의 난이도 단계가 잘 설계되면 재미를 지속적으로 유지할 수 있겠지만, 모든 과정이 그렇게 설계되지는 않습니다. 가끔 가파른 언덕도 있는 법이지요. 지금 재미가 없는 것을 생각할 것이 아니라, 이 문제를 멋지게 해결한 뒤에 새로운 호기심이 생기는지 스스로 확인해보는 것이 정답입니다.

 

2. 내게 소프트웨어 개발자의 재능이 있는가?

 

이 질문이 떠오르는 상황: 같은 문제를 해결하고 있는 동료의 코드를 보니 내가 작성한 코드보다 예쁘거나 효율적일 때, 내가 만든 코드를 돌려 발생하는 에러들이 코드를 작성할 때는 전혀 예측하지 못한 뻔한 것들일 때, 남들은 재미있다고 신기하다고 하는 기술에 전혀 관심이 없는 나를 발견할 때 등입니다.

 

재능은 어떤 일을 하는 데 필요한 여러 역량 가운데, 개인이 타고난 능력과 훈련에 의하여 획득된 능력을 아우르는 말입니다. 이 정의에서의 키워드는 ‘타고난’이 아니라 ‘획득된’ 입니다. 정말로 운이 좋아서 개발자로서의 ‘재능을 타고난’ 사람은 거의 없습니다. 그런 귀한 분들을 우리는 천재 소년/소녀라 합니다. 그런 분들과는 그냥 친하게 지내면 됩니다. 실상은 이렇습니다. 사람들은 누구나 창의성을 가지고 있고, 남들보다 특히 잘하는 영역이 있기 마련입니다. 우리 교육이 각자 가진 그 창의성 영역을 찾아주지 못하는 교육이라서, 또 그걸 드러낼 기회가 없어서 아직 모르고 있을 뿐입니다. 소프트웨어 개발자의 재능이라는 것이 따로 있다 해도, 컴퓨터의 짧은 역사에 비추어 보면 아무리 생각해도 그런 재능이 우리 DNA에 각인되었을 가능성이 없을 것입니다. 다행스럽게도 소프트웨어 개발 또는 소프트웨어에 의한 문제 해결은 다양한 영역의 전문성을 요구합니다. 소프트웨어로 풀어야 하는 문제 자체가 다른 영역에서 오는 것이 보통입니다. 그 문제의 해결에도 여러 영역의 창의성이 동원되어야 하므로 여러분 스스로는 아직 잘 모를 수 있는 타고난 능력이 소프트웨어 개발 과정에서 드러나 언젠가 도움이 됩니다.

 

그래서 ‘내게 소프트웨어 개발자의 재능이 있는가?’의 질문은 ‘내가 소프트웨어 개발자의 재능을 획득했는가?’로 바꾸는 것이 맞습니다. 배워야 한다는 것입니다. 조금씩 실력이 쌓이면 소프트웨어 개발에 대한 역량이 커지고, 좋은 개발자가 될 것입니다. 그리고 혹시 이미 가지고 있던 자신만의 타고난 재능이 잘 발휘되는 영역에서 개발을 하게 된다면, 나의 소프트웨어 개발 역량과 시너지를 내면서 강력한 빛을 발휘할 수 있을 것입니다.

 

소프트웨어 역량과 타고난 재능의 크로스~~

3. 나는 언제 저들처럼 개발을 잘 하게 될까?

 

이 질문이 떠오르는 상황: 나보다 개발 동네에 먼저 입문한 선배에게 질문을 했는데 워낙 명료하게 답을 해줄 때, 같이 공부하는 개발자나 선배들이 분명히 소프트웨어 개발 이야기를 하는데 거의 알아들을 수 없을 때 등입니다.

 

개발을 잘 한다는 것이 무엇일까요? 잘 한다는 것은 개발 결과물에 버그가 적고, 문제 해결 로직이 효율적이며, 읽기 쉬워 생산성이 좋은 코드를 만든다는 것입니다. 누가 봐도 그런 분을 보면 부럽죠. 나도 저렇게 되는 날이 오기나 할까 싶은 생각도 들 겁니다.

 

높은 목표를 지향하는 것이 나쁘지는 않지만, 축구를 배워 열심히 한다고 누구나 손흥민처럼 되지 않고, 야구를 열심히 한다고 누구나 유현진처럼 되지는 않습니다. 대부분은 잘하는 아마추어가 되고 그중의 극히 일부가 좁디좁은 프로 무대에 섭니다.

 

다행스럽게도 소프트웨어 개발의 세계는 넓고도 깊습니다. 우선 넓은 쪽을 보죠. 많은 프로그래밍 언어, 웹, 모바일, 서버, 머신러닝, 데이터베이스, 게임 등의 분야가 있고 그 각 분야에 많은 솔루션, 도구와 프레임워크들이 있습니다. 깊은 쪽도 살펴보면 넓은 여러 분야 각각 컴퓨터과학의 이론들이 적용되는 수준, 데이터나 트래픽의 규모, 알고리즘의 복잡도, 특정 오픈소스 프레임워크에 대한 코드 디테일 등이 있습니다. 당연히 다 잘 할 수는 없겠죠. 앞서 이야기한 ‘친하게 지내면 되는, 세상에 거의 없는 천재 개발자’를 제외한다면 말이죠. 그래서 개발을 잘 한다는 것은 아마도 특정 한 두 분야에 꽤 깊이 있는 수준의 구현 능력을 가졌다는 것을 의미합니다.

 

원래 질문인 ‘나도 저들처럼..’의 ‘저들’이 누구인지를 다시 생각해보겠습니다. 나와 같은 공간에서 개발을 배우고 있는 사람들이라면 아마 지금은 손흥민, 유현진 수준은 아닐 겁니다. 그저 나보다 조금 잘하는 수준이겠지요. 지금처럼 열심히 하면 나도 곧 그 ‘저들’처럼 됩니다. 같은 과정을 배우고 있다면 시간이 답입니다. 여기서의 전제는 그 시간을 어떻게 보내는가 하는 것입니다. 이론과 과제로 배운 지식을 현실의 문제 즉 단 한 명이라도 고객이 있는 문제 해결의 경험으로 체화하는 것이 더 빠르게 ‘저들’의 수준 또는 그 이상의 수준에 도달하는 방법입니다.

정리하면, 지금 옆에 같이 있는 사람들 사이의 실력은 큰 차이가 없습니다. 높은 산에서 아래에 있는 나무들의 높이 같은 것입니다. 모두 갈 길이 멉니다. 차이가 느껴진다면 단지 조금 먼저 배웠거나 시간을 얼마나 썼는지의 차이일 가능성이 높습니다.

 

실력은 짬밥 순

 

학교를 떠나 회사의 신입으로 들어가서 어떤 팀에 속하게 되면, 쪼렙인 나도 얼마 지나지 않아 팀 안에 있는 선배 개발자들을 실력에 따라 줄을 세울 수 있습니다. 거의 틀리지 않습니다. 시간이 지나 현업의 경험이 쌓여가면서 나도 빠르게 성장을 합니다. 후임이 들어와 그의 입장에서 줄을 세울 때, 나도 그 줄 어딘가에 있게 됩니다. 맨 아래가 아닐 수도 있습니다. 업무와 다루는 기술이 바뀌고 시간이 지나면 그 줄이 한 개가 아니었다는 것도 알고 어느 날 내 스스로가 어떤 줄에서는 맨 아래가 아니라는 것도 알게 됩니다.

 

컨퍼런스나 세미나의 라이브 코딩 상황에서 발표자가 나는 이해도 잘 안 되는 코드를 너무 당연한 듯이 빠른 속도로 만들어 성공적으로 시연하는 걸 봅니다. 다들 이 바닥에서 적어도 10년 이상은 일을 했던 분들이고 한동안 자기가 공을 들였던 분야의 코드인 것입니다. 발표를 잘하는 것은 코딩 실력과는 약간 결이 다른 역량이기는 하지만, 개발자로서의 실력은 지속적으로 바뀌는 사용자 환경에서 발생하는 문제를, 좋은 개발 프로세스를 유지하면서, 해결하는 경험을 하면서 쌓여갑니다. 소프트웨어 개발자로서 진정성이 있다면 누구나 그렇게 잘하는 개발자가 됩니다. 항상 나보다 더 잘하는 개발자도 보입니다. 누군가는 나를 그렇게 볼 것입니다. 개발에는 전체 1등이 없습니다. 각자 1등입니다.

 

4. 이런 질문을 하면 창피하지 않을까?

 

이런 상황은 너무 많아 예를 들 필요도 없습니다. 창피하다는 것은 체면이 깎이거나 아니꼬움을 느끼는 상태를 말합니다. 예로부터 모르는 것은 죄가 아니라고 했습니다. 즉, 질문을 하는 상황에서 내가 잘못은 없는 셈입니다. 너무나 당연한 이야기지만 누구에게나 처음이 있습니다. 모두들 남들이 하는 것을 보고 따라하면서 배우고, 매뉴얼, 책, 동영상을 보고 배웁니다. 그리고 부족한 부분은 질문을 합니다. 당연히 답을 해줄 수 있다고 믿는 사람에게 말이죠.

 

여러 명이 같이 배우는 상황에서 혼자 질문을 하는 것이 창피하다고 생각될 때가 있습니다. ‘혹시 다른 학생들은 다 아는데 나만 모르는 것이 아닐까?’ 때문이죠. 장담하건데 내가 방금 그 내용을 이해하지 못했다면 다른 대부분 사람들도 이해를 못했을 가능성이 100%입니다. 내 질문이 친구들을 무지의 세계에서 구해내는 생명줄인 것입니다. 다들 감사하게 생각할 것입니다. 용기를 내야합니다.

 

누군가에게 질문을 한다는 것은, 상대가 최소한 나보다 그 문제를 잘 알거라는 존경심이 바탕에 깔려있습니다. 절대로 체면 깎이는 일이 아닙니다. 그래서 누구나 질문을 받으면 기분이 좋습니다. 질문한 상대방을 얕보지도 않습니다. 질문을 함으로써 존경심을 마음껏 발산하도록 합시다. 질문을 받은 사람은 그 보답으로 최선을 다해 답해 줄 겁니다. 내가 질문을 받았을 때 하는 것처럼 말이죠. 아주 드물게는 싸가지 없게 답을 하는 사람도 있습니다. 그냥 피곤하거나 너무 바빠서 그렇다고 생각하세요. 아니꼬운 일도 아닙니다. 그분 상태가 좋아 보일 때 다시 질문을 해보시면 압니다. 

 

질문을 할 때는 예의를 갖춰야 합니다. 즉 존경하는 자세의 최소한은 지켜야 하는 거죠. 예의란 Google과 StackOverflow 검색 정도는 질문 전에 해보는 것입니다. 도저히 못 찾았거나, 찾았는데 이해가 안 되는 것을 질문해야 한다는 뜻입니다. 질문자는 존경심에 취해 답을 해야 하는데 진짜 뻔한 것, 검색하면 윗줄에 바로 답이 나오는 걸 물어보면 ‘뭐지?’하는 생각이 들테니까요.

 

실력이 쌓이면 질문도 고급지게 바뀝니다. 질문 상대방도 잘 모르는 것일 가능성이 생기는 겁니다. 그런 질문을 내가 받았다면, 최선을 다해 답을 같이 찾으려 하겠죠. 그런 겁니다. 질문을 통해 나와 상대방이 같이 성장하게 됩니다. 

 

손들어 질문을 하자 (그림출처: Camylla Battani on Unsplash)

 

다른 종류의 질문도 있습니다. 처음 소프트웨어 개발에 입문했을 때는 기술이나 용어에 대한 질문이 많을 겁니다. 조금 지나면 기술에 관한 질문의 부분은 스스로 찾아 해결할 수 있게 됩니다. 그래서 질문의 내용이 달라집니다. 답을 구하는 질문이 아니라 관점을 묻는 질문이 많아지는 거죠. 이때는 실력보다는 지금까지 걸어온 배경이 더 중요할 수도 있습니다. 질문자와 답을 하는 사람이 이제 평등해지는 겁니다. 각자 다른 배경으로 각자 다른 문제 해결 경험을 하면서 성장했기 때문에, 문제를 보는 관점, 문제 해결 방법이 다를 것입니다. 질문 자체가 협업을 의미하는 것이죠. 요즘에 유행하는 PBL(Project/Problem Based Learning), 동료학습(Peer Learning)에서는 문제를 보는 관점, 해결 방법과 결과에 대한 서로의 질문과 토론을 강조합니다. 타인의 경험을 간접적으로 배우라는 뜻입니다.

 

질문은 존경심의 표시입니다. 질문은 나와 옆 사람, 대답을 해주는 사람까지 모두를 성장시킵니다. 용기를 내시기 바랍니다. 

 

5. 내 실력으로 취업이 가능할까?

 

세상은 넓고 할 일은 많습니다. 세상의 모든 문제를 해결하는 가장 강력한 도구가 소프트웨어라는 것은 이제 모두가 아는 사실입니다. 그 문제들을 해결하기 위해서 소프트웨어의 분야도 무척 넓습니다. 문제의 깊이에 따라 소프트웨어의 깊이도 달라집니다. 그래서 다양한 분야에서 다양한 역량 수준을 가진 개발자가 필요합니다. 다행인지 불행인지 지금 소프트웨어 개발자 수는 절대적으로 부족합니다.

 

‘취업’이라는 단어의 진정한 의미가 이제 중요해집니다. ‘취업이 가능할까?’라는 질문에서의 취업은 ‘내가 원하는 회사에의 취업’을 의미할 가능성이 높습니다. 그러려면 그 회사가 풀어내려고 하는 문제를 해결할 수 있는 역량, 그 회사가 다루고 있는 데이터에 관한 경험이 필요합니다. 연봉에 걸맞은 수준의 역량과 경험을 요구하지만 그런 역량과 경험은 학교에서 얻기가 쉽지 않습니다. 그래서 신입으로 원하는 회사에 취업하기가 어려운 것입니다.

 

가능한 방법은 학생 때부터 실제 사용자가 있는 프로젝트를 하는 것입니다. 규모가 작은 문제는 혼자서 할 수도 있고, 규모가 크다면 팀을 구성해서 진행합니다. 창의적인 아이템이면 좋겠지만, 꼭 그럴 필요는 없습니다. 누가 봐도 새로운 아이템이 생각보다 없기도 하지만, 창의적이면 너무 어려운 문제가 되기 십상입니다. 사람들이 잘 아는 문제, 이미 다른 해결책이 있는 문제가 개발자로 경험과 역량을 쌓기 위한 프로젝트로 좋습니다. ‘테트리스 만들기’, ‘에디터 만들기’, ‘쉘 만들기’로부터 ‘인스타그램 만들기‘ ’카카오톡 만들기‘ 같은 따라 만들기 프로젝트가 나쁘지 않은 예입니다. 똑같이 만드는 것도 좋고, 새로운 기술을 배우기 위해 일부러 실제로는 별로 필요하지 않은 기능을 추가해보는 것도 좋습니다.

 

만드는 것만큼 중요한 것은 고객을 확보하는 일입니다. 물론 내가 만들고 테스트도 하지만 단 한사람이라도 다른 사람들에게 써보게 하고 피드백을 받고 개선하는 과정이 기술적 성장의 핵심 과정입니다. 학교에서 과제하듯이 피드백 없이 제출하고 점수만 받고 마는 방식으로는 고객 경험이 쌓이지 않습니다. 주변에 써보도록 알리고 앱이라면 마켓에도 올려야 합니다.

 

요즘에 개발을 배우는 과정에서도 그렇고, 예전에 실력이 늘어 어떤 서비스를 만드는 프로젝트를 하는 경우 필연적으로 남들이 만든, 대개는 오픈소스 형태의, 프레임워크를 활용하게 됩니다. 매뉴얼을 꼼꼼하게 봐야합니다. 잘 만들어진 소프트웨어와 그 소프트웨어를 만든 개발자의 설계 철학을 느껴야 합니다. 그 경험은 내가 만든 라이브러리, 프레임워크를 다른 사람이 사용할 하게 될 때 큰 도움이 됩니다.

 

이런 프로젝트는 하면 당연히 Github과 같은 리파지터리에 오픈소스로 하시겠지만, 프로젝트를 진행하면서 배우는 내용, 특정 문제를 기술적으로 해결한 사례를 블로그 형태로 적고 다른 사람들과 공유하는 것이 실력 향상에 큰 도움이 됩니다. 정리를 할 수 있고, 정리하다 몰랐는 것을 더 찾아보고 알게 되거든요.

 

다시 ‘취업’이라는 질문으로 돌아와서 그 실질적인 의미를 살펴봅시다. 취업은 실력과 운이 동시에 작용하는 영역입니다. 나를 기다리는 회사는 없습니다. 그래서 내가 회사를 찾아야 합니다. 회사를 찾아야 하는 이유는 나쁜 회사를 가려내기 위함입니다. 나쁜 회사는 월급을 못주는 회사, 좋은 동료가 없는 회사, 기술적으로 성장이 어려운 회사를 말합니다. 하나라도 해당되면 나쁜 회사입니다. 소프트웨어 개발자 관점에서 보면 지금은 좋은 회사가 매우 많아졌습니다. 내가 이름을 모르는 회사일 가능성이 높겠지만요. 회사가 뭘 팔아서 돈을 벌고 있는지 알아보는 것도 중요하고, 그 회사에서 개발자들이 어떻게 살고 있고, 성장하고 있는지를 가능한 방법을 총 동원해서 알아봅니다. 뉴스, 회사의 블로그, 커뮤니티, 전시회, 미친척하고 방문 등이 방법입니다. 이력서를 내고, 면접을 보는 과정에 질문을 많이 하는 것도 좋은 방법입니다. 회사를 보는 눈을 키워야 합니다.

 

이제 소프트웨어 개발자에게 평생직장은 없습니다. 기술과 산업이 아주 빨리 바뀌기 때문에 한 회사에서 기술적으로 정체된 상태로 머무는 것은 커리어에도 좋지 않고, 인생의 즐거움 관점에서 좋지 않습니다. 개발자의 이직률이 비교적 높은 이유입니다. 이직이 자연스럽기 때문에 개발자 관점에서는 스타트업에서 큰 회사까지 소프트웨어 산업 전체가 한 회사입니다. 그 안에서 부서를 옮기듯이 회사를 옮기는 것이 이제 보통입니다.

 

내가 가진 역량이 잘 발휘될 수 있는 회사는 많습니다. 그런 회사 가운데 내가 잘 성장할 수 있는 회사를 찾는 것이 취업입니다. 회사를 찾는 과정에서 취업을 위해서는 어느 정도 역량이 필요하지도 알게 됩니다. 어쩌면 지금도 가능할 수도 있고요.

 

이상 처음 개발에 발을 들여놓은 분들이 가질 수 있는 의문들에 대하여 제 답을 달아보았습니다. 소프트웨어 개발은 약속의 땅 같은 영역이라고 확실히 이야기 할 수 있습니다. 어느 순간을 넘게 되면 많은 사람이 적성에 맞는다, 자기 몸에 개발자의 피가 흐른다고 느낍니다.

 

다시 한 번 이 영역에 오신 것을 환영합니다. 다 잘 될겁니다.

 

*

 

참고 글들

반응형
Posted by hl1itj
,