모바일 앱 개발자에서 백엔드 개발자로 전환하며 배운 것

안녕하세요. Fromm 백엔드 개발자 김민석입니다.

저는 작년까지 안드로이드 앱 개발을 담당하다가, 올해 초 NestJS 기반 백엔드 개발자로 직무를 전환했습니다.

전환 초기에는 낯설고 어려운 부분이 많았지만, 적응해 나가는 과정에서 모바일 개발 경험이 백엔드 개발에도 충분히 활용될 수 있다는 점을 알게 되었습니다.

그래서 이 글에서는 모바일 개발자에서 백엔드 개발자로 전환하며 느낀 점들을 정리해봤습니다.

관점이 달라졌다

실제 업무를 시작하면서 가장 먼저 바뀐 건 무언가를 바라보는 관점이었습니다. 앱에서는 화면에서 일어나는 과정을 따라가며 기능을 만들었다면, 백엔드에서는 요청이 들어온 뒤 서버 내부에서 어떤 처리가 이루어지고 그게 어떻게 응답으로 연결되는지를 봐야 했습니다.

그러다 보니 시선이 자연스럽게 화면에서 서버 내부로 옮겨갔습니다. NestJS 코드 구조를 읽고, TypeORM 쿼리가 어떤 데이터를 거쳐 응답으로 이어지는지부터 이해해야 했으니까요.

또한, AWS 환경도 앱 개발과는 사뭇 다른 세계였는데요. 사용 중인 여러 서비스가 서로 연결되어 있다 보니, API가 어떤 경로로 실행되는지, 그리고 배포된 이후 문제가 발생했을 때 어디를 확인해야 하는지를 파악하는 일이 초반에는 꽤 복잡하게 느껴졌습니다.

사실 신경 써야 할 게 많기로는 모바일도 마찬가지였습니다. 같은 화면이라도 OS 버전이나 제조사에 따라 다르게 동작하진 않는지, 백그라운드와 포그라운드를 오갈 때 상태가 유지되는지, 네트워크가 끊겼다 돌아왔을 때는 어떻게 처리되는지까지 두루 살펴야 했으니까요. 다만 그 복잡함은 대체로 사용자의 기기와 앱 안에서 일어나는 일이었습니다.

반면 백엔드에서는 그 축이 옮겨갔습니다. 하나의 요청이 게이트웨이를 지나 어떤 서버로 도달하는지, 인증과 인가는 제대로 통과하는지, DB 쿼리와 트랜잭션이 의도대로 도는지, 외부 API나 큐를 거치며 지연이나 실패가 생기진 않는지, 그리고 문제가 생겼을 때 그 흔적이 어느 로그에 남는지까지 살펴야 했습니다. 그러다 보니 “지금 이 요청이 어디까지 와 있고, 어디서 어긋났는가”를 먼저 떠올리게 됐고, 코드 한 줄을 보기 전에 요청이 지나가는 전체 경로부터 머릿속에 그려보는 습관이 생겼습니다.

정리하면, 모바일에서는 기기와 화면을 둘러싼 변수들을, 백엔드에서는 요청과 응답을 잇는 서버 내부 흐름을 살피게 됐습니다. 신경 써야 할 것이 줄어든 게 아니라, 바라보는 대상이 통째로 옮겨간 것이죠. 그래서 같은 기능을 만들더라도 무엇을 먼저 들여다보느냐가 달라졌습니다.

코드를 쓰기 전에 흐름을 먼저 추적했다

새로운 기능을 맡을 때면 모바일이든 백엔드든 곧바로 구현부터 하지는 않았습니다.

예를 들어 모바일에서 로그인 화면을 수정할 때면, 먼저 화면 진입 흐름부터 살펴봤습니다. 어디서 화면이 열리는지, ViewModel이 어떤 상태를 관리하는지, API 호출은 어디서 일어나는지, 그리고 성공과 실패를 각각 어떻게 처리하는지를 차례대로 따라갔습니다.

백엔드로 전환한 뒤에도 이 습관은 그대로 필요했습니다. 화면의 흐름을 따라가던 시선은 자연스럽게 API의 경로를 따라가기 시작했습니다.

제가 맡았던 Auth 작업도 비슷했는데요. 기존 OTP 인증을 이메일 매직링크 방식으로 바꾸는 작업이었습니다.

기존 OTP 방식은 대략 이런 과정이었습니다.

사용자가 이메일 입력 → OTP 메일 발송 API 호출 → 사용자가 OTP 입력 → OTP 검증 API 호출 → 성공하면 회원가입 처리

이메일 매직링크로 바꾸면서 경로는 이렇게 달라졌습니다.

사용자가 이메일 입력 → 매직링크 발송 API 호출 → 사용자가 이메일 링크 클릭 → 토큰 검증 → 성공하면 회원가입 처리

인증 방식이 바뀐 만큼, 그 안에서 무엇이 실제로 바뀌고 무엇을 유지할 수 있는지를 먼저 살펴봐야 했습니다. 그래서 코드를 수정하기 전에 기존 흐름부터 따라가 본 것이죠.

먼저 어떤 API가 이미 존재하는지 Controller에서 확인했습니다. 각 API가 어떤 응답을 내려주는지, 호출하려면 어떤 query나 body가 필요한지를 함께 살펴봤습니다.

다음으로 Service에서 실제 비즈니스 로직을 파악했습니다. 어떤 조건에서 성공하고 어떤 조건에서 실패하는지, 그리고 실패 시 어떤 예외가 발생하며 그 판단에 필요한 데이터가 DB에서 오는지 외부 API에서 오는지까지 확인했습니다.

모바일에서 “사용자 입력 → 상태 변경 → 화면 이동”을 따라갔다면, 백엔드에서는 “요청 → Controller/Service → 응답”을 따라갔습니다. 코드를 한 줄 고치기 전에 기존 흐름부터 끝까지 짚어 보는 순서는, 화면이 API로 바뀐 뒤에도 그대로 이어졌습니다.

달라지는 지점과 유지되는 지점을 구분했다

백엔드로 전환한 초반에는 기존 서버 코드의 구조와 맥락을 먼저 익혀야 하는 입장이었습니다. 그래서 중요한 건 새로운 구조를 고민하는 것이 아니라, 이미 만들어진 흐름을 정확히 이해하고 그 안에서 이번 요구사항으로 인해 달라지는 지점이 어디인지 찾는 일이었습니다.

Auth 작업에서도 달라지는 지점과 유지되는 지점을 구분하는 과정이 먼저 필요했습니다.

OTP 방식에서 이메일 매직링크 방식으로 바뀌면서, 인증을 시작하고 검증하는 방식은 크게 달라졌습니다. OTP를 발송하고 사용자가 직접 코드를 입력하던 흐름이, 이메일 링크를 발송하고 링크에 포함된 토큰을 검증하는 흐름으로 바뀌었기 때문입니다.

하지만 모든 흐름이 바뀐 것은 아니었습니다.

인증이 성공한 이후 회원가입을 처리하는 흐름은 기존 로직을 그대로 활용할 수 있었습니다. 그래서 기존 코드에서 어느 지점까지는 그대로 이어지고, 어느 지점부터 매직링크 방식에 맞게 바뀌어야 하는지를 구분해서 봐야 했습니다.

이런 방식은 모바일 개발에서도 동일했습니다. 새 기능을 추가할 때 기존 상태 관리, 재사용 컴포넌트, API 호출 패턴을 먼저 확인하고, 변경이 필요한 부분만 골라냈으니까요. 백엔드에서도 Controller와 Service 층에서 똑같은 방식을 적용했습니다.

만약 이런 기준이 없으면 변경 범위가 쉽게 커집니다. 인증 방식만 바뀐 것처럼 보여도 성공 이후 처리까지 다시 구성하게 되고, 그 과정에서 실패 케이스를 놓치거나 불필요한 중복이 생길 수 있기 때문입니다.

그래서 백엔드 작업을 할 때는 늘 같은 질문을 스스로에게 던졌습니다.

• 이번 요구사항에서 실제로 달라지는 부분은 무엇인가?
• 기존 로직 중 그대로 둘 수 있는 부분은 어디인가?
• 비슷한 흐름이 이미 존재하는가?
• 내 변경 범위가 요구사항보다 넓어지진 않았는가?

사실 이 질문들은 백엔드에서 새로 만든 게 아닙니다. 모바일 시절 ‘변경 범위를 작게 가져가기’ 위해 던지던 질문을, 이번에는 화면 구조가 아니라 Controller와 Service 흐름을 향해 던지게 됐습니다.

성공 응답뿐 아니라 실패 응답까지 직접 확인했다

모바일 개발을 할 때도 구현만 끝났다고 해서 작업이 끝나는 것은 아니었습니다.

버튼을 눌렀을 때 정상 동작하는지, 로딩 상태는 자연스러운지, API 실패 시 화면이 깨지지 않는지, 빈 데이터나 예외 상황에서 문제가 없는지를 직접 하나하나 확인했습니다.

백엔드에서도 이 습관은 그대로 필요했는데요. 다만 점검 대상이 화면 동작에서 API 응답, 서버 로그, DB 상태로 바뀌었습니다.

그래서 API 작업을 한 뒤에는 보통 이런 순서로 확인하려고 합니다.

1. 로컬 또는 개발 환경에서 API를 직접 호출합니다.
2. 성공 케이스의 상태 코드를 확인합니다.
3. 응답 본문이 의도한 구조로 내려오는지 확인합니다.
4. 실패 케이스를 직접 호출합니다.
5. 에러 응답이 의도한 형태로 내려오는지 확인합니다.
6. 서버 로그를 확인합니다.
7. 필요한 경우 DB 값이 의도대로 변경되었는지 확인합니다.
8. 프론트엔드나 앱에서 실제로 호출했을 때도 문제가 없는지 확인합니다.

모바일 시절에도 API 로그는 확인했지만, 이제는 입장이 반대가 됐습니다. 예전에는 서버가 내려준 응답을 받아 쓰는 쪽이었다면, 지금은 내가 만든 API가 올바르게 응답하는지를 직접 검증하는 쪽이 됐습니다.

차이는 점검 방식에 있습니다. 예전에는 기기 화면에서 버튼을 누르고 UI 상태를 봤다면, 지금은 API 클라이언트로 요청을 보내고 상태 코드, 응답 본문, 서버 로그, DB 상태를 확인합니다.

특히 더 신경 쓰게 된 부분은 실패 응답이었습니다. 모바일에서는 서버가 내려준 실패 응답을 받아 처리하는 쪽이었지만, 백엔드에서는 그 실패 응답을 직접 만들어 내려주는 쪽이 되기 때문입니다. 그래서 성공뿐 아니라 실패 시 어떤 상태 코드와 형태로 응답하는지까지 함께 챙기게 됐습니다.

결국 기본기가 더 중요해졌다

모바일 개발자에서 백엔드 개발자로 전환하면서 느낀 건, 새로운 도구도 중요하지만 개발자로서의 기본기가 더 큰 자산이라는 점이었습니다. NestJS, TypeORM, AWS는 시간이 지나면 자연스럽게 익숙해집니다. 하지만 코드를 읽고 흐름을 추적하는 능력은 어떤 도메인에서든 통하는 기본기였습니다.

그래서 낯선 영역일수록 이런 기본기가 더 중요했습니다. 코드를 쓰기 전에 흐름을 읽고, 변경 범위를 미리 가늠하는 습관이 없었더라면 훨씬 더 헤맸을 것 같습니다.

결국 달라진 건 개발의 본질이 아니라 제가 서 있는 위치였습니다. 이전에는 API를 받아 화면을 만드는 쪽이었다면, 지금은 그 API가 어떻게 작동하는지를 다루는 쪽이 됐을 뿐입니다. 그렇지만 흐름을 이해하고 문제를 해결하는 방식만큼은 모바일에서 익힌 것을 그대로 적용할 수 있었습니다.

그 방식을 구체적으로 풀면 이 세 가지였습니다.

1. 기존 흐름을 먼저 읽기
2. 변경 범위를 명확히 구분하기
3. 성공과 실패 케이스 모두 검증하기

화면을 다루든 API를 다루든 변하지 않는 습관이었고, 덕분에 직무 전환 초반의 불안감도 크게 줄일 수 있었습니다.

마무리하며

앞서 말한 기본기를 빠르게 끌어올리는 데는 Claude Code와 Codex 같은 AI 도구의 도움도 컸습니다. 다만 중요한 건 도구 자체가 아니라, 그것을 어떻게 사용했느냐였습니다.

백엔드 개념이 부족했을 때는 AI에게 코드를 먼저 작성하게 한 뒤, 그 코드를 두고 “왜 이렇게 했을까?”, “더 나은 방법은 없을까?”를 함께 물었습니다. PRD나 기획서도 AI와 함께 살펴보며 구현과 문서 사이에 어긋난 부분은 없는지, 누락된 요구사항은 없는지 확인했습니다.

이렇게 하니 단순히 결과물만 얻는 데 그치지 않았습니다. 설계 의도와 비즈니스 로직까지 함께 익힐 수 있었거든요. 만약 결과물만 가져왔다면 비슷한 상황에서 어떻게 대응해야 할지 막막했을 것 같습니다. 계속 질문을 던지며 학습하다 보니, 백엔드 개념이 조금씩 몸에 붙는 느낌이었습니다.

읽어주셔서 감사합니다.