To OO님,

풀스택을 해야하는가에 대한 고민 잘 읽었어. 엔지니어 성장과 프로덕트 두 가지 관점에서 풀스택을 지향하는 것은 당연하다고 생각해. 엔지니어는 기술을 사용하여 문제를 해결한다고 정의했지? 엔지니어가 성장한다는 것은 점점 더 효율적(더 빠르고 정학하게)으로 문제를 해결할 수 있게 되는 것을 의미해. 특히, 프로덕트 관점에서 문제 해결을 하려면 여러 해결 방법들에 대해 가장 빠른지 또는 효율적인지를 판단하기 위해 여러 기술을 알아야 필요가 있어. 이러한 이유들로 결국 영향력 있는 엔지니어가 되려면 풀스택을 해야 하는데 그 이유를 자세히 설명해 줄게.

효율적인 문제 해결을 위해

예를 들어, 앱의 로딩시간이 길어 사용자가 이탈한다는 문제를 해결하기 위해 담당 엔지니어들이 해결 방법과 필요한 일정을 제안했어.

  • 백엔드 : API 성능 개선 / 3일

  • iOS : 로딩 상태 애니메이션 인디케이터를 추가 / 1일

  • AOS : 로컬 캐시를 이용해서 api 호출을 줄임 / 2일

과연 어떤 해결 방법을 선택해야 할까? 사용자의 이탈을 막기 위해서 어떤 방법이 가장 효율적일까? 효율적이란 의미는 가능한 빨리, 적은 리소스로 해결해야 한다는 거야. 이런 상황에서 의견을 내거나 결정을 하려면 프로덕트를 이루고 있는 전반적인 기술에 대해 지식과 경험이 필요해. 그렇다면 풀스택을 하기 위해 당장 다른 직군으로 전향해서 시작해야 할까? 그럴 필요는 없어. 이직이나 팀 이동 없이 지금부터 서서히 시작할 수 있어.

프로덕트 구성 기술에 대한 관심 갖기

백엔드 엔지니어니깐 Spring framework를 잘 다루면 된다고 생각하겠지만 앞으로 빠르게 성장하려면 기술을 깊고도 넓게 바라보는 시야가 필요해. 특히, 우리 팀의 프로덕트를 구성하고 있는 전반적인 기술에 관심을 갖도록 해. 이번에 내가 구현한 api를 호출하는 프론트엔드의 경우 Server Side Rendering를 사용하고 있는데 장, 단점은 무엇인지? 안드로이드의 경우 이미지 라이브러리로 요즘 coil을 많이 쓴다는데 기존에 사용하던 glide와는 어떤 차이가 있는지? 등 호기심을 갖는 것 부터 시작해봐. 구글링을 통해서도 좋은 결과를 많이 찾아볼 수 있겠지만 좀 더 깊은 이해가 필요하다면 해당 챕터 엔지니어에게 도움을 청하는 것도 좋아. 아마도 기꺼이 잘 설명해 줄거야.

프로덕트의 동작을 버티컬 관점에서 이해하기

전반적인 기술에 관심이 생겼다면 이제 어떻게 동작하는지 이해해 보는거야. 기존에 구현에 참여했던 간단한 기능부터 시작해 보는게 좋아. ‘좋아요’ 기능을 예로 들어볼까?. 사용자가 뷰에서 ‘좋아요’ 버튼을 클릭하고 나면 실행 완료 레이어를 보게 되는데 이 과정을 쭉 따라가 보는거야. 사용자가 ‘좋아요’ 버튼을 클릭하면 해당 버튼 컴포넌트에서 api를 요청하는 함수를 호출하겠지? 컴포넌트에서 api의 endpoint를 호출하면 이후 과정은 백엔드에서 처리해. 백엔드 api의 endpoint는 해당 Controller의 함수로 연결되어 있어. 이때 로그인 여부를 확인한 후 비로그인 상태면 로그인 뷰로 이동시키고, 로그인 상태면 좋아요 관련 비즈니스 로직이 작성되어 있는 Service를 호출하여 아래의 작업들을 수행해.

  1. 사용자 A가 해당 포스팅을 좋아한 것을 DB의 해당 테이블에 저장

  2. 좋아요 수를 카운트하여 해당 테이블에 업데이트

  3. 사용자 로그 데이터 저장

  4. 포스팅을 작성한 B에게 push 발송

이 때 트랜잭션 처리가 되어 있어서 1~3 작업 모두가 성공해야 완료되고 하나라도 실패하면 DB에 저장되지 않고 실패 결과를 반환해. 결과는 http 상태코드와 json 형태의 body로 반환해. 이후는 프론트엔드에서 처리해. 컴포넌트에서는 이미 좋아요 관련 데이터와 화면에 보여주는 영역이 상태 관리 라이브러리를 통해 바인딩 되어 있어서 api 결과를 프론트엔드의 store에 저장하면 화면을 업데이트 해주는 작업을 별도로 하지 않아도 화면은 업데이트가 돼. 이 때, api 응답 결과가 성공인 경우에는 완료 레이어를, 실패인 경우에는 에러 발생 레이어를 보여주고 해당 기능은 종료되는 것이지. 이런식으로 비즈니스 로직을 이해했다면, 다음은 코드 레벨에서 이해한 흐름을 실제로 따라가 보는거야.

코드 레벨에서 흐름 이해하기

우리 팀은 누구나 코드 리뷰를 할 수 있어서 챕터 상관없이 모두가 모든 코드 저장소 접근 권한을 갖고 있어. 하지만 팀마다 정책이 다르니 만약 코드 저장소에 접근 권한이 없다면 동료에게 요청부터 해야겠지? 코드를 따라 가는 과정에서 당연히 개발 언어가 다르다 보니 쉽지 않을거야. 하지만 겁을 먹지 않아도 되는 이유는 구현할 정도로의 개발언어에 대한 이해도를 원하는게 아니라는 점이야. pseudo 코드를 읽는 것 처럼 흐름을 따라갈 수 있을 정도의 이해도야. 세세한 문법은 넘어가도록 하고 함수나 변수 네이밍이 잘 되어 있다면 이름만으로도 작업을 추측할 수 있으니 잘 따라가 보길 바래. 혼자 코드를 보는 작업이 부담스럽다면 처음에는 동료에게 코드 리뷰를 부탁해도 좋을 것 같아. 처음이 어렵지 몇 번 하다 보면 금새 읽고 흐름을 이해할 수 있을거야.

정리하자면, 프로덕트 팀에서 풀스택 엔지니어의 영향력은 대단해. 문제 해결력이 뛰어나기 때문에 아무래도 돋보이기 마련이다 보니 곁에 풀스택 엔지니어가 있으면 자연스레 풀스택에 관심이 생기고 그렇게 성장하게 될거야. 하지만 갑자기 기술 스택을 바꾼다는 것이 쉽지 않아. 그렇기 때문에 팀에서 다른 챕터 엔지니어들과 협업을 통해 다양한 기술 스택을 접하고 배우면서 성장하는 것이 중요한 포인트야. 그렇기 때문에 프로덕트 중심의 팀이 엔지니어의 성장에 꼭 필요하다고 생각해. 대부분의 테크리드나 CTO를 봐도 전문적인 기술 스택을 갖추고 사용할 수 있는 기술 스택을 갖춘 풀스택이 많아. 그렇기 때문에 그들이 엔지니어들과 프로덕트 팀을 리드하면서 문제를 빠르고 효율적으로 해결하는 역할을 할 수 있다는 것을 알았으면 좋겠어.

From. 앞으로 풀스택 엔지니어로 성장하길 바라는 Rock