이전 회사의 경험을 완전히 잊기 전에 회고록이라도 써야 할 필요를 느꼈습니다.
그래서 저와 팀원들이 어떤 식으로 일을 했는지 한번 적어 보려고 합니다.
개인적인 경험이므로, 모든 회사가 이와 같지는 않으니 참고만 해 주세요.
버전 기준
저희 개발팀 내부는 서버/프론트(웹)/모바일(네이티브)로 나뉘어 있었기에 각자 수정 사항이 생길 때마다 버전도 달라지기 마련이었습니다.
예를 들면,
화면 디자인 개선의 경우
1. 서버는 코드 변경이 없음
2. 네이티브 및 웹에서 공통적으로 쓰이는 UI가 바뀜
2-1. 모바일은 코드가 수정될 때마다 심사를 거쳐야 하므로 버전이 올라감
2-2. 프론트 단의 코드가 수정되어야 하므로 버전이 올라감
신규 서비스가 추가될 경우
1. 서버는 새로운 api를 만들어야 하므로 버전이 올라감
2. 프론트 단은 새로운 화면을 만들어야 하므로 버전이 올라감
3. 네이티브 단에서는 추가될 로직이 없으므로 코드 변경이 없음
위의 두 케이스 외에도 서버/프론트/네이티브의 업데이트가 달라지는 일은 굉장히 많습니다. 결론적으로, 저희 팀의 버전은 Major / minor / 주간 업데이트 이렇게 3개로 나뉘었는데요.
1. Major 업데이트
v1.2.3 이라고 한다면 첫글자 v1에 해당하는 부분입니다.
프로젝트 단위가 6개월 / 1년정도의 대규모 업데이트. 버전의 맨 앞자리가 변경됨. 저희 회사의 경우 플랫폼의 리뉴얼 단계에 적용되었습니다.그래서 리뉴얼이 끝난 시점에서 앱의 버전은 4.0.0에서 시작되었죠.
2. Minor 업데이트
v1.2.3 이라고 한다면 두번째 n.2에 해당하는 부분입니다.
보통 2주 / 1개월 정도의 작업 기간이 걸리는 업데이트였는데요, 리뉴얼 후 얼마동안은 1달에 1번씩 새로운 서비스를 추가하여 각 파트별로 동일하게 중간 자리 숫자가 올라갔습니다. 이후에는 업데이트 되어야 할 건들이 더욱 세부적이고, 건수가 많아져 서버/프론트/모바일 별로 완전히 분리가 되었죠.
3. 주간 업데이트
v1.2.3 이라고 한다면 세번째 n.n.3에 해당하는 부분입니다.
주간 업데이트는 매주 화요일마다 이루어졌고, 운영팀에서 빠르게 수정하기를 원하는 간단한 작업이나 세세한 오류 같은 것들을 수정할 때 주간 업데이트를 이용했습니다.그렇기 때문에 가장 자주 바뀌는 버전이었고요.
모바일은 한번 코드를 수정할 때마다 앱 심사를 해야 하고 심사 기간도 2-4일이 걸리기 때문에,웬만하면 기획이나 디자인 단계에서 네이티브 코드를 건드리지 않는 쪽으로 변경이 이루어졌습니다.
업데이트 과정
이러한 업데이트는 회사 내부 기획이냐, 아니면 지자체의 요구가 있었냐에 따라서 과정이 조금씩 달라졌습니다.
1. 회사 내부 기획
보통 앱 내에 새로운 서비스를 출시하거나, 사용자의 요구에 따라 UI/UX를 개선하거나, 기존에 사용하던 로직을 변경하거나...등의 내용들은 전부 회사 내부 기획이라고 볼 수 있습니다. 기획자와 디자이너 분들이 가장 공을 들이기도 하죠. 이러한 내부 기획이 만들어지는 과정은 아래와 같습니다.
- 운영팀 혹은 경영진에서 업데이트 희망일자와 함께 기획팀에 요청
- 기획자는 요구사항에 맞추어 기획안 프로토타입 작성
- 기획자,디자이너,개발팀이 모여 기획안 프로토타입에 대한 리뷰를 진행 (이 과정에서 대략적인 작업일정과 기획 피드백이 이루어집니다.)
- 기획 수정과 함께 디자인 작업 시작, 서버단에서는 api 설계 시작
- 디자인 작업이 완료된 후 본격적인 개발 작업 진행
- 개발단에서 작업이 완료되면 약 1주간의 QA(테스트)기간을 거침
- QA 기간 중 큰 수정사항이 없다면, 경영진에서 요청한 날짜에 맞추어 배포
2. 지자체 요구 기획
저희 회사는 B2C / G2C를 동시에 운영하고 있었기 때문에 지자체와 사업을 제휴하는 인력이 따로 있었어요. 그리고 지자체와 계약을 유지하려면 해당 지자체에서 요구하는 조건을 반드시 수행해야 했기 때문에, 비즈니스 로직이 더 까다로워지기도 합니다. 과정은 대략 이렇습니다.
- 사업 제휴 마케터가 지자체와 협의 후, 지자체에서 요구하는 기능 사항을 정리
- 계약일(배포일) 확정
- 기능 사항 리스트와 배포일을 개발팀에 전달
- 개발 작업 진행 (기획 및 디자인이 필요한 경우, 기획자와 디자이너가 붙어 추가 기획과 디자인 시안 작성)
- 개발단에서 작업이 완료되면 1주 미만의 QA(테스트)기간을 거침
- QA 기간 중 큰 수정사항이 없다면 배포일에 맞추어 배포
이외에도 외부 기업과의 콜라보레이션 이벤트,국가 지원 사업 등의 여러 프로젝트가 있지만 개발 프로세스는 위와 비슷합니다.그리고 이러한 기획들은 최소 1개, 최대 4개까지 묶여 하나의 minor 업데이트 내역에 포함됐어요.
사실 가장 이상적인 것은 기획/디자인/개발팀에서 산정한 일정을 취합하고 조정하여 배포 일정을 정하는 것이지만, 실무자 분들이라면 이상적인 과정은 실현되지 않는다는 걸 잘 아실겁니다.
경영진의 입장에선 작업 규모와 상관 없이 "배포가 언제 되는지?"가 제일 중요하기 때문에 대부분의 회사에선 배포일부터 정해진 후 기획,디자인,개발이 동시에 들어가죠.
이것이 흔히 말하는 애자일 모델입니다.여러분이 신입 개발자라면 단계적으로 이루어지는 폭포수 프로세스에 너무 집착하지 않는 걸 추천합니다.
팀원과의 소통
위에서 애자일이란 말이 나온 김에 애자일과 거의 한 쌍으로 취급되는 또다른 단어가 있죠, 바로 스크럼입니다. 저희 팀 역시 스크럼을 상당히 중요하게 여겼으므로 일주일에 한번,매일 아침마다 한번씩 가벼운 회의가 이루어졌어요.
데일리 스크럼(일간 회의)
모든 팀원들이 출근한 시각인 10시~11시즈음에 진행된 데일리 미팅입니다.CTO(개발팀 리더)가 회의를 주관하였고 어제 하루동안 생겨난 이슈가 없는지, 현재 진행중인 작업에 어려움은 없는지 등의 소소한 일을 보고하는 회의였어요.
저희 팀은 팀원끼리 사이가 좋고 소통이 잘 되는 편이었기에 그동안 쌓인 불만 같은 것도 서슴없이 데일리 스크럼에서 이야기해도 큰 문제는 없었습니다.예를 들면 이런 식이었네요.
프론트 리드 팀원:
서버분들한테 요청할 게 있어요. api 독스를 작성할때,리스폰스로 오는 데이터 타입이랑 네이밍까지 미리 써주면 안되나요? 그러면 api를 연결할때 시간을 단축할 수 있거든요.서버 리드 팀원:
다른 분들한테도 당부하는 편인데 잘 안되고 있나보네요. 다들 독스 전달주기 전에 한번만 더 확인해주세요.AOS 담당 팀원:
다음주에 배포될 업데이트 버전 말인데, 모바일 심사가 늦어져서 배포 일정을 1주 더 늦춰야 할 것 같아요.
이런 사소한 사항 하나하나를 공유하기만 해도, 작업이 어떻게 진행되는지 각자 파악이 가능하죠. 물론 이것보다 더 사소하고 사적인 이야기는 팀원간의 슬랙에서 조율을 합니다. 그래서 슬랙이나 회의가 활발할수록, 팀원간 단합과 소통이 잘 된다고 느꼈어요.
별 내용도 없는 데일리 미팅이 무슨 쓸모가 있냐?라며 비효율적이라는 의견도 있겠지만 큰 내용이 없더라도 강제적으로 팀원들을 한데 모아 의견을 낼 수 있는 자리였다는 점에서 저는 긍정적인 영향이 있다고 생각합니다.
주간 회의
매주 월요일마다 했던 주간 회의입니다. 한 주동안 내가 진행한 작업이 어떻게 되고 있는지,추후 업데이트에 관련해 전달 사항이 있다던지..물론 이곳에서도 사소한 이야기를 합니다만 연차 계획같이 전반적으로 팀원들에게 중요하게 공지될 사안들이 주간 회의에서 이루어졌어요. '데일리 스크럼의 확장판'정도로 생각됩니다.
그리고 그만큼 팀원들이 오래 고민한 개선 사항이나 불만들이 나올 수 있었던 회의였습니다. 저는 주간 회의때 주기적인 회고 미팅을 하자고 건의했는데요, 초반에는 각 실무진끼리 회고를 진행하며 개선점을 찾아갔으나 점차 일정이 바빠져 회고 미팅까지도 할 수 없는 상황이 되어버려 상당히 아쉬웠습니다.
다른 팀원과의 소통
개발을 하려면 아무래도 기획자와 디자이너와 이야기를 하기 마련이죠. 저는 특히나 프론트엔드 개발이었기 때문에, 디자이너와 소통한 시간이 굉장히 많았습니다.
회사 내에서는 기획자와 디자이너가 피그마를 이용했기에 팀원이라면 피그마 시안에 코멘트를 달 수 있었죠. 가끔 경영진 분들이 피그마에 접속해 살펴보실 때도 있었는데...디자이너와 기획자 이외의 사람들이 컴포넌트를 만지지 못하도록 잠가두는게 굉장히 중요합니다. 실제로 경영진 분이 시안을 잘못 만졌다가 사용된 모든 폰트가 깨져 오류가 났던 적이 있었어요.
어쨌든 타 팀원과의 회의는 앞서 기술한 기획 리뷰 회의만 잡고, 보통은 슬랙/피그마 코멘트를 통해서 피드백을 주고받습니다. 여기서도 개발자 분들에게 한가지 당부하고 싶은 것이 있는데..
이건 왜 이렇게 했어요?
제발 이런식으로 말하지 마세요!불화의 씨앗이 됩니다.
물어보는 사람 입장에서는 정말 작업자의 의도가 궁금해서겠지만, 듣기에 따라서는 '내가 너보다 보는 눈이 있다'라는 것처럼 느껴지는 화법이에요.
오히려 신입보다 경력이 있는 분께서 저런 화법을 구사하는 경우를 종종 보았는데, 적어도 같은 실무진끼리는 서로의 작업물을 존중하는 태도가 필요하다고 생각됩니다. 조금만 둥글게 말해도 악감정은 안 쌓이거든요.
본인이 보기에 더 나은 대안이 있는 경우:
이 컴포넌트/로직을 자세히 봤는데 이러한 문제가 생길 것 같아요. 혹시 이런 방법을 적용하는건 어떻게 생각하세요?
단순히 작업자의 의도가 궁금한 경우:
이 컴포넌트/로직이 잘 이해가 되지 않는데, 어떤 식으로 굴러가는지, 혹은 이렇게 만들면 어떤 점이 좋은지 설명해주실 수 있으세요?
"내가 여기에 대해 잘 모르는데.."<<를 강조하는 것만으로도 상대를 깔본다는 느낌은 확연히 줄어듭니다.
업데이트 노트 정리
매주/매월마다 업데이트가 있던 프론트 팀은 버전별로 어떤 사항이 업데이트되었는지 정리해두지 않아서 '이거 언제 적용됐어요?'라는 질문에 굉장히 취약했었어요. 그러던 도중 서버 개발자분께서 '서버쪽은 버전이 바뀔 때마다 변경 사항을 노션에 적어둔다'는 말을 듣고 프론트도 동일하게 변경사항을 정리해야겠다고 생각했습니다.
그래서 보통 업데이트 일정이 나오면 버전명, 변경될 플랫폼,배포일,관련 지라 링크, 작업자,업데이트 타입을 적어두었습니다.
| 버전 | 플랫폼 | 배포일 | 지라 링크 | 작업자 | 업데이트 타입 |
|---|---|---|---|---|---|
| 4.12.4 | 클라이언트 앱,관리자 페이지 | xxxx.xx.xx | ISSUE-3097 | 홍길동 | minor |
| 4.12.3 | 클라이언트 앱 | xxxx.xx.xx | HOTFIX-9421 | john doe | hotfix |
그리고 세부 페이지에서는 PR이 올라온 깃허브 링크를 연결해두는 식으로, 언제 어떤 이슈를 해결했고 어떤 코드가 변경되었는지 히스토리를 저장해둘 수 있었어요. 덕분에 디자이너가 '이 컴포넌트가 언제부터 이렇게 바뀌었죠?'라는 질문에는 당당하게 대답할 수 있는 프론트 팀이 되었답니다.
애자일 방식으로 일을 하려면 빨리 개발되는 만큼,업데이트 내역을 정리하는 것이 중요하다고 느꼈습니다.
실무를 하며 아쉬웠던 것들
사실 취업 전 개발을 배우면서 벨로그에 포스팅을 하는 것이 소소한 낙이었는데요,정작 실무에 투입되고 나니 내가 배우고 느낀 것들을 정리하는 것조차 사치일 정도로 일상에 여유가 없어졌다는 것이 체감되었습니다.그래서 프로젝트가 끝나고 개인적인 회고나 새로 알게 된 것들에 대해서 쓰지 못했던 것들이 참 아쉽습니다.
실무에서도 작업한 코드나 이슈들을 정리해주는 편이 나중을 위해서라도 좋습니다.그래서 저는 간단한 함수라도 주석을 추가하고,매개 변수의 네이밍을 s,i같이 한 글자 대신 word,index같이 한 단어로 표현해 가독성을 높이는 버릇을 들였어요.어쨌든 코드는 여러 사람이 보는 것이니까요.(정말 드문 경우지만 서버쪽이 프론트 코드를 보게 될 일도 있었습니다.)
실무를 하며 깨달은 것들
저희 팀은 희한하게 밸런스가 좋았습니다. 다른 팀원은 처음 보는 기능을 개발하고 새로운 라이브러리를 사용하는 것에 두려움이 없어 신규기능을 빠르게 만들 수 있었고, 반대로 저는 처음 접하는 것에 안정성을 여러번 검증하는 편이다 보니 신규 개발보다는 기존에 있던 코드에 피해를 주지 않으면서 로직을 변경하는 작업을 담당하는 쪽이었어요.
그래서 제가 어떤 타입인지, 어떤 것이 약점인지 명확하게 알 수 있었고 새로운 라이브러리를 사용하는 것에 너무 겁을 먹지 않기로 했습니다.이후에 프로젝트를 나눌 때 일정이 촉박하지 않은 것에 한해 신규 개발 프로젝트를 먼저 가져가보기도 했어요.
맺음말
간단한 회고록을 쓰려 했는데 어쩌다보니 글이 또 길어졌습니다. 그만큼 쓰고 싶은게 많았네요.사실 저는 제가 어떤 결과를 냈는지보다, 어떤 방식으로 일을 했는지에 초점을 두는 편입니다. 솔직히 저도 대기업을 다녀본 적이 없어서 "이게 옳다!"라고 말할 수 없기 때문에 최대한 객관적으로 나는 이렇게 일했다는 걸 보여주고 싶었어요.
그리고 여러 회사를 다녀보며 확실히 느낀건.. 기획/디자인/개발 작업인원이 분배되기만 해도 훨씬 완성도 있는 결과물을 낼 수 있다는 것입니다. 현업에 종사하시는 모든 기획자,디자이너, 개발자들을 응원하며 회고는 이것으로 마치겠습니다.
