우리 팀이 담당하는 서비스

Chapter 6. 회사 시스템 파악

"우리 회사 서비스가 뭐가 있지?"

GitHub 권한도 받았다. 개발 서버 계정도 생겼다. 노트북에는 회사 코드가 클론되어 있다. 모든 준비가 끝난 것 같다.

그런데 팀장님이 슬랙으로 메시지를 보낸다.

"우리 서비스 한번 써보셨어요? 회원가입하고 주요 기능들 둘러보세요. 내일 오전에 서비스 소개 미팅 할게요."

'우리 서비스를 써보라고? 그게... 뭐였더라?'

면접 때 회사 소개는 들었다. "저희는 OO 플랫폼을 운영합니다" 이런 식으로. 그런데 막상 앱을 깔아야 하는 건지, 웹사이트를 들어가야 하는 건지, 어디서부터 시작해야 할지 모르겠다.

'코드는 있는데... 이 코드가 어떤 화면을 만드는지, 사용자는 뭘 하는지, 전혀 감이 안 와.'

슬랙을 보니 다른 팀원들이 "결제 화면 개선했습니다", "검색 속도 20% 향상" 같은 얘기를 하고 있다. 다들 서비스를 잘 아는 것 같다.

'나만... 모르는 건가?'

걱정하지 마라. 지금부터 우리 팀이 담당하는 서비스를 파악하는 방법을 차근차근 알아보자.

왜 서비스를 먼저 써봐야 할까?

코드를 먼저 보면 안 될까? 함수 이름, 변수 이름, 로직을 읽으면 이해가 되지 않을까?

아니다. 코드만 보면 숲을 보지 못하고 나무만 본다. 서비스를 직접 써봐야 하는 이유를 알아보자

1. 사용자 관점을 이해하기 위해

개발자는 코드를 짜지만, 사용자는 화면을 본다. 내가 짠 코드가 사용자에게 어떻게 보이는지, 어떤 경험을 주는지 알아야 좋은 코드를 짤 수 있다.

2. 비즈니스 로직을 파악하기 위해

"왜 이 버튼을 눌렀을 때 이런 동작을 하지?" 서비스를 써보면 이해된다. 회원가입 플로우, 결제 과정, 알림 시스템... 코드만 보면 복잡해 보이지만, 실제로 써보면 "아, 이래서 이렇게 짠 거구나" 깨닫게 된다.

3. 버그를 발견하기 위해

직접 써보다가 "어? 이거 이상한데?" 싶은 부분이 있을 수 있다. 그게 진짜 버그일 수도 있고, 개선할 점일 수도 있다. 신입이 발견한 문제가 시니어들이 놓친 것일 수도 있다. 새로운 시각이 중요하다.

4. 팀 회의에서 대화를 따라가기 위해

"검색 결과 화면에서 필터 기능 추가하면 좋을 것 같아요" 이런 대화가 나올 때, 서비스를 써본 적이 있어야 무슨 말인지 이해할 수 있다. 안 써봤으면 "검색 결과 화면이 어디였더라?" 하고 길을 잃는다.

5. 개발 동기부여를 위해

내가 짠 코드가 실제 사용자에게 어떤 가치를 주는지 알면, 일이 더 재미있어진다. "내가 고친 버그 덕분에 사용자들이 편해졌겠지" 이런 생각이 들면 뿌듯하다.

실전팁

서비스를 써보는 건 업무 시간 중에 해도 된다. "공부"가 아니라 "업무"다. 업무시간에 서비스를 마음껏 써보고 코드부터 보는 것도 좋은 방법이다.

에피소드

입사 첫 주, 팀장님이 "우리 앱 한번 써봐" 하셨는데, "네 알겠습니다" 하고 넘겼다. 첫 업무를 받았다. "로그인 화면에서 비밀번호 찾기 버튼 위치 변경" 간단했다. LoginScreen 파일을 찾아서 버튼 위치를 바꿨다. PR을 올렸다.

시니어가 코멘트를 남겼다.
"근데 이 화면이 어디서 나오는지 아세요? 회원가입 후에도 보이고, 비밀번호 변경 화면에도 나와요. 둘 다 확인하셨나요?"당황했다. 앱을 켜보니 비밀번호 변경 화면에서도 같은 컴포넌트를 썼다. 그 화면에서는 버튼 위치가 이상했다.

다시 코드를 고쳐 화면별로 다르게 표시되도록 수정했다. 시니어 개발자는 웃으면서 말했다. "다음부턴 먼저 서비스를 써보고 작업하면 좋을 것 같아요" 그날 이후로 항상 서비스를 먼저 써본다. 화면을 클릭해보고, 플로우를 따라가본 다음 코드를 본다. 훨씬 빠르고 실수도 줄어든다.

서비스 소개 자료 찾기

우리 팀이 담당하는 서비스가 뭔지 알아보자. 어디서 찾을 수 있을까?

1. 사내 위키 (Confluence, Notion 등)

키워드 검색:

"서비스 소개"

"제품 개요"

"온보딩"

"신입 가이드"

대부분의 회사는 신입을 위한 서비스 소개 문서가 있다. 여기에는 다음과 같은 내용이 있다:

서비스 목적: 우리 서비스가 해결하려는 문제가 무엇인가?

주요 기능: 핵심 기능 3~5가지

사용자 타겟: 누가 우리 서비스를 쓰는가? (연령대, 직업, 관심사 등)

경쟁사: 비슷한 서비스는 무엇이 있는가?

우리의 강점: 다른 서비스와 비교해 우리만의 장점

2. 팀 슬랙 채널의 고정 메시지

팀 슬랙 채널 상단에 고정(pin)된 메시지를 확인해보자. "신입 필독", "서비스 링크 모음" 같은 제목으로 고정되어 있을 수 있다.

3. 이메일 아카이브

입사 첫날 받은 이메일을 다시 확인해보자. "신입 개발자 OOO님 환영합니다" 같은 제목의 메일에 서비스 링크나 소개 자료가 첨부되어 있을 수 있다.

4. 팀장님이나 멘토에게 직접 물어보기

찾아도 없다면 그냥 물어보자.

좋은 질문 예시:
"팀장님, 우리 팀이 담당하는 서비스 소개 자료가 있을까요? 먼저 서비스를 이해하고 싶어서요."

피해야 할 질문:
"우리 팀이 뭐 하는 팀이에요?" (면접 때 들었을 텐데 이렇게 물으면 준비 안 한 것처럼 보일 수 있다)

실전 팁

서비스 소개 자료를 못 찾았다면, 이건 오히려 기회다. 나중에 내가 정리해서 위키에 올리면 된다. "신입이 처음 봤을 때 알았으면 좋았을 것들"을 정리하면 다음 신입에게 큰 도움이 된다.

실제로 서비스 가입하고 사용해보기

이제 직접 써볼 차례다. 앱을 깔거나, 웹사이트에 접속해서 회원가입부터 시작하자.

Step 1: 서비스 다운로드/접속

모바일 앱이라면:

앱스토어(iOS) 또는 플레이스토어(Android)에서 검색

회사명 또는 서비스명으로 검색

다운로드 및 설치

웹 서비스라면:

브라우저에서 주소 입력

북마크 저장해두기

모바일 웹도 함께 확인

실전 팁:

개인 계정과 테스트 계정을 분리하자. 개인 이메일로 하나 가입하고, 회사 이메일로도 하나 가입해서 테스트용으로 쓰면 편하다.

Step 2: 회원가입 과정 꼼꼼히 살펴보기

회원가입은 서비스의 첫인상이다. 신입이 가장 먼저 개선할 가능성이 높은 부분이기도 하다.

체크할 것들:

회원가입 단계가 몇 개인가? (간단한가? 복잡한가?)

필수 입력 항목이 무엇인가? (이메일, 전화번호, 이름 등)

소셜 로그인이 있는가? (구글, 카카오, 네이버 등)

약관 동의는 어떻게 처리하는가?

이메일 인증이 있는가?

에러 메시지가 친절한가?

메모하면 좋은 것들:

"여기 UI가 조금 불편한데?" -> 나중에 개선 제안 가능

"왜 이 정보를 받을까?" -> 비즈니스 로직 이해

"이 단계에서 이탈하는 사용자가 많을 것 같은데?" -? 데이터 분석 시 확인

Step 3: 주요 기능 하나하나 사용해보기

마치 진짜 사용자처럼 서비스를 써보자. 각 기능을 클릭하고, 입력하고, 제출해보자.

체크리스트:

기본 기능

로그인/로그아웃

비밀번호 찾기/변경

프로필 수정

알림 설정

핵심 기능 (서비스마다 다름)

쇼핑몰이라면: 상품 검색, 장바구니, 결제

커뮤니티라면: 글쓰기, 댓글, 좋아요

예약 서비스라면: 검색, 예약, 취소

금융 서비스라면: 계좌 조회, 이체, 내역 확인

숨겨진 기능

설정 메뉴 구석구석

푸터의 작은 링크들

고객센터, FAQ

이용약관, 개인정보처리방침

Step 4: 의도적으로 실수해보기

정상적인 사용만 하지 말고, 사용자가 할 수 있는 실수를 일부러 해보자. 이게 QA의 시작이다.

시도해볼 것들:

빈 칸으로 폼 제출하기

잘못된 형식 입력하기 (이메일에 @없이 입력, 전화번호에 문자 입력)

뒤로가기 버튼 여러 번 누르기

새로고침 버튼 연타하기

네트워크 끊고 사용해보기 (비행기 모드)

아주 긴 텍스트 입력하기

발견할 수 있는 것들:

에러 메시지가 나오는가?

앱이 멈추거나 크래시가 나는가?

사용자에게 안내가 충분한가?

데이터가 제대로 저장되는가?

실전 팁

버그를 발견했다면 바로 티켓을 만들지 말고, 일단 메모해두자. 이미 알려진 버그일 수도 있고, 의도된 동작일 수도 있다. 나중에 팀 미팅에서 물어보자.

에피소드

지인 개발자의 신입 시절 이야기다. 입사 2주차, 친구는 서비스를 열심히 써보다가 이상한 걸 발견했다. 프로필 사진을 업로드하면 사진이 90도 돌아가 있었다. 다시 해봐도 똑같았다.

'버그인가? 근데 말하면 창피한 거 아닐까...'

고민하다가 용기를 내서 슬랙에 조심스럽게 물어봤다고 한다. "혹시 프로필 사진이 돌아가는 건 알고 계신 이슈인가요?"

온라인 평가 살펴보기

우리 서비스에 대해 사용자들이 뭐라고 말하는지 확인해보자.

1. 앱스토어/플레이스토어 리뷰

확인할 것:

평점 (별점 몇 개?)

최근 리뷰 (최근 한 달)

별점 1개 리뷰 (가장 불만이 많은 부분)

별점 5개 리뷰 (사용자들이 좋아하는 부분)

반복되는 키워드 ("느려요", "불편해요", "좋아요" 등)

메모할 것:

"앱이 자주 멈춰요" → 성능 이슈

"로그인이 안 돼요" → 인증 관련 버그

"디자인이 예뻐요" → UI/UX 강점

"고객센터 응대가 좋아요" → 비개발 팀 강점

2. SNS (트위터, 페이스북, 인스타그램)

검색 키워드:

회사명

서비스명

#회사명, #서비스명

발견할 수 있는 것:

실시간 불만사항 ("지금 OO 서비스 접속 안 되는데 나만 그래?")

사용자들의 창의적인 활용법

경쟁사와의 비교 ("OO는 이런 기능 있는데 우리 서비스는 없네")

3. 온라인 커뮤니티 (레딧, 디시인사이드, 네이버 카페 등)

검색해볼 곳:

관련 주제 커뮤니티

"OO 서비스 후기" 같은 검색어

발견할 수 있는 것:

심층적인 사용 후기

버그 리포트 (아직 우리가 모르는)

기능 요청 ("이런 기능 있으면 좋겠어요")

4. 경쟁사 서비스 리뷰

우리 서비스만 보지 말고, 경쟁사 서비스의 리뷰도 확인하자.

비교할 것:

경쟁사는 어떤 기능이 있는가?

사용자들이 경쟁사의 어떤 점을 좋아하는가?

경쟁사의 어떤 점을 싫어하는가?

우리가 더 잘하는 부분은 무엇인가?

이제 서비스도 알아보았다.

앱을 켰다. 회원가입 화면이 나온다. 이제 이 화면이 어떤 코드로 만들어졌는지 대충 감이 온다.

버튼을 눌렀다. 다음 화면으로 넘어간다. '이 부분은 아마 navigate 함수를 쓸 거야.'

입력창에 텍스트를 친다. '이건 state 관리하고, validation 체크하겠지.'

로그인을 했다. 메인 화면이 나온다. 여러 개의 카드가 보인다. '이건 API에서 데이터 받아와서 map으로 렌더링하는 거겠지.'

이제 코드를 열어도 무섭지 않다. 화면을 봤으니까. 사용자 경험을 이해했으니까.

내일 팀장님과 서비스 소개 미팅이 있다. 이제 질문할 준비가 됐다.

"이 기능은 왜 이렇게 만들었나요?"
"사용자들이 이 부분에서 많이 이탈하지 않나요?"
"이 UI 개선하면 전환율이 올라갈 것 같은데, 시도해본 적 있나요?"

노트북을 덮는다. 오늘은 여기까지.

회사 서비스도 이제 눈에 들어왔다.