GPT와 함께 EAC를 개발하는 과정에서 떠오른 몇 가지 생각을 가볍게 기록해 둡니다
풀스택 엔지니어에 대한 미신
따지고 보면 EAC의 디자인, 프론트엔드, 백엔드, 데이터베이스 등 모든 것을 제가 도맡아 작업했으니, 원칙적으로는 풀스택 엔지니어라는 모자를 써도 될 것입니다.
하지만 솔직히 말해 저는 이 모자를 좋아한 적이 한 번도 없으며, 애초에 모자(꼬리표) 자체를 별로 좋아하지 않지만 특히 풀스택 엔지니어라는 타이틀은 더욱 좋아하지 않습니다.
라벨이나 모자는 저마다 하나의 문턱이자 하나의 묘비와도 같아서, 굳이 이렇게 분류해 버린다면 아무런 재미도 없습니다.
성숙한 엔지니어라면 다양한 분야를 두루 경험해 봐야 하며, 엔지니어링에서 천재적인 발상이 발휘되는 지점은 바로 하나의 아이디어를 서로 다른 기술을 통해 실제로 구현해 내는 데 있습니다.
더욱 중요한 점은, 전체 개발 과정에서
풀스택 엔지니어라는 모자는 존재하지 않는다는 사실입니다!
흥미로운 점은 제가 개발했던 첫 번째 버전이 매우 혼란스러워 엔지니어링 측면에서 거의 재앙에 가까웠는데, 그 이유 중 하나가 바로 제가 풀스택 엔지니어라는 모자를 쓰고 있었기 때문이라고 생각합니다.
이 모자를 쓰다 보니, 가령 프론트엔드 페이지를 작성할 때 디자인이나 에셋 작업도 없이 바로 코딩부터 시작했습니다. 데이터베이스 테이블 역시 떠오르는 필드가 있으면 즉석에서 바로 수정해 버렸죠. 그 결과 갈수록 혼란스러워져 도저히 풀스택으로 감당할 수 없게 되었고, 이후 개발 과정에서 온갖 문제가 점점 더 많이 불거져 결국 많은 부분을 갈아엎고 다시 시작해야 했습니다.
사실 아무리 많은 기술을 가진 사람이라 해도, 실제로 어떤 일을 할 때는 오직
한 번에 모자 하나만 쓸 수 있습니다
예를 들어 프론트엔드 페이지를 만들 때 디자이너라는 모자를 쓰고 있다면 UI, UX 등 디자인의 합리성에만 집중해야 합니다. 만약 두 개의 모자를 동시에 쓰려고 한다면 생각이 충돌하게 됩니다.
마찬가지로 운영/관리라는 모자를 썼을 때는 개발에 대한 생각은 접어두고, 커뮤니티를 어떻게 관리하고 규칙을 세울 것인가에만 집중해야지 개발 난이도를 먼저 생각해서는 안 됩니다.
마찬가지로 엔지니어라는 모자를 썼을 때는 어떻게 성능을 최적화하고 작업량을 줄일 것인지를 고민해야 합니다.
모자는 자신의 손에 쥐고
어떤 배우가 그러더군요. 충분한 시간만 주어진다면 누구나 어떤 배역이든 소화할 수 있다고요. 거센 바람과 파도가 몰아칠 때 우리는 우왕좌왕할 수도 있습니다. 저에게 중요한 점은, 모자는 자신의 손에 쥐어져 있고 배역은 스스로 선택한 것이라는 점입니다. 연기를 잘하고 못하고를 떠나, 머리 위의 모자를 벗고 손에 쥔 다른 모자들을 생각하는 법을 잊어서는 안 됩니다.
읽어주셔서 감사합니다. Hat off to you.