[ je 개발 회고 ] 2주년 설문 조사 - 팀장, 사수

 

  2주년이 된지 꽤 지났지만, 간만에 설문조사를 진행했다. 이번에는 작년 한 해 동안 L 프로젝트를 만들며 생고생을 했던 팀장님과 사수에게 많은 질문을 쏟아 부으며 내가 지금 잘하고 있는 점과 개선해야할 점에 대해 알아보는 시간을 가졌다.

 

1. 팀장

  팀장님의 경우, 프로젝트 전체를 관리하는 분이셨기에 이번 프로젝트에 있어서 나는 얼마나 이 프로젝트에 기여했는지를 여쭤보고 싶었다. 두 번째로는, 내가 기획과 디자인을 많이 했고 이것을 컨펌해주신 분이 팀장님이었기에 같이 일하면서 어떤 부분이 나에게는 강점이고, 단점인지를 여쭤봤다. 또, 이제 1년이 지났으니 1년 전과 비교했을 때 지금의 나는 어떤 위치에 있고, 팀 내 생활에 있어서 나는 얼마나 잘하고 있는지 평가를 받고 싶었다.

 

 

(1) L 프로젝트에서 크게 기여한 것은 " MDM + UI 기획 "  이다

복잡하고 꼼꼼해야 하지만 재미없을 수 있는 작업을 책임감있게 잘 했음!
UI 기획 일부를 담당했기 때문에 Roya 의 빚을 줄일 수 있었음 ㅠ.ㅠ

 

  여기에서 얘기하는 MDM 이 Master Data Management 의 약자인데 쉽게 말하면 Admin 페이지다. 그런데 조금 더 데이터 관리에 특화된 Admin 페이지를 뜻한다. 이번 프로젝트에서 Admin 페이지를 11개나 만들었다. MDM 을 하다 보면, 말씀하신 것처럼 좀 지루할 수도 있고, 이게 데이터를 관리하는 것이다 보니까 요구사항이 변경되거나 내부에서 정책이 변경되면 직격타를 맞는 페이지인지라 요구사항의 혼돈의 카오스에서 살아남기 힘들었다.

 

  UI 기획은, UI/UX 전문 서적을 보고 공부하고, 또 발표까지 했을 정도로 정말 신경 많이 쓴 부분이다. 내가 도메인에 대한 전문 지식도 없고, 디자인에 대한 전문 지식도 없는데, 이 두가지의 전문지식을 필요로 하는 일을 하려니 굉장히 힘들었다.

 

  하지만, 결국 다 해냈고 또 고객으로부터 요구사항이 오면 그에 맞춰 대응도 다 하고 있었기에, 팀장님은 그 부분을 가장 높게 평가해주신 것이 아닐까 싶다.

 

 

(2) L 프로젝트에서 미흡, 혹은 더 참여했야 했던 것은  " 2% 부족한 적극성(?) "   이다

무엇이든 고민도 많이하고, 공부하고, 생각하는데 2%를 채우지 못하고 끝나는 것 같다.
넘어서자!

 

  이 피드백은, 정말 공감하는 피드백이다. 이번에 스스로도 좀 반성한 부분이 "겉핥기"처럼 한 것들이 너무 많다. UI/UX 에 공부를 하긴 했지만, 가장 중요한 공부는 레퍼런스를 많이 찾아 보는 것이다. 하지만 레퍼런스를 많이 찾아 보지 않고 이론만으로 디자인을 하려는 경향이 없지 않아 있었다.

 

  도메인 지식에 있어서도 마찬가지다. 화면을 기획할 때 데이터가 있으면, 데이터에 대한 조사가 깊이 있게 이뤄지지 못했던 것 같다. 최근의 정보는 어떤지, 뉴스 기사를 보면 어떻게 데이터들을 비교하고 정보를 얻어내는지를 조금만 더 찾아보면 나올 수 있는데, 그것을 찾지 못했던 것 같다.

 

  뭔가 할 때 시간이 없다는 핑계로 깔짝 대는 것이 아니라 시간을 더 투자해서라도 깊이 있게 찾아봐야겠다.

 

 

(3) 같이 일할 때, 장점은  " 피드백이 빠름 "  이다

피드백이 바른 것은 최고의 장점인 것 같아요!
리더로서 한 명, 한 명을 다 챙기고 업무를 확인하고 관리해야 하는 건 당연하지만 어려움 ㅠ.ㅠ
리베처럼 피드백이 빠른 팀원이 있어서 업무 파악 + 효율성 증대에 큰 도움이 됩니다.

 

  나는 일할 때 노트 필기를 많이 한다. 해야할 일들을 다 적고 우선순위를 정한 다음에 일을 시작한다. 그렇다 보니 뭔가 일을 하는 와중에 요청 사항이 들어오면, 빠르게 지금 내가 해야할 일들과 요청 사항 사이의 우선순위를 결정하고 컨펌을 받고 일을 진행한다. 그리고 요청 사항을 다 완료하면 바로 공지하고, 이제 다음 작업으로 무엇을 진행할 거고, 이 요청사항을 반영하면서 일정이 어느 정도로 미뤄질 것 같다. 이렇게 말하는 편이다.

 

  사실 처음부터, 이렇게 하지는 않았다. 특히 F 프로젝트 했을 때만 하더라도 그냥 마구잡이로 아 해야돼요? 네. 하면서 그냥 요구사항이 오는 족족 다 했던 것 같다. 그런데 그렇게 하니 내가 무슨 일을 했는지 기억도 잘 나지 않고, 뭘 해야 했는지도 까먹는 경우가 많았다. 그래서 노트 필기를 시작했다.

 

  또, 일할 때 중요하게 생각하는 것 중에 하나가 요구 사항을 받았으면 반드시 피드백 하는 것이다. 사람 사이의 대화에서도 말을 했는데 상대가 묵묵부답으로 일관하고 있으면 이해했는지, 안했는지 알 길이 없다. 나는 일을 할 때는 반드시 서로의 상황을 인지하는 것이 중요하다고 생각한다. 그리고 요구 사항이 있고 그것을 하기로 했으면 우선순위에 따라서 일을 진행하되, 그게 끝났으면 바로 공지드리는 것이 옳다 생각한다. 보통 팀장님이 하시는 요구사항들은 우선순위가 1위였어서 재깍재깍 피드백을 드렸고, 그래서 더 이 부분을 좋아하시는 것이지 않나 싶다.

 

 

 

(4) 같이 일할 때, 단점은  " 덜 꼼꼼함 "  이다

꼼꼼하지만!
조금 더 신경쓰면 훨씬 좋을 것 같음

 

  그래.. 맞다.... 이건 아까 전 2% 부족한 적극성과도 의미가 비슷할 것 같다.

 

  예전에 팀장님이 "꼼꼼하게 챙겨라" 라고 말씀하신 적이 있는데 그 때가 UI 를 테스트 할 때였다. 화면에서 에러는 나지 않는지, 어딘가 이상한 것은 없는지 꼼꼼하게 UI 를 테스트해보고 따져야 한다는 것이었다. 나는 분명히 에러가 안났는데, 다른 사람이 테스트를 하니 에러가 났다. 무슨 에러였냐면, 검색창에서 검색할 때 나는 사용자로부터 받은 입력값을 정규식을 사용해서 검색 내용이 포함된 컨텐츠가 있는지를 찾는다. 나는 여러 번 테스트 했을 때 문제가 발생하지 않아 넘겼다. 하지만 동료 개발자가 대괄호( [ ) 를 넣으니 에러가 발생했던 것이다. 왜 났는지를 파악해보니 대괄호가 정규식에서 메타 언어기 때문에 에러가 나는 것이었다. 

 

  사실 위의 예시는 내가 너무 인상 깊어서 쓴 것이고, 이것 외에도 굉장히 자잘자잘하게 내가 덜 꼼꼼하게 테스트하고 확인해서 놓친 에러들이 좀 많았다. 그래도 이제는 조금이라도 더 꼼꼼해지기 위해서 노력을 하고는 있다.   

 

 

 

  회사의 컨텐츠는 대외비기 때문에 내용들을 다 보여줄 수는 없지만, 이런식으로 나 혼자서 문서들을 계속 남기고 있는 중이다. 위의 컨텐츠들은 나중에 내가 E2E 테스트를 만들 때 사용할 시나리오로 남겨두고 있다. 

 

  지금 이렇게 글을 쓰면서 생각해보니, 내가 덜 꼼꼼한 것을 막는 방법은 "기록" 인 것 같다. 일의 우선순위를 작성하듯이 이것도 시나리오들을 하나씩 다 글로 작성해나가면서 내가 무엇을 따져보지 못했는가를 파악하는 것 같다.

 

  아무리 잘 해도 하나에서 문제가 발생해버리면 실패작이다. 정말 꼼꼼하게 무엇을 해야하는지, 어떤 것들을 테스트해야 하는지 등을 기록하면서 일을 하자.

 

(5) 1년 전과 비교했을 때, 업무에 있어 달라진 점이 있다면 " 알잘딱깔센 "  이다

1년 전과 비교했을 때 업무에 대해 설명하는 시간이 줄어들었음.
혹은 말하지 않아도 알아서 하는 것들이 많아짐.

 

  나는 이번에도 팀장님에게 엄청 많이 질문했다 생각했는데... 그래도 작년 만큼은 아닌가 보다(작년엔 얼마나 심했던 걸까) 

 

  그래도 이 얘기는 그만큼 내가 우리 회사의 도메인에 적응하고, 무엇이 더 중요한 일인지를 파악하는 능력이 생긴 것이 아닐까 생각해본다.

 

 

(6) 팀 내 Liebe 의 포지션은 " 점심식사 메이트(?) "  다

한 끗 차이로 분위기가 바뀌는데 "한 끗"을 담당
맞는 비유인지는 모르겠지만...

 

  이건 아마 내가 업무 외적인 상황에서 팀 내 분위기를 화기애애하게 만드는데 도움을 준다는 말씀인 것 같다. 실제로 팀장님이 그렇게 다른 분들에게 나를 소개하셨던 것을 듣기도 했다.

 

  업무를 하다 보면 갈등 상황이 빚어지기도 하지만, 공과 사는 구별해야 한다고 생각한다. 일할 때는 딱 일을 하고, 점심 식사와 같은 자리에서는 좀더 유한 분위기여야 하고 일할 때 받은 스트레스로부터 쉴 수 있는 시간이 돼야 한다고 생각한다.

 

 

(5) Liebe 를 한 마디로 표현하면 " 로잘알 "  이다

생략

 

  로잘알은 축잘알같은 줄임말에서 나온 걸로 "로야 잘 알" 이라는 의미다. 그러니까 팀장님을 매우 잘 안다는 얘기다. 

 

  이건 나도 인정한다. 전화 받을 때 표정만 보고 어느 고객사에서 팀장님에게 무슨 말 했을지 대강 짐작이 간다. 그것 이외에도 좀 많다. 팀장님 보고, "로야님 지금 OO 하시죠?", "지금 OO 하고 싶으시죠?" 라고 물어보면 대부분 다 적중이고, 뭔가 아 이거 로야님 반응이 좀 있겠다 싶어서 팀장님을 쳐다보면 아니나 다를까 내가 예상한 반응을 하고 계신다. 더 재밌는 건, 이제 그런 상황에서 내가 로야님의 눈치를 볼 걸 또 알고 계셔서 팀장님도 갑자기 나를 쳐다보고 웃으신다. 

 

 자타공인 로잘알. 재밌게 회사 생활하고 있다.

 

 

(6) 그 외 하고 싶은 말씀이 있으시다면 자유롭게!

(개인적일 수 있음)
벌써 2년이 지났나요?
적으면서 생각해봤는데 제가 리베는 이해해주겠지 or 다 알겠지라고 생각하면서
소홀했던 부분이 있는 것 같아 반성했어요.
앞으로도 그러지 않겠단 장담은 할 수 없지만 노력할게요 ㅋㅋㅋ
위에도 적었지만 한 끗, 로잘알이라면 말하지 않아도 알겠죠?
고맙고, 수고했고, 앞으로도 잘 부탁해요!
(여기는 성의 있게 글씨 씀!)

 

  이건 설문지를 돌려주시고 나서도 나에게 하셨던 말씀이다.

 

  로잘알이기에 무슨 말씀이 하고 싶으신지 다 알겠다.

 

---

2. 사수

  사수의 경우, 나와 함께 둘이서 L 프로젝트 프론트엔드 개발을 같이 했다. 내 코드에 대해서 리뷰를 받아볼 수 있겠단 생각이 들었기에 코드에 대한 질문과, 협업을 같이 하면서 내게 부족한 점은 무엇이지, 그리고 일할 때 중요하게 생각하는 여러가지가 있는데 과연 같이 협업하는 분이 내가 그것들을 중요하게 생각하는 것처럼 느껴지는지 알아보기 위한 질문들을 했다.

 

 

(1) 코드에서 보이는 강점은 " 기능 완성 "  이다

현업에서 가장 중요한 건 기능완성이라고 생각한다.
Liebe 의 코드는 기능 완성하고 이후에 리팩터링하는 것이 대부분인 것 같다.
코드를 작성하는데 있어서 이 점은 강점이다.

 

  굉장히 좋은 평가지만 한 편으로는 더 분발해야겠다 생각했다

 

  일단, 기능을 구현하는데 있어서, 기능을 어떻게든 완성하는 것이 주 목적이긴 했다. 원래 1년으로 계획된 1차 운영 릴리즈가 갑자기 6개월로 절반 가량 줄어들면서 일정이 매우 타이트해졌다. 그 6개월 안에 기획도 끝내야 하고, 디자인도 끝내야 하고, 개발도 끝내야 하는 것이었다. 그리고 내가 기획을 한다고 해서 그게 완전히 고정되는 것이 아니라, 계속 수정되고 수정된다. 그렇다 보니 개발을 할 때 급하게 "아 빨리 구현부터 하자" 라는 마인드로 임했다. 

 

  사실, 나도 기능 완성이 중요하다고 생각한다. 개발자는 의미 있는 것을 개발하는 사람이다. 하지만, 개발자이기에 아키텍쳐나 더 운영, 유지보수가 용이한 방식으로 코드를 짜는 것도 중요한 능력이다. 그런 의미에서 나는 이번에 실패했다. 그래서 지금 리팩터링하는 과정에서 코드를 선언적으로 바꾸고, 역할을 잘게 쪼개 분할하고, 몇가지 테스트 코드를 도입하고 있다.  

 

  사수가 이번에 강점으로 써준 것은, 이렇게 타이트한 일정 속에서, 어떻게든 요구된 기능을 다 구현할 줄 안다는 것으로 받아들이면 될 것 같다.

 

(2) 코드에서 보이는 단점은  " 복잡함 "   이다

강박적인 코드 분할은 오히려 보기 불편하게 한다.
리팩터링을 하면서 코드가 복잡해진다고 느낄 때가 있다.
협업하는 개발자로서 사요하기 꺼려질 때가 있다.(가끔)

 

  이번에 코드를 엄청 모듈화 하고 있었다. 요구사항을 진짜 많이 받다 보니 각 코드가 어떤 일을 하는지 빨리 파악하는 것이 중요했다. 그래서 각 역할/기능 별로 코드들을 쪼개고 함수로 나눠서 사용했다. 

  하지만, 어느정도 융통성을 발휘해서 의존성이 있는 것들은 좀 유연하게 명령형으로 쓸 법도 한데, 그런 것 마저도 다 함수로 빼내서 사용했기에 사수가 보기에는 굳이 저렇게 까지 작성해야 하나. 라는 생각을 하게 만든 것 같다. 

 

 다음부터는 너무 강박적으로 코드를 분할하기 보다는, 함수 역할의 범위를 조금 더 넓혀서 작성해야겠다는 생각이 들었다. 같이 협업하는 살마이 힘들다고 하면 그것은 좋지 못한 코드일 수 있다.

 

 

(3) 협업할 때 더 키워야할 점은  " 소통(코드 관련) "   이다

내가 개발한 코드에 알지 못하는 기능이 추가되었는데
추가되었다는 내용을 들은 적이 없다.
코드에 문제가 없더라도 추가되었다는 내용은 공유했으면 한다.

 

  이 부분에 대해서는 나도 내가 잘 못한 부분이라고 생각한다. 우리의 개발 환경에서 각자가 공통 함수나 컴포넌트를 만들면 서로 공유하고 가져와서 사용한다. 그런데 사수가 만든 공통 로직은 좀 자주 많이 바뀌었다. 1년 사이에 사수가 만든 Input 공통 컴포넌트만 총 6번 바뀌었다(아예 컴포넌트 이름까지 바뀌어서). 그렇다보니 내 경우에는 원래 있던 것이 사라져서 추가하거나 혹은 기능을 단순히 추가한 경우가 있었다. 예를 들면, 사수가 만든 Input 공통 컴포넌트에 validationFunction 을 props 로 넘겨주어서, 그 함수를 통과하면 HTML 에 표시되고, 통과하지 않으면 표시 자체가 안 되는 (예를 들어 숫자만 입력하게 만들기 위한 로직 같은 것) 코드를 짰다. 그런데 그걸 만들고서 얘기를 하지 않은 경우다.

 

  음... 근데 사실 이 부분에 관련해서는 사수랑 좀 얘기할게 있었다. 많았다. 각자의 사정이 너무 확고한 것 같다. 그래서 이 설문 조사를 받고 사수랑 한 번 터놓고 얘기하는 시간을 가졌다. 그런데 이렇게 얘기할 것이 많다고 하는 것 자체가 우리가 서로 소통을 많이 안했기에 발생하는 문제다. 그리고 실제로도 내가 그렇게 얘기하지 않은 것은 큰 잘못이다. 조금 더 소통을 하려고 노력해야 할 것 같다.

 

 

(4) 일할 때 중요하게 생각하는 것은  " 팀원 간의 커뮤니케이션 "   인 것 같다.

회의에서 본인의 의견을 어필하면서도, 
이의 제기를 받으면 한 발자국 물러나 수용하면서 회의가 올바른 방향으로 갈 수 있도록
회의 분위기를 잘 유지한다.

 

  아 이거는 정말 내가 중요하게 생각하는 것을 사수도 생각하고 있구나 생각했다.

 

  나는 무엇보다 커뮤니케이션을 중요하게 생각한다. 커뮤니케이션이 잘 못 전달되면 프로젝트가 삼천포로 빠지는 경우를 많이 보기도 하고, 감정적으로 상하는 일이나 균열이 발생하면 일할 때 겉잡을 수 없이 커지기 때문에 이 점을 항상 주의한다.

 

  그리고 나는 내가 아직 배우는 입장이라고 생각하기에 누군가 의견을 준다면 경청하고 받아들여야 한다 생각한다. 그렇다고 내 의견을 피력하지 않을 수는 없다. 내 생각은 당당하게 말하되, 대신 그 어떤 반박도 겸허하게 받아들일 자세가 필요하다. 

 

  음... 그런데 이전 협업할 대 더 키워야할 점이 소통이었는데.. 중요하게 생각하는 것도 커뮤니케이션, 소통이니.. 좀 더 분발해야겠다.

  

 

(5) Liebe 에게 하고 싶은 말이 있다면?

개발 부문 뿐만 아니라 회사 전체에서 꼭 필요한 사람이 된 거 같아서 사수로서 뿌듯합니다!
(물론, 본인의 많은 노력이 있어서겠죠?)
앞으로도 지금처럼만 하면 될 것 같습니다 :)

 

  회사 전체에서 꼭 필요한 사람이라... 극찬이 것 같다.

  사실, 저번 설문 조사의 결과에서도 나온 얘기긴 하지만 나는 우리 개발 부문 뿐만 아니라 다른 회사 분들과도 좀 많이 친하긴 하다. 특히 재무팀이랑은 거의 뭐... 명예 재무팀이라는 말도 나올 정도니. 이런 점에서 또 좋게 봐주시는 것 같아 감사하다.