brunch

매거진 기술이 세상을 이롭게 변화시킨다1

라이킷 43 댓글 4

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 박용권 Jan 15. 2016

조금 더 나은 개발자가 된다는 것

콘퍼런스의 발표자가 된다는 것

머릿속에 떠돌던 로직 한 토막이 내 손을 거쳐서 전기 배선을 타고 실리콘의 힘을 빌어 가상세계에 현현하고, 마침내 현실의 사람들과 의미 있는 관계를 맺는 존재가 되는 그런 경험, 무엇과도 견줄 수 없는 그 짜릿함을 떠날 수 없는 사람들...

'프로그래머의 길, 멘토에게 묻다'라는 책에 나오는 문장이다.

글을 읽으며 이보다 더 '개발자'를 잘 표현한 글을 없을 거라는 생각이 들었다. 필자 또한 내 손으로 만든 웹 애플리케이션이나 데스크톱 응용 애플리케이션을 사용하는 사람들을 보며 말로 표현하기 어려운 뿌듯함을 느끼기 때문에 개발자로서 삶을 꾸려나가고 있기 때문이다.

개발자들이 만드는걸 보통 애플리케이션(Application)이라 부른다. 요즘은 줄여서 앱(App)이라는 표현도 자주 사용된다. 애플리케이션의 종류는 무척이나 다양하다.

몇 가지만 말해보자면 금융 기관에서 사용되는 상거래 애플리케이션, 사람들의 스트레스를 재미로 풀어주는 게임 애플리케이션, 밥솥을 비롯한 다양한 전자기기에 들어가는 임베디드 애플리케이션, 웹 브라우저를 통해 다양한 정보들을 보고 들을 수 있는 웹 애플리케이션 등 다양한 애플리케이션들이 있다. 그러다 보니 애플리케이션 별로 전문화된 지식과 풍부한 경험이 필요하게 되면서 이를 개발하는 개발자들을 웹 개발자, 임베디드 개발자, 앱 개발자, 소프트웨어 개발자 등으로 개발하는 영역의 이름을 붙여 부른다.

다양한 개발자 중에서 `백엔드 개발자` 또는 `서버사이드 개발자`라고 부르기도 하는 '애플리케이션 서버 개발자'에 대해 잠시 이야기를 해보려 한다.

'애플리케이션 서버 개발자'라는 말은 현재 필자가 활동하고 있는 개발자 커뮤티니, 한국 스프링 사용자 모임(Korea Spring User Group, KSUG)의 고문이신 박성철님과 이야기하며 처음 들었다. 개인적으로 백엔드나 서버사이드라는 표현보다 조금 더 일반적이고, 비개발자에게 설명하기 쉬워서 주욱 그렇게 부르고 있다.

하는 일을 정리해 보면 요구사항에 대한 수집 및 분석부터 로직의 설계/구현 및 시스템 통합, 유지보수 그리고 운영과 같은 일을 하는 개발자라고 할 수 있다. 다양한 일을 하고 있기 때문에 배우고, 익혀야 하는 것들이 한도 끝도 없이 많은데, 크게 세 가지로 영역으로 정리해보았다.

그 첫 번째는 애프리케이션을 개발하기 위한 기술들이다. 프로그래밍 언어는 물론 기본적인 알고리듬이나 자료 구조 지식을 갖추고 다양한 라이브러리(Library)와 프레임워크(Framework) 등을 다룰 줄 알아야 한다.

더 나아가 객체지향 프로그래밍(OOP), 함수형 프로그래밍(FP), 리팩터링(Refactoring), 디자인 패턴(Design pattern), 개발자 테스트 등 복잡성을 다루고 생산성을 높이는 실천법들을 활용할 줄 알아야 한다. 그리고 데이터베이스(Database)부터 Web Application Server(WAS), Message Queue, 캐시(Cache), 메일(Mail) 등의 백엔드(Backend) 시스템 연동 기술과 HTTP, FTP, TCP/IP 등의 프로토콜 기반의 네트워크 프로그래밍 기술도 익혀야 한다.

두 번째로 아키텍처를 다루기 위한 지식과 경험을 키워야 한다. 프로그래밍에 대한 기술을 공부하고 사용하며 경험을 쌓다 보면, 조금 더 먼 곳이 보이기 시작하며 큰 그림을 그리는 기술을 익힐 수 있다. 사용자의 요구사항 분석과 애플리케이션 설계/모델링, 전체 시스템을 메인과 서브 시스템으로 나누거나, 여러 시스템을 통합하는 구성할 수 있어야 한다.

그리고 마지막 세 번째로 팀 협업이나 품질, 생산성들을 향상하기 위해 프로젝트 지원 도구 및 실천법들을 활용할 수 있어야 한다. 형상관리 도구인 Git이나 SVN, Ant / Maven / Gradle 등의 빌드 툴, Jenkins나 Travis와 같은 CI(Continuous Integration) 툴, Jira / Redmine 등의 이슈 관리 툴들이 프로젝트 지원 도구이다. 그리고 Scrum, XP 같은 애자일 방법론과 각종 협업 기법을 잘 이해하고 활용해야 한다.

이외에도 Use case, User story, UML, ERD 등 산출물 작성/시각화 기법들 또한 익혀야 한다.

이쯤 되면 과연 이 길이 `내 길이 맞는가?` 하는 의문도 들고, 기가 질리기도 한다.

하지만, 포기하지 말자!!!

애플리케이션을 개발하고 사람들과 교류하며 얻을 수 있는 짜릿한 경험을 위해서라도.. ^^

모든 걸 완벽하게 다룰 수는 없겠지만, 언젠가는 다 할 수 있다.

지금은 내가 관심을 가지고 있는 영역부터 조금씩 배우고, 익혀보자. 이때 중요한 것은 하나의 기술을 완벽하게 소화해야 한다는 생각을 버려야 한다는 것이다. 지금 당장 내가 필요한 만큼만 또는 배울 수 있는 만큼만 다루고 나머지는 그런 게 있었어... 하고 넘어가는 여유가 필요하다.

그리고 조금 더 성장한 후에 다시 돌아오면 이전보다 더 많은 걸 배우고, 익힐 수 있을 것이다.

너무 어려워서 지치고, 힘들면 스터디 그룹이나 개발자 커뮤니티에서 다른 개발자들과 함께 해보기를 권한다. 혼자가 아니라 여럿이서 나누어 공부하면 조금 더 동기부여가 되고, 많은 어려움을 함께 해결해갈 수 있다. 또 다른 개발자들이 어떻게 기술을 다루는지를 보면서 더 빠르게 성장할 수도 있다.

하지만 그렇게 어렵게 배우고, 익힌 기술을 실무에 사용해보면 약간의 난관에 봉착하는 경우가 많다. 책, 튜터리얼, 교육기관 등을 통해서 배운다고 해도 내가 만들고 싶은 애플리케이션은 레고 블록을 조립하듯이 탁탁 꽂으면 만들어지는 물품이 아니다.

프로그래밍 기술이라는 건 상황에 따라 적용하는 형태가 조금씩 다르다. 하지만 모든 상황에 대해 자세하게 다루는 책이나 교육기관은 없다.

그럴 때 우리는 주위에 선배나 동료들에게 묻고 배우고, 또는 개발자 커뮤니티 사이트나 스택 오버플로우(Stack Overflow) 등을 통해 온라인으로 질문과 답변을 주고받고, 그리고 검색 서비스를 통해 해결책을 찾아낸다. 이 세 가지 경우에는 하나의 공통점이 있다.

자신이 경험했던 것을 블로그에 기록하는 사람, 누군지는 모르지만 곤란을 겪고 있는 개발자를 위해 온라인으로 답글을 달아주는 사람, 이해 못할 버그로 정신이 붕괴된 후배를 일으켜 세워줄 조언을 던지는 선배... 바로 내가 겪었던 경험을 나눠주는 사람들이 있다는 거다.

그중 콘퍼런스(Conference)나 세미나(Seminar)는 나와 비슷한 일을 하는 개발자들이 모여 경험과 지식들을 공유하는 최고의 장이다.

발표라는 건 내가 가진 지식이나 경험을 타인에게 전달하는 자리다. 그렇기 때문에 발표를 하기 위해선 자신의 지식이나 경험을 정리하는 시간이 필요하고, 정리를 하다 보면 발표자 스스로도 굉장한 성장을 하게 된다. 또한 그렇게 정리된 지식과 경험을 공유받는 청중들에게도 큰 도움이 된다.

필자는 2008년부터 한국 스프링 사용자 모임(Korea Spring User Group, KSUG)이라는 개발자 커뮤니티에서 활동을 하고 있고, 현재는 일꾼단(KSUG는 운영진이라는 단어를 쓰지 않는다)에 소속되어 크고, 작은 행사(세미나, 번개 등)를 진행하고 있다.

세미나 행사에는 발표자가 빠질 수 없는 존재이다. 그렇기에 행사를 준비하는 과정에서 주변 개발자들에게 `이번에 경험하신 그 내용에 대해 발표 한번 해주세요!` 라는 요청을 정말 많이 한다. 이 요청에 대해 필자가 듣는 대답의 대다수는 '내 수준에 뭘... ' 이라던가 '내 실력이 미천해서..', 혹은 '이 정도 주제로는 발표하기가...' 이다.

공자께서 말씀하시기를 "세 사람이 길을 같이 걸어가면 그중에 반드시 내 스승이 있다. 좋은 것은 본받고 나쁜 것은 살펴 스스로 고쳐야 한다[三人行必有我師焉擇其善者而從之其不善者而改之]."

《논어(論語)》의〈술이편(述而篇)〉에 나오는 말이다. 세상을 살아가는데 있어서 누구든지 나의 스승이 될 수 있음을 말씀하셨다고 생각한다.

필자는 4년차 개발자는 2~3년차 개발자들에게 자신의 경험을 나눠줄 수 있을 것이며, 7년차 개발자는 5~6년차 개발자들에게 자신의 경험을 나눠줄 수 있을 거라고 생각한다. 개발자를 년차로 나누는것을 좋아하지도 않고, 믿지도 않지만 비유를 들어 말을 하자면 그런 것이다.