개발자가 뭐예요?
개발자 입문에 관하여
신기하게도 개발자 커뮤니티에서만 편 가르기 하는 경우를 많이 접한다. 컴퓨터 공학 전공자, 비전공자, 국비지원학원출신, 부트캠프출신, 프론트엔드, 백엔드와 같이 막상 개발회사에 입사하면 아무 상관도 없다. 결국 자신의 실력에 모든 게 달려있다. 시시콜콜 편 가르기 해봤자, 지금 이 자리에 모인 개발자들 아닌가? 현실에선 중요한 부분이 아니다.
코로나 시기에 집에서 격리를 하거나 재택근무 하는 경우가 많아져서 모바일 앱 회사가 급성장하면서 개발자 붐이 한번 온 적이 있었다. 부트캠프가 활성화되던 시기였다. 짧고 굵게 캠프형식 학원에 들어가서 프로젝트 단위로 개발을 해보고 완료한 것을 포트폴리오 삼아 개발자에 지원하는 케이스였다. 국비지원학원은 6개월 동안 국비지원학원을 수료하고 개발자로 나가는 경우이다. 국비지원도 출석률이 저조하면 중간에 퇴소처리되기 때문에 쉬운 과정은 절대 아니다. 전공자 같은 경우는 컴퓨터 공학과 졸업 후 개발회사에 지원할 것이다.
본격적으로 개발자 직무로 면접을 보다 보면 제일 먼저 고민하는 부분이 SI(시스템개발) 회사와 솔루션 회사이다. 제일 큰 차이점은 SI업체는 입사하게 되면 SI업체 소속으로 크고 작은 프로젝트에 투입되어 파견을 나가서 개발업무를 하고, 솔루션 회사는 한 회사에서 밑바닥부터 계속 회사 솔루션 관련 개발을 한다. SI업체의 장점은 프로젝트마다 개발환경에 다르기 때문에 다양한 개발 스킬을 배울 수 있다. 하지만 악덕 SI업체를 가게 되면 경력 뻥튀기를 해서 신입인데 경력 3년 대리급으로 가서 감당할 수 없는 개발을 하게 되어 사람들한테 욕만 먹고 중간에 잘릴 수도 있다. 반면에 솔루션 회사는 파견이 아닌 회사 내의 자체 솔루션으로 프로젝트를 진행하거나 SM(운영, 유지보수) 업무를 하여 개발환경에 적응을 하면 오래 버틸 수 있다. 하지만 한 회사의 개발환경만 적응하다 보니 우물 안의 개구리, 고인 물이 될 수 있다. 솔루션 회사에만 있다가 SI업체 가서 프로젝트를 나가게 되면 개발환경에 적응도 못하고 자존감이 바닥을 칠 수도 있다. 위의 장단점을 보고 자신이 어디로 가야 할지 정말 많은 고민을 해야 한다.
요즘은 프론트엔드(앞단), 백엔드(뒷단)라고 불리는 부분이다. 개발을 하게 되면 일반적으로 고객이 보는 사이트를 프론트엔드라고 하며 직원들이 관리를 위한 시스템을 백엔드라고 한다. 프론트엔드는 스크립트 관련 화면에 특화되어 있고, 백엔드는 관리를 위한 복잡한 로직이나 batch(자동실행) 들을 만든다. 물론 원하는 직무로 갈 수 있겠지만, 경력이 쌓이다 보면 어차피 둘 다 해야 하는 부분이다.
개발자가 되면 제일 먼저 익숙해져야 하는 부분은 역시나 코딩이다. JAVA 개발자 기준으로 본다면 조건문, 반복문, 상속, 배열, DB쿼리이며 만약 JAVA Spring 프레임워크라면 기본적으로 개발할 때 해야 하는 구조 정도는 반복 숙달해야 한다. (Controller, Service, ServiceImpl, Repository, mybatis)
개발자로 일을 하게 되면 가장 오해하는 부분이 끊임없이 공부를 한다고 생각한다. 반은 맞고 반은 틀린 것 같다. 자신이 코딩하고 오류를 못 잡아서 검색하는 경우가 더 많고, 만약 처음 도입하는 신기술이라면 공부를 해서 실무에 적용해야 한다. 공부라기보단 문재해결을 위한 정보수집이 더 많은 부분을 차지한다.
개발에서 제일 중요한 것은 적응이다. 적응력은 개발자마다 차이가 있다. 개발환경에 빨리 적응해서 개발을 해내는 사람이 있고, 적응하는데 시간이 걸리지만 적응만 되면 엄청난 퍼포먼스를 보이는 개발자도 있다. 다양한 화면, 복잡한 화면들을 개발을 해본 개발자들이 중장기적으로 볼 때 개발속도가 엄청 빠르다. 한 번이라도 해본 화면과 동일한 구조의 화면이 나오면 복사 붙여 넣기만 잘해도 순식간에 화면하나가 만들어지기 때문이다.
이제 개발로 한 사람의 역할을 할 수 있게 된다면 그다음으로 중요한 부분은 사람이다. 중간 관리자를 잘 만나야 한다. 중간 관리자라고 하면 과장(책임), 차장(수석)급의 능력 있는 사람을 만나야 개발에 관하여 배울 점이 많다. 하지만 어딜 가나 모난 사람 한 명쯤은 있길 마련이다. 제발 모난 사람이 내 윗선이 아니길 바라야 한다.
웬만한 개발을 할 줄 아는 개발자가 되면 업무파악을 잘해야 한다. 기획안이나 중간관리자에게 지시를 받아서 개발을 할 때 해당 개발건에 대한 프로세스를 정확히 파악하지 못하면 초기 개발부터 잘못될 확률이 높다. 설명을 기반으로 개발로 구현해 낸다는 생각을 가져야 한다. 업무적으로 이해가 안 되는 부분을 그냥 지나치고 개발을 하면 초기, 중반 개발한 걸 엎고 다시 개발할 수도 있다.
그다음 개발 검증의 시간 디버깅이다. 디버깅 방법은 여러 가지가 있다. 브라우저 개발자 모드에서 브레이크포인트를 걸어서 보는 방법이 있고, 로직을 적용하기 전 sample을 만들어서 계속 로직만 돌려볼 수도 있다. JAVA기준 내가 확인할 부분에 브레이크포인트를 지정하고 디버깅 모드로 서버를 시작하여 해당 부분을 자세히 볼 수도 있다. 브레이크포인트로 소스가 이동하면 F6키로 한 줄 한 줄 나려 가면서 변수의 값을 살펴보거나 배열의 값을 계속 확인해봐야 한다. 이렇게 한 번만 하는 게 아니라 세 번 이상은 해야 한다. 그래도 운영 반영시 오류가 발생할 수도 있다. 데이터가 그만큼 다양하기 때문이다.
어느 유명한 개발자분이
"자신은 디버깅 잘하는 사람들 중 개발 못하는 사람 본 적이 없고, 개발 못하는 사람들 중 디버깅 잘하는 사람을 본 적이 없다"라고 했다.
나의 개인적인 생각으로도 개발 완성도에서 디버깅이 차지하는 비중은 60% 정도 되는 것 같다.
그 밖에 개발에 대한 흥미, 재능, 적성에 달려있다. 익숙해지고 많이 경험해 보고 이제 개발이 할만하다고 생각했을 땐 흥미가 있고 적성에 맞는 거라고 보고, 이제 웬만한 건 할 줄 안다 싶을 때, 그 시점에서 좀 더 깊게 파고들어서 내가 개발하는 프레임워크 코어까지 알게 된다면 재능이 있는 것이다. 그리고 다른 개발자와 경쟁하려 하면 안 된다. 나만의 개발 템포, 나만의 개발 순서 정하고 생각이 복잡해졌을 때 지금 당장 할 일 하나만 메모장이든 일지에 적어놓고 초기화한다는 생각으로 컴퓨터 재부팅하듯이 열려있는 잡다한 것들을 다 지우고 할 일 하나만 집중하다 보면 어느덧 능력 있는 개발자가 되어있을 것이다.
개발자는 천재가 아니다. 개발도 사람이 하는 일이고 사람이 하는 일이기에 오류나 장애가 날 수도 있다. 그리고 업무적으로 세분화하면 커머스, MES(공장 자동화), PLM(제품 생산 프로젝트), 유통, 물류 등등과 같이 겪어보지 않으면 모르는 세상이 존재한다. 개발자에 관심이 있는 분에게 아주 조금이라도 도움이 되었으면 좋겠다.
