이 글은 커뮤니티에서 올렸던 글 중에 하나인데,
가장 반응이 좋았던 글이다.
한국에 동료 개발자 분들도
많은 공감을 해주었던 글이였기 때문에
전지적 개발자 시점 태그의 첫 글로
가장 어울리는 글이라고 생각한다.
생각날 때 마다 조금씩 항목을 늘려갈 것 같다.
개발자는 누구나 할 수 있나요?
결론적으로 말하면
누구나 할 수 있다고는 생각한다.
프로그래밍이 진입장벽이 높지만,
어느정도 이상 실력이 올라오면
어느 정도 까지는 금방 금방 성장하는게
흔히 사람들이 인식하고 있는 프로그래밍을 하는 개발자이다.
어느 직업이건 마찬가지라고 생각하지만
어느 이상의 실력 혹은 급여를 바라고
개발자를 하고 싶어 하고,
하려고 한다면 누구나 할 수 있다고는 생각하지 않는다.
왜냐하면 개발자라는 직업은
계속해서 새로운 기술이 나오면,
그에 따른 대응이 가능해야 된다.
비교적 최근 스마트폰이라는
패러다임의 변화가 왔을 때
수 많은 개발자들이 패러다임의 변화라는
파도에 휩쓸려 사라졌다.
발 빠르게 대응할 수 없다면
패러다임의 변화가 왔을 때 대응하기 힘들다.
그래서 끊임 없이 공부를 해야 된다.
(물론 현실에서 자발적으로 학습하는 사람의 수는 그리 많지 않다)
여기서 말하는 공부는 학교에서 하던
시험 공부를 말하는 것이 아니다.
IT기술의 동향을 살피고 나름 분석해보거나
직접 토이 프로젝트를 해보는 것을 통해
언어를 포함한 기술에 대해 익혀두는 것을 말한다.
따라서 기본적으로 향상심이나
호기심이 많아야 한다.
향상심과 호기심이 많다면
저러한 행위는 저절로 하게 되있다.
게임을 좋아하는 사람이라면 게임을 하기 위해서
잠자는 시간까지 쪼개가며 하거나
심지어 게임에 이기기 위해서
돈을 지불하면서 까지 배우는 것과 같이
새로운 것을 좋아해
향상심과 호기심이 적절하게 있다면
개발자라는 직업은 그러한 사람들에게 꼭 맞는 직업이다.
이러한 특성을 가지고 있는 사람이라면
나는 개발자라는 직업을 추천하고 싶다.
하지만 그렇다고
꼭 공부를 해야 되는건 아니다.
이는 IT 업계가 아니더라도 어느 업계나 마찬가지이다.
자발적으로 학습하고 공부하는 사람은 흔치 않다.
단지 개발자로서 직업 수명이 짧아질 뿐이다.
한국에서는 개발자로 시작해서
결국에는 치킨집 사장이 된다는 말을
한국에서 우스게소리로 굉장히 많이들 하는데
이게 공부하지 않은, 학습을 소홀히하는
개발자들의 미래가 될 가능성이 크다.
정확히는 개발자라는 직업에 대해
충분히 인지하지 못하고,
연봉을 높게 받을 수 있다는 말만 듣고
개발자라는 직업을 가지게 된 사람의
미래가 될 가능성이 크다.
게다가 실력도 중요하지만
무엇보다 커뮤니케이션 능력이 좋아야 한다.
물론 어떤 사람들은
개발자는 실력만 좋으면 되는거 아니야?라는 생각을 할 수도 있다.
나도 대학생 시절에는
그러한 생각으로 가득 차 있었던 적이 있었다.
이러한 생각은 대학 졸업 프로젝트를
팀장으로서 진행하면서 산산조각이 났지만 말이다.
사회에서 유용성이 높은 엔터프라이즈급 시스템을
혼자서 개발하는 것은 절대로 불가능하다.
왜냐하면 대게 프로젝트에는 주어진 시간이 존재하며,
한 사람이 낼 수 있는 퍼포먼스와 그에 따른 효율에는 한계가 있고,
항상 충분한 예산이 주어지는 것은 아니기 때문이다.
물론, 적절한 아웃소싱을 하면
그렇게 보일 수 는 있지만 말이다.
또한 위에서도 언급하기도 했고,
어느 직업이나 마찬가지겠지만,
좋은 실력을 가진 개발자 혹은
연봉을 많이 받는 개발자는 아무나 할 수 있는 것은 아니다.
프로그래밍뿐만 아니라
커뮤니케이션 능력도 좋아야 한다.
사실 아무리 실력이 좋아봤자
어느 정도 규모가 있는 프로젝트에서
개인이 할 수 있는건 한계가 있다.
여기서 한계는 대부분 시간적인 한계를 말한다.
프로젝트 관점에서 본다면
프로젝트에서는 정해진 예산이 있고,
그에 따른 개발 일정이 있다.
게다가 개발자라고 해도 단순히
개발 일만 하는건 아니다.
일정이 촉박할 경우 혹은
분업이 잘되어있지 않은 프로젝트에서는
경우에 따라선 거래처에 가서
협상하거나 설명 할 수 있고,
설계, 테스트, 프레젠테이션 등등도 할 수도 있다.
단순히 프로그래밍 실력이 좋은 개발자라면
개발 단계에서의 시간 단축은 할 수는 있겠지만,
한 개인이 협상 부터 시작해
설계, 개발, 테스트, 업무 조율 등등
이 모든 단계에서 시간 단축을 할 수는 없다.
왜냐하면
실력이 좋은 사람도,
실력이 좋지 않은 사람도
주어진 시간은 똑같이 때문이다.
물론 실력이 좋은 사람이 효율은 좋겠지만
단축할 수 있는 시간에는 명백히 한계가 있다.
설사 이 모든 과정의 능력을 가지고 있다고 해도,
시간적으로 무리라고 단언할 수 있다.
물론 적절히 아웃소싱을 이용한다면
그럴듯 하게 보일 수 는 있겠지만,
무슨 의미가 있겠는가?
협업을 피할 수 없는 업계에서
단 몇 주만 같이 일해보면 이미 그런 것 쯤은 모두 드러난다.
따라서 개발자라는 직업은
혼자서 하는 것 보단
대부분 다른 사람들과 함께 일하는 경우가 많다.
그리고 개발 단계에서도 협업을 하게 될 탠대,
과연 프로젝트 관점에서 본다면
단순한 프로그래밍 실력만 좋은 개발자가
프로젝트에서 득이 될까 독이 될까?
자신이 관리자라는 입장에서,
동료라는 입장에서 보면 답은 정해져 있을 것이다.
세상에 좋은 유용성을 가지는 시스템들은
미디어에서 나타나는 것 처럼
한 사람의 천재 개발자가 갑자기 영웅 처럼 등장해서
개발되는 것이 아니다.
수 많은 프로세스에서 수 많은 사람들이 협업한 결과 이다.
다만, 좀 아이러니 한게
보통 실력이 좋은 개발자(특히 코딩 부분)들은 커뮤니케이션을 잘 못한다.
왜냐하면 다른 사람과 말하는 시간보다
컴퓨터 보고 자판을 두드리는 시간이 많은 특성상
어쩔 수 없이 비교적 커뮤니케이션 능력이 떨어 진다.
커뮤니케이션이라는게 다양한 사람도 만나보고,
대화도 많이 나누고 그 안에서 적절한 선을 알아야만
효율성 있는 커뮤니케이션을 할 수 있기 때문이다.
따라서 꽤나 많은 개발자들이 외골수적인
특성을 가지는데에는 이러한 이유가 있다.
그래서 재미있게도
개발자들 끼리 협업할 때도
같은 이야기를 말하려고 하는대,
설명을 잘 못해서 어긋나는 경우가 많고
그리고 그것 때문에 싸우는 경우도 많다.
실제로 동료 A라는 사람과
동료 B라는 사람이 업무 이야기를 하다가 싸움이 났는데,
이야기를 정리해보니 결국에는 같은 이야기를
서로 다른 방식으로 설명하고 있던 것이였다.
이러한 상황이 IT업계에서는 일상다반사다.
사실 위에서 두 가지를 잘해야 한다고 말은 했지만,
실제 실력과 커뮤니케이션
둘 다 잘하는 사람은 정말 정말 드물다.
현실은 실력만 좋은 개발자 찾기도 힘들다.
물론 실력만 좋아도 되긴하지만
당장은 돈은 많이 받겠지만
근대 그 실력을 증명할 수 없는 순간이 오면
아이폰의 등장으로 앱이 IT시장에 등장했을 때 처럼
패러다임이라는 파도에 휩쓸리기 쉽다.
어떤 직업이던 간에 사회에서 우선시 여기는 것은
같이 믿고 일할 수 있는 사람
즉, '신뢰'이기 때문에
커뮤니케이션이 비교적 약한 개발자들은
IT업계도 여기서 크게 벗어 나지 않는다.
과거에 같은 직장, 같은 프로젝트에 좋은 관계를 쌓아
신뢰를 얻었고, 최소한의 실력을 갖추고 있다고 판단된다면
경력이 없더라도 경쟁력을 확보할 수 있다.
그리고 이 신뢰는 최소한의 실력을 가지고
적절한 커뮤니케이션을 타인과 이룬다면 손쉽게 만들 수 있다.
결국 내가 타인의 힘이 필요로 하듯이
타인 또한 스스로에게 없는 능력이 필요하기 때문이다.
그렇기 때문에 지금 주위의 협업하는 동료들을 위해서라도
자신의 미래를 위해서라도
사회에서 허용되는 커뮤니케이션 능력은 있어야 한다.
참고로 나라면 아무리 실력이 좋아도
커뮤니케이션 능력이 심각한 사람이랑 일하고 싶지 않다.
그런 사람이랑 이상한 걸로
말씨름하다가 일정 늦어지는 것 보다
실력은 떨어지지만 커뮤니케이션이되서
일정을 조율하는 쪽이 몇 배는 더 일하기 편하기 때문이다.
만약 당신이라면 실력은 좋지만 괴팍한 스크루지와 일하고 싶은가?
아니면 실력은 평범하지만
항상 웃으면서 가끔 시시한 농담을 하며
대화를 나눌 수 있는 사람과 일하고 싶은가?
프로젝트 관점에서 본다면
전자의 경우 대부분 팀원 간의 잦은 불화로 인해
전체적인 좋은 퍼포먼스를 기대하기 힘들며
최악의 경우 하락할 수 도 있다.
시너지를 전혀 기대할 수 없고
퍼포먼스 하락의 리스크까지 보인다.
프로젝트 관점에서는 리스크가 늘어나는 것이다.
하지만 평범한 실력을 가지면서
어느 정도 커뮤니케이션 능력이 있다면
적어도 퍼포먼스 하락은 없고
시너지 효과를 기대해 볼 수 있다.
때로는 좋은 시너지 효과를 발휘 할 수 있다면
그 인원의 두, 세배의 퍼포먼스가 나올 수 있기 때문이다.
어쨋든 개인적으로는
개발자로서의 실력과 커뮤니케이션 능력의
밸런스가 중요하다고 생각 한다.
어떤 사람이 가질 수 있는
개발자로서의 실력과
커뮤니케이션 능력의 합을 10으로 본다면
7:3 이렇게 말이다.
어느 비율이 더 좋느냐는
자신의 장,단점과 그리고 기질에 따라 다를 수 있고
상황에 따라 다를 수 있다.
정리해보자면 개발자는 누구나 할 수 있다.
하지만 많은 사람들이 바라는
실력 좋은 혹은 연봉이 높은 개발자가 되기는 쉽지 않다.
왜냐하면 새로운 기술이 패러다임으로 등장했을 때
자신의 가치를 증명할 수 있어야 하기 때문이다.
따라서 끊임 없는 학습을 해야되는 직업이며
실력은 물론 커뮤니케이션 능력까지 되어야
많은 사람들이 원하는
실력 좋은 혹은 연봉이 높은 개발자가 될 수 있기 때문이다.
분야에 따라서는
핵심 개발자들은 높은 수준의 수학적 지식과
수학적 사고력이 필요 할 수도 있다.
물론 누구나 할 수 있기 때문에
개발자라는 직업을 가진다면 어느 정도의 수입을 보장될 것 이다.
하지만 그 만큼 개발자로서 생명은
생각하는 것 보다 더 짧을 수도 있다.
게다가 실력 까지 떨어진다면
개발자로서 받는 취급은 여러 의미에서 좋지는 않을 것이다.
그래서 개발자를 하고 싶다고 한다면
나는 말리진 않겠지만 위에 언급한 내용을 고려해볼 필요가 있다.
미래는 뻔히 보이는데
지나고 나서 땅을 치고 후회해봐야 소용없지 않겠는가?
선택은 스스로의 몫 이다.
무슨 언어가 좋나요?
사실 가장 많이 듣는 질문은
1번 질문이 아니라 2번 질문이다.
개발자 뿐만 아니라
다른 직업도 마찬가지로 1번과 같은 생각을 한다음
2번과 같은 생각이 들어야 된다고 생각하지만
현실은 그렇지 않은가 보다.
단순히 무슨 언어가 좋냐고 물어보면,
상황에 따라 다르다고 이야기 할 수 밖에 없다.
왜냐하면 각 언어마다 장, 단점을 가지고 있고
분야 마다 잘 사용하는 언어,
잘 사용하지 않는 언어가 있기 때문이다.
예를 들어 C계열 특히 C++은
메모리 관리를 할 수 있기 때문에
성능을 우선시하는 게임 업계에서 많이 쓰인다.
하지만 성능이 딱히 필요하지 않은
정확히는 딱히 신경 쓰지 않아도 되는
Web업계에서는 Java, C#, Python, Ruby 등등 다양하게 사용하는 경향이 있다.
특히 한국에서는 Java를 많이 쓴다.
이런 이유 외에도 여러가지 이유 때문에
각 업계에서 자주 사용하는 언어가 있다.
분야도 분야지만,
나라에 따라서도 다를 수 있다.
예를 들어
느낌상 미국의 경우 정말 빠르게 변하기도 하고
새로운 언어, 프레임워크 등을 포함한 개선되거나 새로운
기술이 계속해서 나오며
이를 사용해보면서
이에 관한 글과 토론이 활발한 반면
동양 쪽은 조금 느낌이 다르다.
익숙한 기술에 대해 벗어나기를 힘들어 한다.
새로운 기술에 대해 직접 사용하고
토론을 하기 보다는
외국 포럼에서 토론한 내용들을 보기만 하고
심지어 공유하는 성향도 약하다.
따라서 어떤 언어가 좋을지는
분야에 따라, 나라에 따라 다를 수 있다.
예컨데
한국 쪽에서 Web에서 일하고 싶다면
Java를 다룰줄 아는 것이 좋을 것이고,
외국 Web에서 일하고 싶다면
Python이나 Ruby를 배우는 것이 좋을 수도 있다.
최근에는 언어보다는
프레임 워크를 우선시 하는 경향이 있기는 하다.
그럼에도 불구하고 궁금한 사람들이 있을 것이다.
누군가가 나에게
'난 프로그래밍은 해본적 없지만
나중에 개발자가 되고 싶은데 무슨 언어가 좋다고 생각해?'라고 묻는다면,
그냥 깊게 생각하지 않고
마음에 드는 언어를 배우라고 권하고 싶다.
왜냐하면 결국 언어는 도구일 뿐이며,
무엇을 먼저 시작했는지는 그리 중요하지 않다.
언어는 테크가 아니라 스킬 일 뿐이다.
대장장이의 도구가 수 많은 틀과 모루와 망치 인것 처럼
개발자의 도구는 수 많은 언어와 툴, 그리고 컴퓨터일 뿐이다.
또한 세상의 인식과는 다르게
개발자라고 모두 코딩을 하는 것은 아니다.
상위 레벨로 올라가면 올라갈 수록
점점 구체적인 코딩과 같은 일 보다는
추상적인 일을 주로 하게 되기 때문이다.
워터폴 개발 방법론의 프로세스로 비유하자면,
코딩, 테스트 보다 설계, 요건 정의에 무게가 기울어 진다.
여기에 더해 리더급 프로그래머는 팀원의 서포트도 해야 한다.
적절한 분업이 이루어지지 않은 프로젝트라면
관리 역할 까지 해야 할 수도 있다.
다시 프로그래밍 언어에 대해 돌아가보자면,
사람에 따라 어려운 언어를 배워야
나중에 비교적 쉬운 언어를 배우기 수월하다고 생각해
C언어를 추천하는 사람도 있고
어려운 언어를 먼저 시작하면
쉽게 포기해버리기 쉬우니 Java나 Python와 같은
비교적 다루기 쉬운 언어를 추천 하는 사람들도 있다.
둘 다 일리가 있는 말이라고 생각 한다.
하지만 위에서 언급했다시피
언어는 단순히 도구 이기 때문에
언어를 도구로서 인식할 수 있기만 한다면
무슨 언어를 먼저 배우건 상관 없다.
수학 잘해야 되나요?
수학 잘해야 하긴 하다.
하지만 일반적으로 말하는
수학을 잘해야한다는 의미와는 많이 다르다.
여기서 수학을 잘 해야 한다는건
일반적으로 생각하는 수능에서
어려운 미적분 문제 같은 것을 능숙하게 푸는 것이 잘하는게 아니라,
프로그래밍에서 사용하는
일부분의 수학적 지식과 수학적 사고력이 있어야 된다는 것을 말한다.
어떤 분야의 개발자냐에 따라 다르겟지만,
수학적 지식은 수학계 석/박사들이 정의한 수식을
어느정도 이해할 정도의 수학적 지식을 말한다.
쉽게 말하면 벡터, 행렬, 그래프 등등 으로
정의되어진 수식을 볼줄 아느냐를 말하고,
수학적 사고력은
이 수학적 지식을 바탕으로
실제 프로그래밍을 할 수 있는 사고력,
또는 프로그래밍을 할 때의 수학적 사고력이 있느냐를 말한다.
예컨데
머신 러닝에 비용 함수라는 것이 있다.
자세히는 알 필요없지만,
간단히 설명하자면 머신러닝에서는
데이터를 분류하기 위해 선을 긋는대, 이 선을 결정 할 때 쓰는 함수다.
그리고 이 선을 어떻게 긋는 방법이 여러가지 있는데,
가장 간단한 것 중에
일직선을 긋는 선형 회귀(Linear Regression) 라는 방법이 있다.
그 식은 아래와 같다.
cost(W)라고 써져 있는 부분이
비용 함수의 수식이다.
이 비용 함수를 예로
수학적 지식과 수학적 사고력에 대해 설명하자면
여기서 나오는 비용 함수의 수식을 이해할 수준의 수학적 지식과
이것을 언어로 프로그래밍할 수 있는
수학적 사고력이 있다면 된다는 것이다.
물론 이와 같이 수학적 지식까지 필요한 업무는 그렇게 많지 않다.
왜냐하면 대부분 그러한 것들은
이미 훌륭한 API가 개발되어져 있기 때문이다.
대부분 업무에서는 이러한 API를 사용하기만 하면 된다.
따라서 수학적 사고력만 가지고 있으면
흔히 말하는 개발자로서의 능력은 가지고 있다고 볼 수 있다.
정리하자면
개발자가 수학을 잘해야 한다고들 말하는데,
여기서 말하는 수학은
수능에서 미적분과 같이
어려운 수학 문제를 능숙하게 푸는 것을 말하는것이 아닌,
수학적 지식과 수학적 사고력이 뛰어나야 한다는 말이다.
이 의미에서 말한다면 개발자는
수학을 잘해야 한다고 말할 수 있다.
특히 수학적 사고력이라는건
코딩을 하건 설계를 하건 뛰어나면 뛰어날 수록 좋기 때문에
수학적 사고력이 뛰어나야 한다는 의미에서
수학을 잘해야한다고 말한다면,
또한 개발자는 수학을 잘해야 한다고 할 수 있을 것 이다.
반대로 수능에서 보던
어려운 미적분 같은 문제를 잘 풀 수 있어야 한다는 의미에서
개발자가 수학을 잘해야 한다면,
그런 수학은 잘 못해도 된다고 말할 수 있다.
그래서 개발자가 수학을 잘해야 한다고 듣고
고등학생 때 공부했던 수학책을 펼쳐봐야 의미 없다고 볼 수 있다.
같은 의미에서 수학적 지식에 가까운
알고리즘 문제 풀기 또한 개발자로서 요구되는 능력이라고 보기는 힘들다.
개발자 하고 싶은데 무엇 부터 해야 하나요?
정말 정말 정말 애매한 질문이다.
솔직히 나는 이런 질문을 하기전에
자신이 개발자라는 직업이
자신에게 맞는지 부터 보는게 먼저라고 생각한다.
물론 이것은 다른 직업들도 마찬가지라 생각한다.
특히 다른 직업과 다르게
학습한 것에 대한 결과물이 바로바로 나오기 때문에
하고 싶다면 꼭 해보고 생각해 보기를 바란다.
자신이 정말 개발자라는 직업을 하고 싶다면,
일단 어떤 언어라도 좋으니
일단 한 가지 언어를 배워본 다음
이것저것 해보면서
프로그래밍이 재미있다고 생각이 들고,
다음에 뭐 부터 해야할까?라는 생각이 든다면,
개발자라는 직업을 추천해주고 싶다.
위에서도 언급했듯이
향상심과 호기심이 있어야 한다.
코딩이 재미도 없는데
단순히 취업이 잘된다는 이유로,
연봉이 꽤나 높다는 이유로 선택한다면
솔직히 돈은 많이 받을 수 있겠지만,
그 앞은 사실 지옥 뿐이다.
개발자로서 입문은 보통 프로그래밍이 핵심인데
이게 재미 없다면 지옥 밖에 없을 것이다.
물론 여기서 말하는 재미는
자신이 좋아하는 것을 할 때 느끼는 즐거움과는 거리가 좀 있다.
무언가를 자신이 고민해서 직접 만들고
의도한대로 프로그램이 돌아갔을 때 느낄 수 있는 즐거움을 말한다.
그리고 프로그래밍이 재미있다면
컴퓨터 구조, 알고리즘, 자료구조,
이산 수학, 선형 대수 등의 공부를 해보길 바란다.
노파심에서 이야기하지만
여기서 공부를 하라는 것은
학점을 높게 받으라는 이야기가 아니고,
모든 것을 외우라는 이야기도 아니다.
다음에 필요할 때 생각은 날 정도로 익히라는 것이다.
가장 좋은 방법은 나 또는 수 많은 개발자들이 그러하듯이
자신만의 블로그를 만들어서 이해한 것을 자신만의 방식으로 기록하고,
필요할 때 마다 보는 것이다.
아마 자신의 학부가
컴퓨터 공학이라면 들어가 있을 것 이다.
자신이 컴퓨터 공학이 아니라면,
요즘에는 친구들이 고등학생때 듣던 인터넷 강의 같이
유명의 대학 강의가 공개된 사이트도 있으니깐
그쪽에서 공부하면 될 것이다.
또한 최근에 학문에 가까운 수학 알고리즘 문제를 푸는 것을
추천하는 사람들이 있는데,
현실에서 대부분의 개발자의 주 업무는
그러한 알고리즘을 개발하는 것이 아니다.
정확히는 운용/보수에 가까우며
운용/보수에서 필요한 능력은
학문에 가까운 수학 알고리즘을 해결하는 것과는 거리가 멀다.
대부분의 개발자의 임무는 시스템을 만드는 사람들이다.
정확히는 완성된 시스템을 운용/보수 하는 사람들이다.
그러한 알고리즘은 수학계의 사람들이
더 잘하고, 그들의 몫이기 때문에
개발자가 굳이 신경 쓸 필요는 없다.
한국에서 많은 사람들이 말하듯이
모든 것을 다 잘할 필요가 없다.
수학은 학자들에게 맡기고,
개발자는 솔루션 개발이라는
개발자의 바운더리 안에서도 가장 우선시되는 것만 신경 쓰면 된다.
개발자는 수학계의 학자들이 정의해 놓은 것을
자신의 수학적 지식으로 이를 이해하고
수학적 사고력으로 프로그래밍 해서 솔루션을 개발하면 된다.
혹은 성능 좋은 API가 있다면
그것을 쓰면 된다.
개발자가 생각해야 하는
알고리즘은 수학에 가깝기보다는
시스템의 동작하는 알고리즘에 가깝다.
차라리 그 시간에 다른 언어들을 익히고
사이드 프로젝트 하기를 권장하는 바이다.
물론 나는 말리지는 않는다.
하고 싶다면 하면 된다.
다만 그러한 문제를 푸는것으로
개발자로서 능력을 함양할 수 있다고 한다는 것에 의문이 가는 것 뿐이다.
수학적인 알고리즘을 푸는 것이
개발자에게 미세하게 나마
도움이 될 수 있다는 것에는 동의하지만,
마치 큰 도움이 된다는 것처럼
이야기하는 것에는 동의하지 않는다.
이전 에세이에서도 이야기 했듯이
우리의 자원은 한계가 있기 때문에
즉, 시간은 한계가 있기 때문에
주어진 시간을 효율적으로 사용할 필요가 있다.
정말 중요한 것에만 시간을 쏟아도 부족하기 때문이다.
프로그래밍 너무 어려워 보이는데
머리 좋거나 천재들만 가능한거 아닌가요?
프로그래밍은 굉장히 어려워보이기 때문에
천재들만 하는 것 같은 인식은
어느 나라에도 있는 것으로 보인다.
적어도 나는 이방인으로서
살아가면서 그렇게 느끼고 있다.
마치 위의 사진 처럼
안경을 쓰고 멋드러진 나비 넥타이를 차고 있는
천재 소년들 처럼 말이다.
반은 맞고 반은 틀리다.
프로그래밍은 어렵긴 하지만
천재들만 하는 것은 아니다.
아마 영화와 같은 매체에서
마치 불가능을 가능하게 해주는 연출 장치로서
해커나 프로그래머를 사용하기 때문이라고는 생각 된다.
물론 불가능을 가능하게 해줄 수 있는 가능성이
지닌 것이 IT기술이고 그것을 다루는 개발자인것은 맞지만
시스템이 복잡하면 복잡할 수록
혼자서는 시간이 부족하다.
따라서 IT업계는 분업화가 굉장히 잘되어 있다.
크게 프로그래밍 팀, 테스트 팀, 영업 팀으로
대충 나눌 수 있고
세부적으로 IT 컨설턴트, PM, 아키텍터, 리드 프로그래머
설계자, 기획자 등등 수 많은 분업화 되어진 역할들이 존재 한다.
따라서 IT 업계에 있다고 해도
모두 프로그래밍을 해야만 하는 것은 아니다.
프로그래밍은 그런 수 많은 역할 중
하나일 뿐이다.
또한 프로그래밍이 어려워 보이는 것은
언어이기 때문에 당연한 것이다.
잘 모르는 사람들에게는
프로그래밍 언어라고 해서
언어와 유사해 보이기 때문에
언어라고 말하는 것 처럼 들릴 수 있으나
정말로 언어이기 때문에
프로그래밍 언어라고 부르는 것이다.
중국어, 일본어, 영어 등등
다른 나라의 언어를 배울 때와 동일하다.
하지만,
이런 외국어 하나를 다룰줄 안다고
우리는 보통 천재라고 부르지 않는다.
이처럼
프로그래밍 언어를 다를줄 안다고해서
그 사람이 천재인 것은 아니다.
외국어도 사용하면 사용할 수록
익숙해지듯이
프로그래밍 언어도 사용하면 사용할 수록
익숙해질 수 밖에 없다.
프로그래밍 언어는 테크보다는 스킬에 가깝기 때문이다.
또한 관련 대학 전공자
그러니깐 보통 한국이라면 컴퓨터 공학부,
외국이라면 컴퓨터 과학 학과를 나온 사람들만이
하는 것이라는 이야기도 들었는데,
실상 업계에 들어와 보면
비전공자들도 심심치 않게 보인다.
하지만,
이 것을 하나의 업으로 한다는
의미는 조금 다르다.
정확히는 이 것을 하나의 업으로 삼고
연봉을 많이 받고 싶다는 생각으로 한다면
많이 고통스러울 수 있다.
따라서 프로그래밍 언어가 어려운 것은
우리가 외국어를 배울때 어려움을 느끼는 것 처럼
당연한 것이며,
그렇다고 천재들만 하는 것은 아니다.
미디어에서 보던
불가능을 가능으로 만들던
어린 천재 프로그래머나 해커들이나 하는 것들은
일반적인 IT업계의 업무들과는 많이 다르다.
그러한 이미지를 가지고 일을 시작한다면
아마 많은 실망을 할 것이다.
