[고찰] 👩‍💻 나의 업무 습관에 대한 고찰과 개선점

어느날 벨로그를 보다가 마음에 확 드는 제목이 있어서 들어가봤다.

 

함께 일하고 싶은 사람 - 1. 업무 습관

 

내게는 만들고 싶은 게임을 만드는 것과는 별개로, 게임 회사에 취업을 하는 게 0순위이기 때문에 이런 제목이 마음에 드는 게 당연했다.

 

아무튼, 함께 일하고 싶은 사람 시리즈를 보니 '나는 그동안 어떻게 행동했는가'에 대해 깊은 성찰을 할 수 있었다. 여기서 말하는 하고 많은 능력들 중 각각의 능력에 나는 어느 정도의 수준인지 자아성찰해보고, 일정 수준을 도달하기 위해 내가 해야 할 일을 정리해볼 것이다.

 

---

업무 습관

 

1. 혼자서 탐구한 흔적이 있는 질문

혼자서 탐구한 흔적이 있는 질문.

 

'혼자서 탐구'는 내가 정말 부족했던 점 중에 하나였다. 난 지금 2학년 끝물이지만, 1학년 1학기에 팀으로 체스 게임을 개발할 때였다. 어떤 자신감이었는지는 모르겠지만, 기획자가 준 기획서를 제대로 읽어보지도 않고 빤히 나와있는 내용들을 질문하기 일쑤였다.

생각해보면 내가 그때 했던 질문들은 거의 나의 시간과 기획자의 시간을 버리는 생산성이 없는 질문이었을 것이다. 자연스럽게 어느 순간 내가 찾아보지 않은채로 질문을 너무 많이 한다는 것을 느꼈다. 의식한 뒤로는 줄이려고 노력했다.

 

궁금하면 "OO아, 이거..."부터 시작해 질문이 바로 튀어나왔지만, 대부분은

"아니다. 일단 내가 문서들 다 보고 이해가 안 되는 게 있으면 질문할게."가 뒤따라왔다. 장족의 발전은 아니고... 단족 정도의 발전이라고 할 수 있다.

 

2학년 2학기인 지금은 잘 되느냐하면 1학년 때보다 질문을 하는 빈도수가 줄고 문서를 꼼꼼하게 보기 시작했다. 사실 이건 나의 질문 때문이 아니라, 기획이 원하는 구현에 충실해 멋진 결과물을 내고 싶었기 때문이다.

 

 

생각해보면, 내가 하는 질문에 대해서 깊게 생각해본 적이 없었다. 협업을 하며 질문 횟수가 정해져있는 것도 아니고, 너무 과도하게만 하지 않으면 괜찮을 거라 생각했기 때문이다. 하지만, 이 글을 읽어보니 질문을 하는 능력이 중요하다고 느꼈다. 질문은 정보의 획득의 의미도 있지만, 신뢰이기 때문이다.

 

학교에서 선생님께 질문을 하는 아이들만 봐도 느껴진다.

 

1. 선생님. 저 이 문제 어려워요. 모르겠어요.

2. 선생님. 제가 이 문제를 풀기 위해 어떤 식을 써봤어요. 저는 이렇게 생각해서 이런 식을 썼는데, 답이 나오지 않아요. 이 접근법이 맞을까요? 아니면 다른 접근법을 써야 할까요?

 

1번은 질문인지 구별하기도 어렵다. 그와 반대로 2번 같은 경우에는 질문의 발생 배경과 스스로 도출한 생각, 원하는 답변을 명확하게 제시하고 있다. 선생님은 1번 학생과 2번 학생 중에 어떤 학생을 더 신뢰할까? 당연히 2번이다. 누가 더 노력했는지는 모르지만, 위에 말만 봐서는 2번은 문제를 풀려고 많은 노력을 했다는 것을 알 수 있기 때문.

 

 

그렇다면 나는 질문을 어떻게 해야할까?

 

- 원하는 답변이 무엇인지

- 질문 발생 배경

 

이 두 개는 기본적으로 반드시 들어가야한다. 

 

OO아, 여기 이 시스템이 들어간 기획 의도를 알 수 있을까? 기획서를 보다가 이 시스템은 우리 게임이 추구하는 '빠른 템포의 전투'와 맞지 않다는 생각이 들었어. 시스템이 플레이어가 움직이는 것에 방해를 줘서 오히려 템포를 방해할 것 같은 느낌이 들었기 때문이야.

 

부끄럽지만, 예시로 내가 할 법한 질문을 써봤다. 처음에 두괄식으로 답변받고자 하는 질문을 던지고 그렇게 생각하게 된 배경을 서술하는 것이다. 그렇지만, 질문을 체계적으로 하는 게 하루 아침에 되는 것은 아니다. 나만 봐도, 입이 뇌보다 먼저 반응하기 때문이다.

 

이러한 습관을 고치려면, 글을 먼저 쓰는 게 중요한 것 같다. 글은 언제나 고칠 수 있고 체계적이고 나는 말보다 글을 더 잘 쓰니까. 질문을 하기 전엔, 완벽한 글은 필요하지 않지만 위에 말한 두 개를 충족하는 짧은 글 정도는 구상하고 가야겠다.

 

 

2. 물어보기 전에 대답하는 사람

 

실제로 많지 않은 대단한 사람이다. 자신의 현재 진행 상태를 먼저 공유하거나 누군가 궁금할 수도 있는 점을 예측해 미리 답한다는 것은 쉽지 않은 일이기 때문이다.

 

실제로 1학년 2학기 팀프로젝트에서 그게 잘 되지 않아 프로젝트를 실패한 경험이 있었다. 다행스럽게도, 지금 진행하는 졸업 작품 프로젝트는 과거 실패의 경험을 극복하고자 노션의 대쉬보드로 팀원들의 각자 진행 상황을 알 수 있게 레이아웃을 만들어놓았다.

 

나름 잘 진행되고 있는 Todo 대쉬보드이며 리더로서 팀원들의 현재 상태를 묻지 않고도 볼 수 있다는 장점이 있었다. 역시 한 번의 실패는 여러 번의 성공이 될 수 있다.

 

이렇게 물어보기 전에 대답할 수 있는 것들을 위에 블로그에서 따왔다.

 

• 위처럼, 현재 하고 있는 일에 대한 상황 공유
• 피드백이 있을 법한 부분에 자신의 의도와 의견을 첨언하는 것
• 요청에 대한 기한과 상황 공유 날짜를 알려주는 것
• 확인을 표현하는 것

 

이렇게 있다. 나는 개발자이니, 기획의 요청에 대한 기한과 상황 공유 날짜를 알려주는 게 중요하다고 생각한다. 예를 들어,

 

요청한 점멸과 유체화 스킬을 10일 후인 10월 20일까지 개발하겠습니다. 10월 10일엔 최대한 점멸 스킬 기능과 이펙트까지 추가해서 보여드릴 예정입니다. 15일에는 유체화 스킬을 보여드리고 피드백을 받겠습니다.

 

이렇게 되면 데드라인에 대한 약속도 더 잘 지킬 수 있게 되고, 상황 공유도 할 수 있어 기획자와의 신뢰가 높아질 것 같다. 

 

개발자로서 구현 진행 상황을 누가 요청하지 않아도 날짜와 같이 정확히 공유해야겠다!

 

 

3. 독성 말투가 없는 사람

 

이 부분에 대해서는 내 강점이다! 나는 기본적으로 작은 것에도 민감해, 사람들을 배려하지 않으면 내가 오히려 불편하기 때문이다. 그래도 편하고 친한 팀원들과 대화할 때는 독성 말투가 없다고 말할 수는 없다. 물론 모두 장난으로 받아들이지만 말이다.

 

여기서 중요한 건 상대방이 잘못했다는 점을 전제로 말하지 않는 것이다.

 

"이거 왜 안 보셨나요?"

 

위는 상대방의 잘잘못을 따지는 것 같다.

 

"혹시 일주일 전에 디자인 시안을 보낸 메일 보셨나요? 메일이 누락됐을까 봐 걱정돼서 말씀드립니다."

 

라고 말하는 사람과 훨씬 일하고 싶기 때문이다. 나는 졸업 작품 프로젝트의 리더라 팀원들의 업무 데드라인을 체크하고 일을 했는지, 안 했는지 체크할 때가 많다. 따라서 둥글둥글한 말투로 말하는 게 더욱 더 중요할 것 같다.

 

 

내가 평소에 팀원들에게 하는 질문은,

 

"이거 왜 기간 안에 못했는지 알 수 있을까?"

 

같은 경우가 많다. 그렇게 뾰족한 질문은 아니지만, 더 둥글고 좋은 말이 있다!

 

"이 일이 기간 안에 하기 어려운 이유가 있을까? 나나 다른 팀원들이 도와줄 건 없을까?"

 

참으로 따뜻하고 건설적이기까지 한 질문이다! 이 챕터에서는 리더로서 팀원들에게 둥글게 말하는 스킬을 배워갈 수 있었다. 졸업 작품은 반년 넘게 진행하게 되니까, 사소한 일로 싸우지 않게 이런 말투를 습관 들여야겠다.

 

 

4. 문제에서 성장하는 사람

 

문제에서 성장한다는 것은 개발자에게는 가장 중요한 역량인 것 같다. 개발자는 오류를 먹고 자라기 때문이다. 개발뿐만이 아니다. 실패를 먹고 성장하는 사람과 일하고 싶은 건 당연하지 않은가. 자기소개서의 장점보다 단점과 그 해결방안을 더 많이 써야하는 이유이기도 한 것 같다.

 

난 내가 '문제에서 성장하는' 역량은 어느정도 보유하고 있다고 자신있게 말할 수 있다. 지적을 받거나 스스로 성찰한 행동은 의식하고 하지 않기로 마음을 먹고, 그에 맞는 행동을 한다고 생각하기 때문이다. 

 

 

다만, 그런 나의 문제점은 주로 누군가의 피드백에서 성장하는 비율이 너무 많다는 것이다. 다른 사람의 피드백 또한 정말 중요하지만, 자기성찰을 통해 스스로의 문제를 탐색하고 성장하는 사람은 당장 일에 익숙하지 않더라도 발전 가능성이 무한한 사람이기 때문이다.

 

그런 면에서 내 업무 습관에 대해서 탐구하고 개선점을 찾는 이 행동은 바람직한 행동이라고 할 수 있다. 다만, 굳이 마음을 먹지 않아도 일상 생활 속에서 성찰과 성장을 하려면 의식적으로 꾸준히 자기 자신을 들여다보는 행동이 필요하다고 생각한다. 그런 행동이 쌓이고 쌓여 자신에 대한 이해도가  높아지면, 그게 흔히 말하는 메타인지가 높다는 말!

 

다른 사람의 피드백을 귀중하게 여겨 성장할뿐만이 아니라, 개인적으로 항상 성찰하는 습관을 가지고 보완할 점과 개선점을 생각하는 연습이 필요한 것 같다. 특히 리더로서는 더더욱 중요한 역량이다.

 

초등학생 같긴 하지만... 티스토리 비공개 글로 성찰 노트를 만들어서 그날 그날 있었던 내 보완점과 개선점을 구체적으로 적는 노력을 해야겠다. 오늘부터 시작이다!

 

 

5. 근거, 사례, 대안을 제시하는 사람

 

최근에, 크래프톤의 인재상에서 이런 인재상을 보았다.

 

대안 없는 불평을 건설적 비판으로 오해해서는 안 되고, 건설적 비판을 비난으로 오해하면 안 됩니다.

 

정말 맞는 말이라고 생각했다! 다만, 오해하면 안된다는 것보다는, 졸업작품 프로젝트의 PM으로서 대안 없는 불평 대신 건설적 비판을 해야한다는 것을 정말 깊게 느꼈다. 그리고 오늘 이 글을 보면서 대안 없는 불평과 건설적 비판의 차이가 무엇인지 알 수 있었다.

 

근거, 대안이 없는 의견은 불평이 되기 매우 쉽다는 것이다! 

 

사례도 있다면 강력한 의견이 되지만, 일단 근거와 대안 조차도 없다면 "이유는 모르겠는데 그냥 별로야... 어떡하냐."라는 말과 동일하기 때문이다.

 

반대로 건설적 비판은 프로젝트의 완성도에 매우 도움이 된다. 실제 사례로 졸업 작품 팀원 중 건설적인 비판을 굉장히 잘 하는 친구 C가 있다. C는 로그라이크(트) 게임에 대한 이해도가 정말 높아 회의를 할 때 레퍼런스 게임의 사례를 들어 자신의 의견을 얘기한다.

 

"이런 기능은 난이도를 높이기 위해서는 적절하지 않은 것 같아. (의견)
플레이어 움직임을 억제해서 플레이어에게 답답함을 줘. (근거)
OO 게임에서는 난이도 상승을 위해 이런 시스템을 이용했는데, 상당히 재미있고 거부감도 들지 않아. (사례)
이걸 우리 게임과 맞게 이 부분만 바꿔서 사용하면 괜찮을 것 같지 않아? (대안)"

 

물론 이렇게 짜임새 있게 이야기하지는 않지만, 이 흐름과 비슷하게 이야기하는 C는 기획 회의할 때 건설적 비판을 함으로써 게임의 재미와 완성도에 많은 기여를 한다.

 

C와 같이 게임에 대한 건설적 비판을 하려면 많은 경험이 중요한 것 같다. 학교생활을 하면서 게임을 자주 할 수는 없지만, 일주일에 한두 번이라도 하며 장단점과 재미 요소를 분석한 보고서를 틈틈이 써야겠다는 생각이 들었다. 또, 우리 게임의 시스템이 더 발전할 수 있도록 항상 의심하고 생각해야겠다.

 

이건 PM과 팀 구성원으로서의 이야기였고, 리더로서의 이야기는 조금 다르다.

 

나는 사람들의 피드백에 남들보다 더 민감해하는 편이다. 따라서 대안 없는 불평에도 분명히 흔들리는 경우가 있을 수 있다고 생각한다. 이런 불평에 흔들리지 않기 위해, 불평과 비판을 명확히 구분하도록 하자. 또, 근거가 없는 피드백은 부드럽게 근거를 물어보는 습관을 가져야겠다!

 

 

6. 코드에 적용에 이유가 있는 사람

 

원래는 기술 적용이지만, 나는 코드라고 국한시켜서 해석을 했다. 내가 생각하기엔 개발자로서 가장 중요하다고 생각하는 역량 중 하나이다.

 

보통, 사람들은 자기가 하는 행동에 의미를 부여하지 않는다. 나 또한 마찬가지이다. 테이블에서 손장난을 하는데는 별 의미가 없고, 발을 까닥이면서 리듬을 타는 것 또한 별 의미가 없다.

 

다만, 나는 코드는 한 줄 한 줄, 자료형과 변수명부터 큰 구조까지 전부 의도가 있어야 한다고 생각한다. 

 

그렇지 않으면, 내가 쓴 코드에 대한 신뢰가 현저히 떨어지기 때문이다. 생각하지 않고 짜는 코드를 신뢰할 수 있는 사람은 없다.

 

나도 완벽하지 못해서 게임을 개발하거나 알고리즘 문제를 풀 때 이따금씩 습관대로 행동할 때가 있다. 하지만, 이렇게 되면 절대 발전할 수 없다는 것을 알고 있다. 옛날부터 이를 느껴 알고리즘 문제를 풀 때마다 코멘트와 주석을 달고 있다. 알고리즘을 설계하고 코드를 짜면, 알고리즘 설계 하나 하나가 코드의 의도가 되기 때문이다. 일종의 연습인 셈이다.

 

또, 의도를 가지고 코드를 짜면 후에 더 좋은 코드로도 갱신이 가능하다. 오늘은 A 방식으로 짜야겠다고 생각했는데, 몇 달 뒤에 의도를 읽어보니 B 방식으로 짜는 게 훨씬 효율적이라는 생각나는 것처럼.

 

항상 정신이 말짱한 상태로 코드를 짜고, 하나 하나에 의도를 생각하며 코드를 짜는 습관을 들여야겠다. 처음에는 정말 어렵지만, 알고리즘 문제를 꾸준하게 풀며 조금은 습관이 되었다고 생각한다.

이번 졸업 작품에도 많은 양의 코드와 다양한 기술이 들어갈 텐데, 의도를 생각하고 코딩하는 것뿐만이 아니라 주석을 달고, PR에 코드 설명을 간단하게 하면서 의도 또한 적어야겠다!

 

 

 

7. Strong Opinions, Weakly Held => Followership

 

자신의 의견은 강하지만, 그것에 집착하지는 않는 태도를 말한다. 본문은 Strong View라고 적혀있지만, 더 많이 사용되는 Strong Opinions로 고쳤다.

 

나같은 경우에는 Strong Opinions, Weakly Held같은 경우는 정말 잘 장착되어있다고 생각한다.

 

Strong Opinions의 기본적으로 주어지거나 해야겠다고 생각한 모든 일에 진심이기 때문이다. 그래서 더 짱짱한 근거를 찾고 의견을 단단하게 만든다. 

 

Weakly Held는 내가 단순한 사람이라 어쩌다 얻게 된 역량이다. 내 의견보다 근거가 논리적이고 좋은 의견을 보며 주장했던 내 의견은 사실 잘 보이지 않고 새로운 의견에 눈이 반짝반짝해지기 때문이다. 그동안은 스스로가 줏대 없다고 생각했지만, 본문을 보니 최적의 방안을 찾는 것이 오히려 더 좋다는 말에 위로를 받았다.

 

다만, String Opinions에서 내가 생각한 근거가 정말 논리적인지 항상 객관적으로 판단하는 게 조금 부족한 것 같다. 근거는 과거의 내가 잘 고안했을 거라 생각하는 생각이 문제였다. 의견을 모두 만들고 다시 근거가 논리적이고 의견을 강하게 뒷받침하는지 생각해보자!

 

 

---

 

정리

말이 정말 많았던 것 같다. 정리해보자.

 

챕터	현재 역량	노력해야할 것
1. 탐구하는 질문하기	★★☆☆☆	- 질문하기 전 짧은 글로 먼저 써보기 - 질문을 명확하게 하기
2. 물어보기 전에 대답하기	★★☆☆☆	- 현재 상황을 정기적으로 공유하기 - 상황 공유 날짜를 미리 정해놓기
3. 독성 말투가 사용하지 않기	★★★★★	- 상대방의 잘못을 전제로 말하지 않기 - 건설적이고 따뜻한 피드백을 주기
4. 문제에서 성장하기	★★★☆☆	- 성찰 노트 만들기
5. 근거, 사례, 대안 제시하기	★★☆☆☆	- 의견을 글로 정리하고 발표하기 - 불평과 건설적 비판을 구분하기 - 내 의견이 불평인지, 건설적 비판인지 객관적으로 판단하기
6. 코드 적용에 의도를 넣기	★★★☆☆	- 코드에 의도가 담긴 주석 달기 - PR에 코드의 의도를 쓰기 - 알고리즘 문제를 풀고 코멘트하며 연습하기
7. 강한 의견과 집착하지 않기	★★★★☆	- 의견을 논리적 근거를 담아 견고하게 만들기 - 근거가 논리적인지 살피기

 

모두 정리해봤다. 부족한 역량을 우선순위로 두어 노력해야할 것을 조금조금씩 구체화해서 내 업무 습관이 개선되도록 노력해야겠다. 사실 지금 당장 이것들을 모두 다하기엔 무리가 있다고 생각하기에...

 

당장은 팀 작업을 하면서 1, 2번을 실행해보고 팀 회의를 하며 5번을 내 것으로 만들어야겠다. 

 

부족한 게 많다! 아자아자 이민영!!