여전히 걷는 중
에필로그
학원에서 강의하던 시절, 수강생들의 질문과, 멘토링을 하면서 받았던 질문, 25년 넘게 현장에 있으면서 후배 개발자들에게 수없이 들은 질문들이 있다. 몇 가지를 정리해 본다.
"이직이 잦으면 불리한가요?"
3D 그래픽 디자이너로 시작했다. 이후 캐릭터 디자이너, 웹 디자이너, 부동산 법무, 회계까지 거쳤다. 서로 완전히 다른 직무처럼 보이지만, 연결되는 고리가 있었다. 다음 회사 면접에서는 이전 경험과 새 회사에서 필요한 부분을 연결했다. 업무와 기술이 달라도 대인관계, 소통, 업무를 대하는 자세는 같다.
"무조건 시키는 일은 다 하겠습니다"라는 말은 "아무것도 모르니 알아서 키워주세요"와 같다. 회사는 단순 노동 인력을 뽑는 게 아니다. 같이 성장할 사람을 원한다.
기술이나 지식도 중요하지만, 면접관은 성향과 업무를 대하는 자세, 소통 능력을 본다. 실제로 기술이 뛰어난 사람보다 "우리와 잘 지낼 수 있는 사람"을 채용하는 경우가 많다. 기술과 지식은 배우면서 쌓으면 된다. 하지만 성향과 태도, 소통은 개인적인 면이 강해 가르친다고 쉽게 바뀌지 않는다.
회사 입장에서도 이직이 잦은 사람을 원하지는 않는다. 이직 사유가 개인적인 이유면 의심한다. 납득할 수 있는 정확한 사유가 있어야 한다. 연봉을 올려서 이직했다거나, 회사 경영이 힘들어 권고사직을 했다거나, 회사가 폐업했다거나. 개발 분야는 이직이 많다. 대부분 연봉을 올려서 이직한다. 프로젝트를 경험하면서 타 회사 임원이나 팀장의 권유로 이직하기도 하고, 경험을 쌓아 큰 회사에 경력직으로 들어가기도 한다. 실력을 인정받고 이직하는 사람은 어느 회사에서나 채용하기를 원한다.
"프로그래밍 분야별 장단점이 뭔가요?"
산업군보다 업무 형태로 나누는 게 낫다. SM, SI, 솔루션으로 나눌 수 있다. SM은 운영 및 유지보수, SI는 프로젝트 개발, 솔루션은 자체 개발한 프로그램이나 서비스다.
SM의 장점은 장기적인 시스템 분석, 다양한 이슈, 오류나 버그 경험과 해결 방안을 배울 수 있다는 것이다. 365일 24시간 대기라는 단점이 있지만, 매일 매시간 오류가 나는 시스템은 없다. 그런 시스템이라면 다시 만들어야 한다. SM은 출퇴근 시간이 일정하고 저녁 시간에 자기 시간이 가능하다.
SI의 장점은 다양한 프로젝트 경험으로 단기간에 실력을 향상시킬 수 있다. 프로젝트마다 개발 언어와 시스템이 다르기 때문에 다양한 경험을 쌓기에 좋다. 단점은 정해진 일정에 정해진 개발을 완수해야 하기 때문에 스케줄 조절이 안 되거나 프로젝트가 순탄하지 않으면 야근은 필수라고 보면 된다.
솔루션의 장점은 회사가 자체적으로 만든 프로그램이라 SI처럼 갑과 을 관계가 없다는 것이다. 일정이 있지만 타이트하지 않고 유연하게 진행되는 경우가 많다. SI와 SM을 동시에 경험할 수도 있다. 단점은 납품하는 회사마다 다르게 적용해야 할 때 커스터마이즈가 자주 있을 수 있다. 솔루션의 버그나 오류가 발생하면 직접 회사에 가서 확인 및 점검을 해야 한다. AS센터처럼 자주 방문할 수도 있다.
회사 선택의 기준
"회사를 어떻게 선택하셨나요? 규모나 연봉, 복지 외에 뭘 고려해야 할까요?"
회사의 외견만 보고 판단하기 쉽다. 성장할 수 있는 회사인지, 튼튼한 회사인지. 이런 판단도 중요하지만, 회사가 쌓은 이력과 외견만 보지는 않는다. 그 회사가 어떤 사업을 하는지를 본다. 그 사업을 위해 어떤 노력을 하고 있는지는 면접을 통해 물어본다. 그리고 급여가 밀린 적이 있는지를 문의한다.
사업 아이디어가 좋고, 그 아이디어를 위해 회사 대표가 노력하는 모습이 보이고, 급여가 밀리지만 않는다면 충분하다.
회사의 규모, 연봉, 복지, 자산, 투자. 중요하지만, 메인은 아니라고 생각한다. 스타트업 기업은 대체로 규모가 작다. 복지는 대기업이나 코스피 상장 중견기업보다 못할 수 있다. 자산과 투자도 큰 회사보다 당연히 낮다. 이런 항목을 고려한다면 스타트업이나 작은 회사는 논외 대상이 된다.
카카오는 메신저 하나만 있는 회사였고, 몇 년 정도 유지하다 접을까도 생각했던 아주 작은 회사였다. 규모, 복지, 자산을 고려한다면 그 당시의 카카오는 들어가지 말아야 할 회사다. 하지만 몇 년이 지난 지금은 굴지의 IT 회사가 되었다. NC소프트도 작은 팀에서 시작하여 현재의 회사로 성장했다.
회사의 외견으로만 판단하지 말아야 한다. 외견을 판단하기 전에 그 회사에서 할 수 있는 일과 어디까지 성장하고 올라갈 수 있는지가 기준이 되는 게 맞다.
지금도 프로젝트에 참여하기 전에 그 프로젝트가 무엇인지, 프로젝트 리더 성향이 어떤지를 본다. 그 프로젝트에서 최대한 할 수 있는 업무와 리드 역할까지 올라갈 수 있는지 보고 판단한다.
연봉이나 급여는 중요하다. 실력도 없는데 높은 연봉을 원하면 어느 회사도 받아주지 않는다. 신입의 경우에는 사회 통념이 적용되어 적절한 수준으로 연봉이 책정된다. 경력자는 제시한 금액에서 협상이 가능하다. 높은 연봉을 원한다면 그만큼의 실력과 인정을 받아야 한다. 경력이 많다고 연봉이 올라가는 건 아니다. - 실력도 없는데, 경력이 많다는 이유로 높은 금액을 제시하는 사람은 개인적으로 싫어한다. -
마지막으로 매월 급여가 밀리지 않고 제때 나오면 된다. 회사 사정이 어려워 급여를 몇 달간 미루는 회사는 아무리 좋은 아이디어를 가지고 있어도 선택하지 않는다. 합의하에 단기적으로 낮게 지급되는 것은 납득이 가지만, 밀리는 것은 무료 봉사에 지나지 않는다. 급여는 최소한의 신뢰관계다.
코딩 테스트보다 중요한 것
"코딩 테스트는 어떻게 준비하는 게 좋을까요?"
회사마다 다르겠지만 대부분 알고리즘을 공부한다. 개발 언어를 질문하는 경우는 거의 없다. 인터넷이나 강의도 많다. 어떤 문제가 발생하면 코딩으로 어떻게 해결할 수 있는지를 테스트하기 때문에 다양한 알고리즘 문제를 풀어보는 것을 권장하지만, 개인적으로 코딩 테스트가 효율성이 있는지는 의문이다.
자료구조는 반드시 봐야 한다. 학원에서는 자료구조에 대해 언급하지 않지만, 자료구조는 프로그래밍의 기본이다.
네이버나 카카오에 입사할 때 코딩 테스트를 진행한 사람들 이야기를 들어보면, 문제 해석도 힘들다는 말을 많이 한다. 문제에서부터 해석이 안 되니 테스트 내내 당황했다고 한다. 문제만 제대로 이해하고 해석하면 답은 그렇게 어렵지 않게 나올 수 있다. 자료구조를 학습하고, 알고리즘은 많은 문제를 풀어보면서 문제 이해력과 해결력을 향상시켜야 한다.
최근에는 앞서 '바이브 코딩 알기' 연재에서도 언급했듯이 코딩 테스트 보다 AI를 활용한 코딩 설계 능력을 보는 곳도 나타나고 있다.
"프로그래밍 능력을 어느 수준으로 끌어올려야 취업 기본이라고 할 수 있을까요?"
가장 기본이 되는 데이터 타입, 함수, 클래스 정도는 알아야 한다. 데이터 타입은 정수, 실수, 문자 등의 정의와 활용 정도. 함수를 사용하는 이유와 파라미터, 리턴 타입 등을 이해하면 된다. 의외로 함수를 왜 사용하는지 모르고 그냥 교육기관에서 사용하라고 해서 이유 없이 사용하는 사람들이 많다. 함수의 개념을 이해하지 못하니 파라미터에 뭘 넣어야 하고 리턴을 왜 해야 하는지도 모른다.
함수는 반드시 알아야 되는 개념이다. 프로그래밍은 "함수가 다"라고 말할 수 있을 정도로 중요하다.
클래스는 상속과 캡슐화, 인스턴스 등 어려운 개념이 많다. 처음부터 숙지하기엔 힘들다. 프로젝트를 진행하면서 쌓으면 된다. 다만 객체지향이 어떤 개념인지, 클래스와 함수는 어떻게 다르고 활용하는지는 숙지하고 있으면 좋다.
무조건 배워야 하는 언어는 없다. 90년대에는 C언어가 필수였지만, 지금은 원하는 언어를 배우는 게 좋다. 언어마다 특징이 있어서 원하는 분야가 있다면 해당 언어를 배우면 된다. 자신이 관심 있고 하고 싶은 분야의 언어를 배우는 것을 권장한다. 다만, 언어를 배우면서 로직의 흐름을 더 익히는 게 좋다.
"프로그래밍 경력을 쌓을 수 있는 방법이 있을까요?"
회사에서 프로젝트에 참여하면서 경험하는 게 가장 좋다. 회사마다 다르겠지만 대부분 신입에게 그렇게 많은 스킬을 요구하지 않는다. 기초적인 코딩 능력과 관심도, 프로그래밍에 대한 열정 정도만 본다.
공모전이나 팀을 만들어 간이 프로젝트를 진행하는 것도 도움이 되지만, 정식 프로젝트 경험만큼 좋은 건 없다. 5개월이나 6개월 코스로 진행되는 학원이나 교육센터에서 프로젝트를 진행하는 것도 도움이 된다. 강사 주도하에 팀을 만들어 프로젝트를 진행하면 정식 프로젝트처럼 체험할 수 있다. 다만, 파레토의 법칙에서 처럼 80%에 해당하는 참여이면 안 하는 게 났다. - 자신이 하지도 않았는데, 마치 자신이 한 것처럼 말하는 사람을 많이 봤다. -
AI 시대, 개발자의 미래
AI가 코드를 짜는 시대가 왔다. ChatGPT에게 "로그인 기능 만들어줘"라고 하면 코드가 나온다. Claude에게 오류 메시지를 보내면 해결책을 알려준다. 예전에는 Stack Overflow에서 몇 시간 검색해야 했던 문제가 30분 만에 풀린다.
"개발자가 사라지는 거 아닌가요?" 후배들에게 자주 받는 질문이다. 답은 "아니다"이다. 하지만 역할은 바뀌고 있다.
단순 코딩의 비중은 줄어든다. AI가 더 잘하기 때문이다. 그런데 AI가 만든 코드를 그대로 쓸 수 있을까. 아니다. 버전이 다를 수 있다. 보안 취약점이 있을 수 있다. 비즈니스 로직과 맞지 않을 수 있다. 결국 사람이 검토하고 수정해야 한다.
오히려 흐름과 구조를 이해하는 능력이 더 중요해졌다. AI가 짠 코드를 읽고, 검증하고, 전체 시스템에 어떤 영향을 미치는지 판단해야 한다. 이건 AI가 대신해 줄 수 없다.
소통의 중요성도 커졌다. AI에게 정확한 지시를 내려야 원하는 결과가 나온다. 요구사항을 명확하게 정의하고, 맥락을 설명하고, 제약 조건을 알려줘야 한다. 고객의 추상적인 아이디어를 구체화하는 능력이 AI를 잘 쓰는 능력과 연결된다.
AI는 도구다. 전동 드릴이 나왔다고 목수가 사라지지 않았다. 도구를 잘 쓰는 사람이 더 좋은 결과를 낸다.
변하지 않는 것이 있다. 흐름을 이해하는 능력. 문제를 해결하는 집요함. 소통하는 능력. 스케줄을 관리하는 습관. 25년 전에도 중요했고, 지금도 중요하고, 앞으로도 중요할 것이다.
결국 본질은 같다. 도구가 바뀌었을 뿐이다.
흐름을 따라 걷는다는 것
디자이너가 되고 싶었다. 두꺼운 A4 파일을 들고 면접을 다녔지만 비전공자는 서류에서 떨어지기 일쑤였다. 디자인 일을 준다더니 개발을 시켰다. 어느새 25여 년이 흘렀다.
3D 디자이너, 부동산 법무, 회계까지. 이직이 잦다고 할 수도 있다. 하지만 모든 경험이 지금의 나를 만들었다. 다양한 직종을 경험했지만 회사 내부에서는 40퍼센트 정도는 IT와 관련된 개발 업무를 꾸준히 했다. 다양한 직종 경험이 서로 연관되어 분야 간 이해와 업무를 대하는 태도와 시야가 넓어졌다.
프로젝트는 혼자 하는 게 아니다. 메일 하나 놓쳐서 일주일 지연됐던 일, 3만 줄짜리 파일을 인수인계받고 처음부터 다시 짰던 일, 8개월 진행된 프로젝트 방식을 1주일 만에 바꿔 PL이 됐던 일. 현장의 경험들이다.
개발은 코드만 잘 짜면 되는 게 아니다. 화면설계서 100페이지 중 담당이 3페이지라도 전체를 봐야 한다. 데이터가 어디서 와서 어디로 가는지, 그 흐름을 이해해야 제대로 된 개발이 가능하다.
개발은 알고리즘이나 프로그램 언어 습득을 생각하기 쉽지만, 이런 것들은 누구나 자체적으로 공부하거나 경험을 쌓으면서 습득할 수 있다. 회계나 경리를 해도 차변, 대변, 재무제표는 기본적으로 알고 시작하듯이 프로그램 개발도 언어는 기본 지식이 있어야 한다. 하지만 이런 기본적인 바탕 지식이 기준이 될 수는 없다. - 기준이 될 수 없을 정도로 당.연.한. 것이다. -
일에는 항상 마감이 있고 오로지 혼자서 하는 일은 없다. 영화에서 나오는 개발자들은 언제나 컴퓨터만 들여다보고 항상 혼자서 개발하는 이미지로 가득하다. 실제로는 혼자서 개발하는 경우는 찾아보기 힘들다. 혼자서 아이디어를 생각하고 기획하고 디자인, 개발, 출시까지 하고 일반 고객을 직접 상대하면서 유지보수까지 혼자서 하고 돈을 벌 수 있다면 혼자서 해도 무관하다.
그런 경우가 아니라면 돈은 클라이언트 고객으로부터 나오고, 클라이언트 고객이 정한 출시일을 지켜야 하기에 스케줄 관리는 필수다. 클라이언트 고객이 생각하는 방향으로 개발되어야 하기 때문에 소통은 중요한 요소가 된다. 아이디어를 구현하기 위해서 데이터와 로직이 어떻게 흘러가야 하는지에 대한 이해도가 필요하다.
프로그래밍 분야를 취업하기 위해서는 언어 학습만이 중요한 것이 아니다. 언어는 부차적인 요소다. 프로그래밍 또는 코딩의 기본만 제대로 이해하면 어떤 언어든 어렵지 않게 습득하거나 다룰 수 있다. 시스템에 대한 관심과 호기심은 무엇보다 중요하다. 프로그래밍은 혼자서 하는 개발이 아니다. 여러 명이서 협업하여 만드는 것이기에 다른 사람과의 소통도 중요하다.
개발자는 코드만 잘 작성하고 자격증만 따면 되는 게 아니다. 팀원 간 소통과 업무와 관련된 정리가 필요하다. 자격증은 참고용이지 필수는 아니다. IT 개발 분야에서는 정보처리기사만 있으면 된다. 필수라는 말은 아니다. 바리스타 자격증처럼 개발을 할 수 있다는 자격 증명 정도일 뿐이다.
학원에서 강사를 하고 있을 때까지만 해도 자격증이 하나도 없었다. 학원에서 강사는 자격증을 가지고 있어야 한다는 말에 1년 안에 4개의 자격증을 습득했다. 별도로 공부한 것은 없고 시험 이틀 전에 문제집 하나 풀어본 게 다다. 8년 동안의 경험을 통해 실력을 인증받은 것에 지나지 않았다.
개발은 전체적으로 흘러가는 모습을 알아야 제대로 된 결과가 나온다. 시스템은 흐름이다. 프로젝트가 전반적으로 흘러가는 과정과 시스템 흐름을 이해해야 한다.
처음부터 프로그램 개발 분야를 선택한 것은 아니었다. 디자인을 하고 싶었다. 학교 수업과 병행으로 디자인은 독학으로 했다. 취업 전선에 뛰어들었지만 전공자와 독학의 체감은 예상외로 멀었다. 실력은 둘째치고 서류에서 탈락하는 게 다반사였다. 어렵게 들어간 회사에서도 디자인보다는 개발 쪽으로 업무를 할당하는 경우가 많았다.
결국 지금은 개발을 주로 하고 있다. 디자인은 사람과 사람 간의 업무지만, 개발은 사람과 컴퓨터 간의 업무다. 결과가 디자인보다는 확실하기 때문에 사람에 대한 스트레스는 없었다. 다만 풀리지 않는 코드를 만났을 때는 며칠을 고민한다. 고민이 해결됐을 때 그 쾌감은 경험하지 못하면 느낄 수 없다.
흐름을 따라 걷는다. 시스템의 흐름, 프로젝트의 흐름, 기술의 흐름. 거스르지 않고 따라간다. 새로운 기술이 나오면 배운다. 새로운 프로젝트가 주어지면 적응한다. 25년간 그렇게 걸어왔다. 앞으로도 그렇게 걸을 것이다.
여전히 걷는 중이다.
