brunch

매거진 레터 드 메튜

라이킷 16 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 메튜 Aug 31. 2023

백엔드 개발자의 핵심은 무엇인가.

단순 코더에서 백엔드 개발자가 되던 핵심.

2009년도, 신입 개발자(=병특) 시절때의 일이다. 회사에 파견나온 모 프리랜서 과장님이 Spring으로 회사에서 발주받은 정부프로젝트를 만들고 있던 때이다. (그 때도 나는 이 블로그를 운영하고 있었긴 하지만..) Spring을 기반으로 여러가지 프레임워크들이 들어갔는데 그중 기억나는게 ibatis라는 ORM(Object-relation Mapping, SQL객체와 자바 객체를 연결) 툴과 velocity라는 템플릿 엔진이었다. 여기에 당시 한참 유행하던 jQuery까지.

당시 유행하던 자바 구성들.

어쩌다 나도 이 프로젝트에 투입이 되었는데, 그전까지 나는 주로 ASP랑 ASP.NET 1.1 (...) 로 만들어진 사이트 유지보수만 했었는데 사실 별거 없고 그냥 윈도우 서비스로 돌아가던 해당 웹사이트들이 장애나면 껏다켜주고 딱히 신규 모듈 추가는 안하고 거의 프론트엔드에 이리저리 추가만 하던 시절이었다. 단순 HTML코딩과 자바스크립트만 하다가 지쳐서 가끔 jQuery나 Prototype (!!) 을 끄적이고만 있던 시절.

회사입사 이전에 하던 일이 주로 당시 유행하던 자바 빈즈로 모델 1이나 구현하던 경력아닌 경력을 가지고 있던 때라서 Spring의 그 구조에 대해서는 아주 막 크게 어려움은 없었다. 뭐 스트러츠나 비슷한 프레임워크에서 IoC같은 개념들이 들어온거라 했는데 그땐 뭐 그런걸 알리가 있나.. 사실 참여했던 팀에서도 환경구축은 이미 윗선에서 다 끝내놓고 나는 velocity만 찍어내던 때였다. domain.com/cmd=listUser 같은 URI분기같은건 전혀 개념도 없었고, 어쨌건 대부분의 연동은 다 끝나서 그냥 나는 PM이 주는 서비스 페이지 기획대로 찍어내기만 하면 됬다.

난 어쨌던간에 신입이었으니, 코어한 기능인 뭐 토큰이나 Auth 같은 개발기회는 전혀 없었고 그저 CRUD에 맞는, 일종의 게시판 보기, 글쓰기, 수정, 삭제 같은 기능만 할 수 있었다. 신입이었으니 당연히 그냥 기존에 있던 비슷한 페이지에 있던 로직 불러왔었고, velocity템플릿 엔진에서 뭐 헤더 푸터는 common으로 빠져있으니 손댈 것도 없었고.. 그리고 무엇보다, 내가 보기에는 이 페이지들이 별로 누가 쓸 것 같지도 않았다. 그러니깐 즉, 그냥 프론트만, 그것도 그냥 한국에서 말하는 "코더" (지금은 이 용어를 쓰려나?) 질만 덕지덕지 하던 것 같다.

어쨌든 복붙을 열심히 하고 있던 찰나, 한참 담배를 피던 시절 회사 입구에서 흡연가들과 얘기하며, 갑자기 전체 시스템을 아키텍처링 하셨던 과장님이 네덜란드로 MBA유학을 가신다 하더라. (지금은 잘 사시련지..) 내가 왈, "과장님 유학가시기 전에 백엔드 소스코드좀 주시면 안되요?" 라고 하니 "그게 내 전재산인데 어떻게 줄 수 있겠어요." 라고 한다.

"그게 내 전재산인데 어떻게 줄 수 있겠어요."

우와, 난 백엔드가 돌아가는 아무 로직도 소스를 본 적이 없으니, 아니 백엔드만 가지면 정말 전재산을 가지는게 될까 싶었다. 난 호시탐탐 그 백엔드 코드를 볼 수 있기만을 노렸었다. 거의 기회가 없던 찰나, 사실 중소기업 병특들은 단순 코딩만 한다면 그건 신의 직장이라고 볼 수 있는데 나는 당연히도 탕비실 청소, PC견적, 윈도우 깔기 및 이메일 세팅 등의 작업을 담당했었다. (사실 그게 너무 싫어서 1년뒤 이직함.) 마침 어느순간 그 과장님의 컴퓨터를 수리할 일이 있어서 어쩌다보니 코드를 보게 되었는데 당시에는 알아보지도 못해서 가지고 있던 폰으로 소스를 사진으로 마구 찍었던 기억이 난다.

나중에 프로젝트가 끝나고, 과장님은 유학을 가시고, 집에서 사진을 분석해 봤는데 기존에 알고있던 스트러츠나 JSP 모델과 별반 차이는 없었다. 그냥 좀더 깔끔하게 정리된 정도랄까.. 대부분의 요청들은 나도 가지고 있던 PM업무요청서에 다 있던것들이고.. 이게 핵심 기능이었구나 ㅎㅎ 그런데 왜 java파일은 안주고 class만 공개했던건지.. 그 과장님이 참여했던 다른 프로젝트의 소스도 다 살펴보니 java파일이 없더라. (당시 회사에서 발주받은 프로젝트는 난 병특이니 당연히 열심히 유지보수 하고 있긴 했다.) 원천 코드를 아에 숨기는게 전재산을 숨기는 기술이라.. 상당히 의아했지만 다른 회사로 이직하면서도 나는 자주 백엔드 개발자들이 원천 코드를 숨기는 모습을 보았다.

외국 개발자들이랑 일하면서 내가 느끼는 것은 원천코드를 숨기는 것은 아무런 의미가 없다는 것이다. 자바야 역어셈블리 하면 요즘엔 코드도 잘 나오고, 아무리 소스코드를 잘 가지고 있다 한들 표기된 라이센스를 어기면 법적 대응으로 가서 천문학적 소송비용이 발생할 수도 있다. 그런 지적재산권에 대한 무서움(?)을 알고 나서는 그냥 스스로 조심을 하게 되더라. 그리고 무엇보다, 사실 프레임워크가 주는 Best Practice가 있고 요즘에는 Stackoverflow, 구글링을 넘어서 ChatGPT나 Bard가 있는 시대이다. 이럴때일수록 무슨 사람이 되어야 할까?

모든게 오픈북처럼 오픈된 세상에서 결국엔 얼마나 빨리, 문제에 대한 답을 상황에 맞게 명료하게 내리는 것이 아닐까. 기본적으로 탄탄한 이론에 대한 지식과 (자료구조나 웹 프로토콜 구조, 서버/클라이언트 간 트랜젝션 프로토콜, 보안 등) 빠르게 웹의 그 답을 가지치기 할 수 있는 능력, 그리고 무엇보다 스스로를 낮추고 모든 틀릴 수 있는, open-ended에 대한 열린 마인드가 더 중요하지 않을까. 프레임워크 등의 기술은 정말 빠르게 버전업 하지만 사실 까놓고 보면 오래전부터 논의된 문제점에 대한 보안이나 best practice일 경우가 많으니깐.

결국엔 아무리 잘난 자바 코드를 가지고 있어봤자 나보다 잘난 코드는 이세상에 천차만별로 많고, 내가 가진 잘난 코드도 사실은 까놓고 말하면 원천은 거의 대부분 나 스스로가 아닐 확률이 높기 때문이다. 물론 소프트웨어 외에 대부분의 공학적 분야에 적용이 되겠지만, 잘 생각을 해야한다. 결국 나도 이를 이해한 어느순간부터 소스코드에 대한 집착을 버리기 시작했으니. (오픈소스가 90%이상이라면 그건 내가 만든게 아니라 짜집기 한게 아닐까 라는 생각.)

결국 이 백엔드, 아니 웹의 세계는 핵심을 가지고 끝없이 파생되는, 그런 세계인 것 같다. 그리고 이게, 내가 한국에서 일할 때의 결론이었다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari