나는 어떤 개발자이고 싶은가

주니어 개발자로 일하면서 더 좋은 개발자가 되기 위해 어떻게 해야할지에 대한 고민들을 당연히 하게 됩니다. 스타트업에서 일한다면 스스로 어떻게 하느냐에 따라 본인이 얻을 수 있는 것 또한 많이 달라지게 되는 것 같아요. 그만큼 주니어 포지션임에도 회사에 기여할 수 있는 범위도 넓고, 할 수 있는 것들도 많기 때문입니다.

저는 이런 환경에서 일했는데요,

시리즈 B 단계의 초기 스타트업
주니어 개발자들로 이루어진 팀
역시나 주니어 개발자인 나

대부분의 스타트업도 어느정도 비슷한 상황에서 일하게 될 것이라 생각합니다.
시니어 프론트엔드 개발자가 없는 조직도 많고, 바쁘고 변화무쌍한 환경에서 빠르게 적응하고 스스로 할 일을 찾아 해나가야 하는 게 스타트업이니까요.
중요한 건 '나는 어떻게 일할 것인가?'이겠죠.

좋은 개발자가 되려면? (feat. 개발 실력 빼고도)

좋은 개발자가 되기 위해 나는 어떻게 일할 것인가, 라는 질문에는 여러 방향으로 그 답을 고민해볼 수 있습니다. 당연히 기술적으로 뛰어난 실력을 갖춘 개발자가 되는 것이 기본이겠죠. 그렇지만 이 글에서는 이를 제외하고, 팀에 속한 구성원으로서 어떻게 좋은 프로덕트를 만들고 함께 잘 일하기 위해 노력했는지에 대한 고민과 시도의 과정을 정리해보려고 합니다.

크게 3가지의 꼭지가 있을 것 같아요.

• 성장하기 위한 노력: 성장하기 위해 노력하자. 그럴 수 있는 환경이 부족하다고 느낀다면 스스로 만들어나가기 위해 할 수 있는 것들을 시도해보자
• 사용자 관점에서 생각하고 프로덕트 개선하기: 개발자는 프로덕트를 만드는 사람이고, 코딩은 문제해결의 수단이다. 주어진 요구사항을 단순히 구현하는 것을 끝이라 생각하지 말자. 프로덕트가 사용자에게 잘 전달되기 위한 방향에서 최선의 기술적인 방법을 고민하고, 할 수 있는 것을 찾자
• 협업: 생각보다 업무의 비효율은 소통과 협업에서 발생한다. 팀 차원으로 시야를 넓혀 함께 잘 일하기 위해 노력하자

1. 함께 잘 일해요! 꾸준히 회고하고 개선하기

"우리, 회고합시다!!"

"우리 회고를 해봐요!!"

더 멀리 가려면, 우리가 호흡을 맞추는 게 먼저야

회사 차원에서도 조직문화 등에 많은 신경을 써주었지만, 스타트업인 만큼 빠른 속도와 바뀌는 방향성에 맞춰 여러 인원이 움직이다보면 어쩔 수 없이 약속했던 것들이 지켜지지 않는 부분도 생기고, 소통에 오류가 생기거나 비효율적인 부분도 많이 발생하게 되었습니다. 업무 프로세스 측면에서 손발이 맞지 않는 부분들도 있었고, 실무를 따라가기에 벅차 기술적인 고민을 함께 하기 어려운 부분들이 있었죠.

개발자로서 함께 성장할 수 있는 좋은 환경을 스스로 만들고 함께 더 많은 좋은 고민을 해나가고 싶었지만, 이를 위해서는 주니어들끼리 시행착오와 많은 시도를 거칠 만한 시간과 리소스가 필요했습니다.

그 리소스를 확보하려면 우선 현재 하고 있는 업무로부터 발생하는 비효율을 최대한 줄어야 한다고 생각했습니다. 그래야 그 확보한 시간을 다른 곳에 투자할 수 있고, 이를 통해 업무의 효율성을 올릴 수 있을테니까요.

우선, 함께 일하는 과정에서 시간과 체력이 낭비되는 원인을 생각해보고 하나씩 개선점을 생각해 정리한 뒤 팀 차원에서 함께 논의 후 실행에 옮겨보았습니다.

⚡️ 파트/팀 차원에서의 회고 진행하기

먼저 했던 것은 팀원들과의 대화였습니다.
프론트엔드 팀원들에게, 그다음은 PM, 백엔드 팀원들에게 문제의식을 느끼는 지점을 전달하고 의견을 들어봤습니다. 다행히 모두 공감하고 있는 부분들이었어요. 다들 적극적인 자세로 개선하고자 하는 반응을 보여주셨습니다.

뭔가 개선이 되었으면 좋겠고 협업이 잘 안된다는 생각이 들어서 답답한 지점들이 있었는데, 정확히 어떻게 해야할지는 잘 모르겠었어요. 그런 원인들이 있을 수 있겠네요!
그럼 우리가 뭘 어떻게 하면 좋을까요?

이 다음으로 바로 회고 템플릿을 만들고, 회고 미팅 일정을 잡은 후 각자의 의견을 받았습니다. 회고 전에 미리 의견과 개선안을 굵직한 카테고리로 취합하고 준비했어요.

파트 협업 회고

이런 부분에 대해 이야기를 나누었어요

플랫폼 파트에는 PM과 프론트엔드, 백엔드, 디자이너와 기획자가 속해있고, 업무 프로세스에 대한 이야기를 주로 나누었습니다. 개발 리드가 따로 없었기 때문에 PM을 비롯한 다른 직군 분들과 개발직군의 협업 방식을 맞추기 위한 이야기가 많았습니다. 일회성으로 끝나는 자리가 되지 않기 위해 정기적으로 진행하면서 도출했던 개선점에 대한 피드백을 나누었습니다.

• Rule
• 어떤 부분이 개선되어야 할까
  • 각 파트에서 겪고 있는 어려움과 개선의 필요성을 느끼는 부분
• 어떻게 개선할 수 있을까
  • 서로가 생각하는 해결책과 이에 대한 의견
• 조금 더 논의가 필요해요
  • 회고 과정에서 나온, 조금 더 논의가 필요하지만 함께 이야기 하고 싶은 부분들
• follow-up
  • 협의한 내용을 실행해보고, 이후 개선사항을 재점검하고 피드백할 자리 사전 협의

프로젝트 회고

이런 부분에 대해 이야기를 나누었어요

프로젝트 단위로 협업할 구성원이 바뀌는 특성

근무했던 회사는 스쿼드와 같은 목적 조직 형태로 구성되어 있지는 않았습니다. 파트별 개발팀이 나뉘어 있고, 프로젝트 단위로 함께 할 팀 구성원이 꾸려졌습니다.
그러다 보니 함께 합을 맞췄던 구성원 대신 또 다른 팀원과 일하게 되고, 각각의 성향이 다르고 함께 일하던 방식이 다르다보니 다시 호흡을 맞추는 시간이 필요했습니다. 각자가 일하는 방식이 익숙하지 않아 버벅이는 경우도 있었구요. 팀원들 모두 이에 대해 피로함을 느끼는 부분이 있었으나 각자가 어떻게 해야할지에 대한 고민을 안고 있었습니다. 따라서 전체 파트 차원에서의 협의가 필요하다 느꼈습니다.

동일한 이벤트 프로젝트가 주기적으로 진행되는 경우도 있었는데, 이 경우에는 같은 구성원과 진행했습니다. 이 때는 한번 진행한 프로젝트에서의 아쉬웠던 점에 대한 개선점을 찾고 다음 번에는 명확히 개선할 수 있도록 함께 이야기하고 고민하는 자리가 필요하다고 느꼈습니다.

• Rule
• 문제점/개선점
• 좋았던 점, 이전보다 개선되었다고 느낀 점
• 프로젝트 진행 시 확인 사항
• 이렇게 개선해봅시다

중요! 개인의 책임을 탓하지 않고, 생산적인 고민을 하는 시간으로 만들자

이 때 특히 신경을 썼던 부분이 있습니다.

실수 혹은 잘못한 부분에 대해 투명하고 편하게 이야기 할 수 있도록 하자

개인의 잘못을 탓하지 않고, 개선하기 위한 고민을 함께 하자

회고를 위해서는 아쉬웠던 지점이나 실수 혹은 사고가 발생했던 지점을 되짚고, 그 원인을 명확히 분석해야 합니다. 그래야 다음 해결책을 준비하고 같은 문제가 발생하지 않도록 모두가 대비할 수 있으니까요.

그러다보면 자칫 누군가의 실수를 지적하는 불편한 자리로 느껴질 수 있을 것 같다는 생각을 했습니다. 서로의 책임을 전가하는 시간으로 만들고 싶지도 않았고요. 모두가 투명하고 편하고 당당하게 실수나 아쉬웠던 부분을 이야기하고, 더 잘 하기 위한 고민을 생산적으로 하고, 필요하다면 서로의 도움을 받고 이해하는 시간이 되었으면 했습니다.

그래서 회고 템플릿에 규칙으로도 명시하고, 시작전에 항상 강조하며 이 회고의 의도를 명확히 강조하기 위해 노력했습니다.

"각자의 잘잘못을 따지는 것이 아닌, 결과와 사실만을 기반으로 발생한 문제와 개선할 수 있는 점에 대해서 다룹니다."

"매 프로젝트 진행 시 필수적인 프론트엔드 x 백엔드 협업, 충분히 원활하게 이루어지고 있을까요?
업무의 효율성을 위해 손발을 맞추어야 할 필요성을 느껴 프&백 협업 회고를 제안했습니다."

"함께 더 효율적으로 일하기 위해 도출한 개선점에 대해 공감대를 형성하고
같이 더 잘 일할 수 있는 자리가 되었으면 좋겠습니다!"

다행히 회고에 참여했던 분들 모두 정말 적극적으로 임해주셨고, 이러한 취지에 공감해주셨기 때문에 불편함 없이 정기적으로 회고를 진행할 수 있었고, 아무리 사소한 것이라도 터놓고 이야기하며 빠르게 개선해 나갈 수 있었습니다.

정말 많은 이야기를 나누었지만, 회고를 통해 개선했던 것들 중에는 이런 것들이 있었어요.

✅ 비효율적인 소통방식으로 인한 업무 효율 저하

업무 소통 및 협업에 대한 가이드라인이 사내에 존재했지만, 프로젝트 특성과 참여 인원에 따라 소통의 사각지대가 생기는 경우가 잦아지는 시기가 있었습니다.

원인: 소통 채널이 일원화되어 있지 않음

• 개개인이 소통하면서 명확한 것들이 없었죠. 사실 소통에 대한 가이드라인이 있다면 간단히 해결될 문제들이었으니까요.
• 자잘한 사항들이 개개인끼리 소통해 결정되고 다른 팀원에게 공유가 되지 않거나, 잘못 전달되는 경우들이 발생했습니다.
• 이런 문제가 발생하던 이유는, 사내 메신저 채널은 주로 팀별로 나뉘어져있었으나 실제로 업무를 진행하는 팀은 프로젝트 단위로 구성되어 있었기 때문입니다. 소통할 채널이 마땅하지 않다보니 DM으로 소통하게 되고, DM채널별 구성원을 관리하기 어렵다보니 각자 자신만의 방식으로 개별 소통하는 경우가 생기게 되었습니다.

해결: 프로젝트별 소통 채널 생성

프로젝트 진행기간 동안 해당 프로젝트에 참여한 인원이 함께 소통하는 채널을 운영했습니다. 그리고 채널 운영과 관련해 함께 지킬 규칙을 만들었습니다.

• 채널의 생성 및 삭제는 PM이 맡아서 관리하기
• 프로젝트에 필요한 모든 소통은 해당 채널에서 진행하기
• 하나의 주제별 하나의 스레드에서 대화하기

결과

• 모든 관련 담당자들은 프로젝트와 관련된 업데이트 사항과 히스토리를 해당 채널에서 공유받을 수 있게 되었습니다.
• 모든 팀원들은 동일한 언어로 소통하며 서로 다르게 받아들여 생기는 혼선이 줄어들었습니다.

✅ 백엔드-프론트엔드 협업

api 작업 속도 및 일정이 맞지 않음

• 예상한 응답
  당시에는 api 문서와 버전 등 여러가지에 대한 논의 및 변경이 이루어지고 있는 상황이었고, 이 상태에서 프론트와 손발이 맞지 않아 업무 부하가 크게 발생했습니다. 프론트엔드에서는 api mocking을 적극적으로 활용해야 했죠. 그런데 기존에는 json data를 하드코딩해 사용하고 있었습니다.

예상한 데이터 응답값이 달라짐

프론트엔드에서 생각한 응답값의 형태와 백엔드에서 실제로 작업한 데이터 혹은 이후 변경된 값의 형태가 달라, 프론트엔드에서 완성된 api를 확인 후 재 작업하는데 드는 비용이 커졌습니다. 이에 따라 프로젝트 마감일정에 가까워졌을 때 예상하지 못한 사이드 이펙트가 생기는 경우도 있었습니다.

msw를 사용한 api mocking

msw를 사용하면 실제 비즈니스 로직과 동일하게 ap를 호출하는 형태로 mock data를 불러와 사용할 수 있습니다. 따라서 api endpoint만 교체해주면 작업완료된 실제 api를 사용할 수 있고, 프론트엔드의 코드는 변경할 필요가 없습니다. 또한 필요한 경우 각각의 상태 코드 및 예외 케이스 또한 지정해 응답값에 따른 처리로직까지 미리 작성해 테스트할 수 있습니다.

✅ 프론트엔드 협업

컴포넌트 설계의 필요성

이전에는 퍼블리셔가 먼저 UI를 작업하면, 해당 UI를 사용해 프론트엔드 개발을 하는 방식으로 진행되었습니다.
이렇게 작업된 주된 이유는 첫번째로 작업 일정과 속도였습니다. 보통 프로젝트를 시작할 때 프론트엔드 개발자는 백엔드, 기획자 등과 함께 리뷰하고 준비할 것들이 있는데, 퍼블리셔가 이 때 먼저 디자인을 보고 UI를 바로 작업해두면 프론트엔드 개발을 시작할 때 바로 이어 작업할 수 있기 때문이었죠.

그러다 보니 이런 문제가 있었죠.

프론트엔드 개발자 관점에서 좋은 컴포넌트 설계를 하기 어려움

• 개발을 고려하지 않고 UI만 작업되어 있다보니 작업 시에 일일히 고치게 되면 시간도 많이 들고 수정사항도 많이 발생하게 되었습니다. 성능도 고려하기 어려웠는데, 그렇다보니 시간이 없어 충분히 좋은 컴포넌트 구조를 가져가지 못한 채로 작업을 마무리하게 되는 경우들이 빈번히 발생했습니다.

• 그래서 프론트엔드 개발자가 먼저 컴포넌트 구조를 잡게 될 경우, 퍼블리셔 분이 해당 코드를 이해하고 그에 맞게 UI 작업을 하는 데에 추가적인 소통이 필요했습니다.

  

스토리북을 활용해 독립적인 UI를 담당하는 컴포넌트 설계하기

기존에는 컴포넌트의 문서화가 되어 있지 않았고,
컴포넌트의 재사용성이 다소 떨어지는 형태인 경우들이 보였습니다. 이후부터는 페이지 리뉴얼 작업 단계에서부터 디자이너분과 논의하여 공통적인 요소들을 묶어 재사용 가능한 컴포넌트들을 만들도록 하고, 스토리북을 통해 프론트엔드 팀원이 컴포넌트를 설계하고 함께 리뷰하는 것을 제안했습니다.

같은 프론트엔드 팀원들끼리도 협업하는 데 이점이 있었지만, 퍼블리셔 팀원분과 협업하기에도 훨씬 수월했습니다. 작업 일정 및 속도 상 다른 개발사항을 논의하고 준비하는 동안 퍼블리셔 분이 먼저 UI를 작업하면 이어받아 개발을 하게 되는 경우가 종종 있었는데, 그러다보니 개발을 고려한 컴포넌트의 구조가 아니어서 전반적인 리팩토링을 다시 하거나, 이 과정에서 UI가 조금씩 틀어져 바로잡는 데 시간을 더 쓰기도 했습니다. 그렇다고 프론트엔드 개발자가 먼저 컴포넌트 설계 후 그 위에 작업을 하게 되면 퍼블리셔 분은 컴포넌트를 확인하고 동작 및 구조를 파악하기 어려워 추가적인 소통이 필요했습니다.
스토리북은 독립적인 환경에서 컴포넌트 작업/리뷰가 가능하고, 그 구조를 파악하기도 쉽기 때문에 이를 통해 협업하면서 있었던 이전의 애로사항들을 해결할 수 있었습니다.

한결 좋아진 팀워크, 점점 맞는 손발

어떻게 보면 기본적인 부분들이기도 합니다. 그런데 의외로 일하다보면 기본적인 것들이 바쁜 일정에 쫓기면서 흐트러지는 것이 원활한 협업을 방해하는 원인이 되는 경우가 많았던 것 같아요.

중요한 것은 좋은 팀워크를 내기 위해 함께 노력하고 있는가, 그러기 위해 우리는 무엇을 할 수 있는가라고 생각합니다.

이렇게 회고를 진행하며 팀원들끼리의 호흡이 잘 맞게 되었고,
문제의식을 느꼈던 부분도 개선이 되어 효율적으로 일할 수 있게 되었다고 팀원들 모두가 느끼게 되었던 것 같습니다. 결과적으로 플랫폼 파트의 공식적인 개발문화로 자리잡아 주기적으로 진행하게 되었어요!

3. 기술적인 도전과제 해결하기

협업의 효율성을 올려 아낀 리소스는 이제 기술적인 성장을 위해 투입해야겠죠!
우리는 어떻게 함께 회사에 필요한 기술적인 고민을 하고, 개선할 수 있을까?가 다음으로 한 고민이었습니다.

⭐️ 기술 세미나 진행

사내 문화로 기술 세미나를 한 번씩 진행하고 있었습니다.
이 때 Typescript, React-Query를 사용한 상태관리 방식개선 등 여러 주제로 세미나를 열어 실제로 함께 개선하는 경험도 해볼 수 있었습니다.

우리에겐 지속적인 교류와 점검이 필요하다

하지만 기술 세미나를 진행하면서 아쉬웠던 점이 있었는데,
단순한 트렌드 공유나 단편적인 정보 공유의 목적이라면 세미나 자체로도 충분하지만,함께 지속적으로 고민하고 시도하며 피드백을 주고받는 자리가 필요하다는 생각이 들었습니다.

기술 세미나는 모든 개발팀이 참여했는데,
더 작은 단위로 모여, 가장 긴밀하게 협업하는 플랫폼 파트의 프론트엔드 팀원들끼리 수시로 소통하며 필요한 것들을 논의할 수 있는 자리의 필요성을 느꼈습니다.

그래서 제안했던 게 프론트엔드 주간 기술 미팅이었습니다.

⭐️ 프론트엔드 주간 기술 미팅

해당 업무에 대한 필요성 얼라인하기

먼저 팀원들을 모아 그 동안 개선이 필요하다고 느꼈던 부분들과 주간 기술 미팅 진행에 대한 의견들, 우선순위와 진행방식등에 대해 의견을 취합했습니다.

각 기술적인 과제들을 리스트업한 후 우선순위를 정하고, 예상 기간과 세부 태스크, 기대효과를 정리했습니다.

예를 들어, 가장 필요하다고 느끼는 것들에는 주로 아래와 같은 사항들이 있었습니다.

• 모노레포 구축
• 공통 모듈 관리
• storybook 도입 및 컴포넌트 재사용성 확보
• vite migration
• test 코드 도입

태스크 조율하기

이후 PM과 이야기해 해당 태스크를 실무와 병행할 수 있도록 시간을 확보하거나 업무량 조율을 할 수 있는지에 대해 이야기했습니다.

업무/심리적 부담감 줄이기 - 우리에겐 작고 연속된 성공 경험이 필요해

그런데 이전 회사 근무 경험과 개발 경력이 많지 않은 주니어 개발자들로 이루어진 팀이었던 만큼, 이를 진행하는 데 있어서 고려해야 할 것이 또 있었습니다. 이 일에 대한 필요성에 공감하고 하고 싶은 의지가 있음에도 팀원들이 부담감을 느끼고 있었기 때문입니다.
반드시 해야하는 업무들이 있는데, 이와 병행해 주어진 기간까지 맡은 태스크를 끝낼 수 있을지 자신이 없는 게 가장 큰 이유였습니다.

그래서 가장 작은 단위로 각 태스크들을 쪼개고, 한 주간 무조건 달성할 수 있는 목표를 정했습니다.

노션 페이지에서 장기 목표와 주간 단기 목표를 정하고, 달성률을 볼 수 있도록 했어요. 배운점이나 어려운 점을 함께 공유하고, 서로 격려하고 칭찬하는 자리가 될 수 있도록 했습니다.

할 것도 많은데.. 나는 아직도 이것밖에 못했어ㅠ (X)
이번 주간 목표는 달성했어! (O)

추가적인 업무를 해내야 한다는 부담감에서 벗어나 성취감을 느끼고, 더 해낼 수 있다는 자신감을 갖고, 스스로의 성장을 위해 무엇을 하고 있는지를 확인하며 의욕을 가질 수 있었으면 했습니다.

이후에 다른 팀원분으로부터 실제로 이 방식이 도움이 많이 되었다는 이야기를 들었을 때 다행이었고 뿌듯했습니다.

4. 프로덕트를 사랑하는 개발자

👏 유저를 관찰할 수 있는 기회를 마다하지 말자

전달받은 기획 내용대로 구현해내는 것에만 집중하는 것과, 유저의 사용 경험을 고려하며 개발하는 것과는 차이가 있다고 생각합니다.

이전에 들었던 A/B 테스트에 관한 강의에 따르면.. 데이터에 기반한 의사결정을 할 수 있는 조직에서 일한다면 가장 좋겠지만, 사용자 경험을 개선하기 위한 의사결정에 데이터를 사용할 수 있기까지 구축해야 하는 환경과 들이는 비용을 생각했을 때, 일반적으로 작은 스타트업의 경우 이러한 정량적인 데이터를 수집하고 관리하는 것이 오히려 비합리적인 선택일 수도 있다고 합니다. 오히려 유저를 직접 만날 수 있는 정성적인 데이터부터 사용하는 것이 더 효과적이고 효율적이라는 것이죠.

창작 공모전 멘토로 참여하기

근무하던 회사에서 챌린지 프로그램을 진행한 적이 있습니다.
일정 기간 동안 자사 서비스를 활용해 게임 등의 3D 컨텐츠를 제작해 공모전 형태로 출품하고, 해당 기간 동안 서비스를 사용해 높은 퀄리티의 콘텐츠를 간편하게 창작할 수 있도록 멘토링을 지원하는 프로그램이었습니다.
이 때 멘토로 참여해 개발하는 서비스의 유저들을 직접 만날 수 있는 기회가 있었습니다.

유저가 바라는 것은 따로 있구나...!

그리고 유저의 창작경험을 저해하는 요소들을 쉽게 발견할 수 있었을 뿐 아니라, 실제로 유저가 필요로 하는 요소들 또한 알 수 있었습니다.

👏 내가 할 수 있는 것이 있다면, 먼저 적극적으로 제안하자

멘토링 기간동안 얼라인된 팀 내 가장 큰 우선순위는 유저가 높은 품질의 콘텐츠를 제작하고, 손쉽게 프로덕트를 사용할 수 있도록 지원하는 것이었습니다.
따라서 필요한 수정사항이나 기능 업데이트는 기존보다 짧은 주기로 배포하여 유저의 피드백을 빠르게 반영하고자 했습니다.

그러기 위해서는 기획자, 디자이너와의 긴밀한 소통과 협업이 필요했습니다.
내부 협의를 거쳐 반영해야 할 사항의 우선순위를 정할 때,
기획과 디자인 단계를 최소화하고 어떻게 가장 적은 리소스를 들이고 유저의 니즈를 충족시킬 수 있을지, 어느 정도의 시간이 걸릴지는 개발자가 파악할 수 있습니다.
따라서 해결 방식과 일정 제안 > 기획, 디자인 파트 협의 > 작업 후 배포의 방식으로 진행했습니다.

1. 창작 경험을 저해하는 요소 해결: 자동저장 progress UI 개선

멘토링 프로그램 첫 주차부터 유저의 콘텐츠 창작 경험을 저해하는 요소를 바로 발견하게 되었는데요, 바로 그 당시에 릴리즈된 자동저장 기능이었습니다.

당시 창작한 콘텐츠를 저장 후 업로드할 때 progress UI가 표시되었습니다. 문제는 자동 저장 기능이 추가되면서 별도의 ux가이드라인이 없어 임의로 해당 작업을 맡은 개발자가 동일한 progress UI를 사용했던 것이었죠. 개발 시 테스트 환경에서는 용량이 작은 콘텐츠만 테스트해보았기 때문에 용량이 큰 콘텐츠는 이 progress UI가 표시되는 시간이 길어졌습니다. 해당 ui는 가장 상위에서 렌더링되어 사용자의 행동을 차단했기 때문에 사용자는 예상하지 못한 시점에 주기적으로 자동저장되는 오랜 시간 동안 창작을 방해받게 되었습니다.

실제 창작과정에서 용량이 큰 콘텐츠에 대한 고려를 하지 못한 UX라고 판단해, 릴리즈 된지 얼마 지나지 않은 시점에서 빠르게 이슈를 제기했고, 자동저장 끄기/켜기 기능 추가와 함께 progress UI를 변경했습니다. 이 때 저장하는 동안 사용자의 스튜디오 내 추가 액션을 막아야 했던 이유가 있었는지 히스토리와 개발 이슈 및 관련 로직을 파악했고, 문제가 없음을 확인해 다른 방식으로 UI개선을 제안해 디자이너와의 협의를 거쳐 반영했습니다.

2. 원하는 기능이 다른 경우: ‘개별 3D 오브젝트별 오디오 삽입’ 기능 추가

기존에는 3d 게임 등을 만들 때 배경음악을 삽입할 수 있도록 콘텐츠 전체에 오디오를 삽입하는 기능을 지원했습니다. 하지만 유저 커뮤니티 내에서 콘텐츠 전체가 아닌 3d 그래픽 오브젝트마다 개별적으로 오디오를 삽입하는 기능 지원 유무에 대한 문의와 요구사항을 빈번하게 확인할 수 있었습니다. 기획단에서의 예상과 달리 사용자는 배경음악 삽입 보다는 오브젝트와 플레이어 캐릭터와의 상호작용으로 게임의 인터렉션 요소를 만들고 싶어했고, 상호작용이 완료 되었다는 것을 효과음을 통해 알리고 싶어했습니다.

관련 로직 파악 후 소요시간 및 리소스를 산정해 기획 협의를 거쳤고, 해당 기능 1일만에 배포 후 커뮤니티 공지 후 사용자의 반응을 지켜볼 수 있었습니다.

3. 원하는 기능의 조합이 다른 경우: 이미지 GUI 버튼 등록 기능

: 널 위해
🌠 + 🖼️ 이것도
📙 + 🖲 이것도 준비했어!

: 하지만 내가 원하는 건 🌠 + 🖲 인 걸...

당시 스튜디오에서는 이미지, 영상, 3d모델 등 타입별 파일을 자유롭게 업로드해 콘텐츠에 추가해 작업할 수 있는 기능을 지원했습니다. 다양한 포맷의 파일을 스스로 업로드해 사용할 수도 있었고, 기존에 제공되는 에셋을 사용할 수도 있었어요.

이미지 파일을 사용하는 방식으로는

1) 🌠원하는 이미지를 업로드해 🖼️평평한 3D 오브젝트 판의 형태로 씬에 추가하거나
2) 📙제공되는 gui 이미지를 선택해 씬 화면에 🖲GUI의 형태로 추가하는 기능이 있었습니다.

하지만 유저들이 주로 사용하고자 했던 기능은 의외로
🌠원하는 이미지를 업로드해 씬 화면에 🖲GUI의 형태로 추가하는 것
이라는 것을 알게되었습니다.

게임을 제작하기 위해서는 커스터마이징이 가능한 다양한 종류의 GUI가 필요했기 때문에 이에 대한 니즈가 가장 많았던 것이었죠.

그러나 멘토링 기간 내에 기획과 디자인을 거쳐 해당 기능을 제공하기 위한 UI 디자인 및 기획서가 나오기는 힘들었고, 기획자/PM 또한 어떤 방식으로 이를 해결해야 할지, 어느 정도의 일정이 걸릴지 알 수 없어 어려운 점이 있었습니다.

해당 코드를 파악해보니 기존 UI를 크게 변경하지 않으면서 개발 리소스를 줄이고 빠르게 작업할 수 있는 방법이 떠올랐는데요,
기존에 원하는 이미지를 업로드하되, 해당 이미지 에셋의 정보를 제공하는 더보기 팝업에 버튼을 추가해 gui로 추가 할 수 있도록 기능을 제공하는 방식을 제안했습니다.

이를 위한 별도의 탭이나 버튼을 만들어 전체적인 UI틀에 영향을 미치지 않으면서, 유저가 원하는 기능을 제공할 수 있었고, 하루 내로 배포해 유저가 빠르게 사용할 수 있었습니다. 이후 해당 기능을 모든 유저가 활발하게 사용해 콘텐츠를 제작한 결과물들을 보면서 뿌듯했던 경험이 있습니다 :)

돌아보며

사실 시니어 개발자가 이미 있거나, 업무 프로세스와 조직문화가 잘 갖춰져 있고 체계적으로 업무가 진행되고 있는 곳이라면 이러한 고민을 할 필요는 없었을 것 같습니다. 관점에 따라 어떻게 보면 당연한 것들인 것도 있고, 이런 것들을 위해 이렇게까지 노력을 해야했다고? 라는 생각이 드는 분도 계실 수도 있을 것 같아요.

그래도 이러한 경험이 의미가 있었다고 느끼는 이유는,

• 주어진 상황에서 할 수 있는 것을 찾아 시도하고 변화를 이끌어 냈고
• 혼자가 아닌 팀이 함께 성장하는 경험을 할 수 있었고
• 이를 통해 나는 어떻게 팀과 회사에 기여할 수 있고, 어떤 태도와 마인드셋으로 일할 수 있을지에 대해 배울 수 있었기 때문

입니다.

하고자 하는 것을 함께 할 수 있는 팀원들이 있다는 것

위에서 이야기한 것들은 제안은 먼저 했지만, 절대 혼자 해낸 것은 아닙니다.
다른 팀원들이 더 좋은 생각을 내기도, 잘 할 수 있는 부분을 이끌어주기도 했고 '그래, 일단 한 번 해보자!'라고 선뜻 함께 해주었기 때문에 가능했던 일입니다. 잘 하다가 자신감이 떨어지거나 여력이 없어질 때는 다른 팀원분들에게 의지하기도 했고, 많이 배우기도 했습니다. 그런 팀원분들과 함께 할 수 있다는 것 자체가 가장 큰 복지인 것 같아요. '스타트업의 가장 큰 복지는 함께하는 뛰어난 동료'라는 말이 와닿았던 때였습니다.

나의 팀원을 신뢰할 수 있고, 자랑하고 싶은 팀에서 일한다는 것은

조직 문화에도 회사차원에서 관심을 많이 갖는 회사이기도 했지만, 열정있고 적극적인 팀원들이 모여있었기 때문에 각자에게 배우고 싶은 점들도 뚜렷했습니다.

하루는 다른 개발자 교육기관과 연계해 채용 설명회에서 실무자의 이야기를 전달하는 기회가 있었습니다.이 때 프론트엔드 팀을 대표해 개발팀이 일하는 방식을 발표했어요.

이 때 사례를 가져오는 것이 어렵지 않았습니다. 바로 각 팀원들이 일했던 모습들을 떠오르는대로 모아볼 수 있었고, 팀원들에게 "너의 ~~한 점을 자랑하고 싶은데, 보여주어도 괜찮은지" 물어보고 허락을 받았습니다.
다들 기분좋게 허락해주었고, 다른 개발 지망생 분들께 저를 포함한 다른 팀원분들이 어떻게 변화를 만들고 적극적으로 함께 일해왔는지를 보여줄 수 있었습니다.

이 때 새삼 느꼈습니다. 주변에 함께 한다는 것이 자랑스럽고, 배울 점이 많은 팀원들과 함께 하는 것은 역시 큰 복지라는 생각이 들었어요.

나는 어떤 팀원이 되고 싶은가, 어떤 팀에서 일하고 싶은가

그만큼 저 또한 함께 하고 싶은 팀원이 되고 싶다는 생각을 많이 했습니다. 좋은 개발자가 되기 위해 여러 공부를 꾸준히 하는 것은 당연하고 또 중요합니다.
다만 나아가 회사에서 일하는 한 조직의 구성원인 이상, 결국 우리가 작성하는 코드의 목적인 비즈니스와 프로덕트에 기여하기 위해서는 더 넓은 시야에서 함께 일하는 것을 이해하고 여러 방면에서 팀원들에게 도움이 되는 팀원이 되는 게 중요하다고 생각해요.

앞에서 말한 3가지 꼭지와 관련해

• 늘 함께 성장하기 위해 부단히 노력하는
• 사용자 관점에서 생각하고 프로덕트를 이해하며 개발하는
• 혼자 일하는 게 아닌, 넓은 시야에서 함께 일하는

좋은 개발자이자 동료가 되고자 합니다.

역시나 아직 많이 부족합니다! 하지만 그 간의 경험을 토대로 앞으로도 더 고민하고 시도하며, 함께 할 수 있는, 자랑하고 싶은 동료가 되어보겠습니다 :)