이전에 올린 [같이 일하고 싶은 개발자] 주제가 생각보다 관심을 받아서, 같이 일하고 싶은 개발자가 되기 전, 먼저 갖춰야 하는 기본자세에 대해 말해보면 좋겠다 싶더라고요. 이 자세를 먼저 갖추면 팀에 속해 협업할 때도 좋을 거고, 일할 때 주변에서 많은 인사이트를 저절로 얻을 수 있는 팁이 될 수도 있으며, 회사에서 예쁨 받는(?) 개발자가 될 수 있습니다 😆
모르면 모른다고 말하는 자세
정말 간단하면서도 현실에선 쉽게 입이 떨어지지 않죠. 특히 개발자라면 더더욱 입이 안 떨어지는 말이기도 합니다. 왜 우린 "모릅니다!" 라는 간단한 말을 못 하는 걸까요?
- 모른다고 하면 혼날까 봐
- 모른다고 하면 무시당할까 봐
- 자존심 상해서
- 쪽팔려서
- 나름 개발자인데 모른다고 했다가 잘리면 어쩌지?
등등... 여러 가지 이유가 있습니다.
저는 그중에서 [모른다고 하면 혼날까 봐]가 가장 큰 이유였습니다. 실제로 쌩신입 첫 회사 때는 정말 몰라서 혼났습니다 "그걸 모른다고요? 와 은경씨 심각한데..."라는 소리를 들었습니다ㅋㅋㅋ.... 요즘은 신입한테 그런 말하는 사람 몇 없을 거라고 생각합니다. 그래야만 하고요. 왜냐면 신입한테 저런 말해봤자 나중에 그런 말 한 사람도 고생으로 돌아옵니다. 웬만한 신입은 저 말 듣는 순간 멘탈 털리면서 의기소침+주눅이 들어서 나한테 질문도 안 하고 보고도 안하고 말도 안거는 상황이 발생할 테니까요. 그럼 둘 다 고생인 겁니다.
아무튼, 개발자들은 모른다고 말을 쉽사리 못 합니다. 하지만 모르는 건 모른다고 해야 합니다. 그래야지 본인도, 주변 동료들도 덜 고생한다는 겁니다. 모르면 주변에서 알려주려고 하지, 절대로 방치하거나 무시하거나 하지 않을 겁니다 (무시는 장담 못하겠네...ㅎ) 우리는 뭐가 되었든 데드라인에 맞춰 빠르게 개발을 해내, 비즈니스에 성과를 낼 수 있게 해야 하는 개발자들입니다. 물론 기술적인 노력, 견고함, 확장성도 중요하지만 아쉽게도 회사 입장에선 빠른 개발이 가장 우선순위가 높을 겁니다. 이건 아마 스타트업일수록 더 압박이 심할 겁니다. 이럴 땐 모른다는 건 빠르게 모르겠다고 말해 주변 동료들과 함께 현 상황에 대해 빠르게 헤쳐나가는 식으로 해결해야 합니다.
신입일 경우에는 해당 개발건에 대해 당장 떠오르는 솔루션이 없다면 그 자리에서 "방향성을 아예 못 잡겠는데 어떻게 개발하면 되나요?", "래퍼런스 코드가 있나요?" 라고 물어보는게 좋습니다. 만약 떠오르는 솔루션이 있지만 모호하고 잘 모르겠다면 "혹시 이런 식으로 방향성을(개발을) 잡아서 진행하면 될까요?"라고 되물어봅시다. 만약 "엇 저번에 해본 적이 있으니까 이렇게 해보면 될 것 같은데?" 싶으면 개발을 해보시고 1~3시간 이내로 진전이 없다 싶으면 빠르게 주변에게 현 상황을 공유합시다.
주변에 업무진척도를 공유하는 자세
이 자세는 위에 내용과 이어집니다.
- 알겠다고 하고 개발을 진행했으나 하루 반나절동안 진전이 없을 때
- 아는 줄 알았으나 내가 생각한 방법대로 안되고 더 이상 모르는데 하루 반나절이 지났을 때
- 주변 동료든 상사든 "모르는 부분이라도 있을까요?", "어려운 점은 없나요?"란 질문을 들었을 때
- 대충 알 것 같아서 여러 가지 시도해보고 있는데 하루 반나절이 지났을 때
- 문제없이 개발을 진행하고 있으나 작업이 오래 걸릴 것 같을 때
이 외에 더 무수한 경우들이 있지만 대표적으로 몇 가지 뽑아봤습니다. 위와 같은 경우가 나에게 발생했을 경우 팀톡이든, 주변 동료든, 나의 사수에게든 현 상황에 대해 공유를 하시는 게 좋습니다.
여기서 신입 개발자들이 많이 실수하는 게 뭐냐면 먼저 선뜻 공유를 못하는 것도 있지만, 공유를 할 때
- 작업 진행 중입니다
- 개발 중입니다
- 해봐야지 알 것 같아요
라는 식으로만 말한다는 것입니다. 위와 같이 말하면 안 됩니다. 그럼 어떻게 말을 해야지 좋을까요?
- 해당 개발건에 대하여 ~~으로 진행하고 있고, 이 작업은 내일 3시면 마무리가 될 것 같습니다. 마무리되면 그때 다시 한번 더 공유드리겠습니다.
- 현재 개발 진행 중인데, ~~~부분이 어려워 진행에 어려움을 겪고 있습니다.
- ~~~식으로 적용하면 될 줄 알았으나, 지금 막힌 상태입니다.
- 사실 잘 모르겠습니다. 검색하며 해당 래퍼런스를 찾고 있으나 잘 모르겠습니다.
- 현재 ~~~ 개발은 완료된 상태 입니다. 내일은 ~~ 개발에 대해 작업 들어갈 예정입니다.
- 현재 ~~~ 개발 중인데, 이 개발 자체가 좀 오래 걸리는 작업이라서 XX일에 마무리가 될 것 같습니다. 그때 다시 한번 더 공유드리도록 하겠습니다.
위와 같이 대표적으로 몇 개 뽑아봤습니다. 개발을 잘하고 있든, 못 하고 있든, 몰랐든 간에 위와 같이 현 상황에 대해 공유를 하는 게 좋습니다.
저는 전회사 같은 경우 데일리 스크럼이라고 해서 매일 오전에 프로덕트팀이 다 같이 모여 현재 내 업무에 관해 공유하는 회의를 가졌습니다. 이렇게 하면 어디서 작업이 딜레이가 되고 있는지, 해당 사람의 작업이 나에게 어떤 영향을 끼칠지 등등을 파악하고 작업할 수 있겠죠? 단순하게 진행 중입니다라고만 말하는 게 아닌, 구체적인 공유가 중요합니다. 특히 이런 식의 공유는 팀원을 케어해야 하는 팀장과 기획자들에게 매우 좋은 협업의 자세가 되지 않을까 싶습니다.
중요한 건 공유 자체가 늦어지면 안 됩니다. 아예 몰라서 작업 자체가 어렵다고 느껴진 경우에는 그 순간 빠르게 공유해야 하고, 내 작업에 대한 데드라인이 있으나 딜레이가 될 것 같다고 느낀 경우에도 빠르게 공유. 또는 작업 데드라인 하루 전에 현 진행 상황에 대한 공유를 해주는 것도 좋습니다.
대처법도 같이 생각하는 자세
이 자세는 여러 가지 경우가 있을 수 있습니다. 예시로 제가 회사에서 실제로 겪었던 일을 말해볼까 합니다.
전회사에서 유저들에게 수료증을 발급해 주는 기능을 개발하던 중 요구사항이 [모바일에서도 수료증을 볼 수 있고 다운로드할 수 있어야 한다]가 요구사항이었습니다. 그러나, 모바일에서는 특정 크기 이상의 캔버스는 아예 빈페이지가 랜더링 되는 현상이 발생했습니다.( "대부분의 경우 최대 크기가 10,000 x 10,000픽셀을 초과하지만, 특히 iOS 기기는 캔버스 크기를 4,096 x 4,096픽셀로 제한합니다." - 스택오버플로우) 저희는 수료증을 PC 화면에서 보던 사이즈 그대로 모바일 환경에서 보고 싶었거든요. 이걸 어떻게 해결해야 할지 고민하던 중 일단 우리에겐 정해진 데드라인이 있기에 빠르게 이 상황을 공유해야겠다고 생각했습니다. 그때 저는 이렇게 말했습니다
현재 수료증을 모바일(ios 사파리) 환경에서 볼 경우 화면이 빈 페이지로 나오는 현상이 발생하고 있습니다. 원인이 무엇인지는 파악했으나 동일한 조건에선 이걸 해결할 수 있는 방법은 없는 것 같습니다. 그래서 몇 가지 제안을 드려봅니다
1. 모바일에서 수료증 보기는 제한한다
2. 모바일에서는 수료증 보기는 막고, 즉시 다운로드로 변경해 본다
3. 모바일 환경에서는 PC와 동일하게는 불가능하고 작은 이미지 사이즈는 어떤지?
4. 캔버스 렌더링이 문제인 것 같기도 한데, 캔버스로 랜더링 하는 형식 말고 S3에 업로드해서 이미지 URL을 바로 받아서 보여주는 건 어떤지? 이 경우라면 모바일 환경에서도 수료증을 동일하게 볼 수 있을 것 같다
위와 같이 기획자, 디자이너에게 공유를 드렸고, 그 결과 4번째 방향으로 해결을 해보자는 결론이 나왔고, 당시 백엔드의 손길(...)은 필요 없다고 생각해서 프론트인 저 혼자 진행했었으나, S3 업로드를 하려면 백엔드분의 손길이 필요하게 돼서 급하게 리소스 남는 분께서 도움을 주셨습니다. 그리고 백엔드분 일정으로 인해 데드라인을 늘리게 되었습니다.
이처럼 빠르게 현 상황을 공유해야지 다 같이 머리를 싸매고 다른 방법을 고민해 볼 수도 있는 거고, 여기서 단순 "지금 개발에 문제가 생겨서 안될 것 같다. 다른 방법을 찾아보는 건 어떤가요?"라고만 말하는 게 아닌, 개발자 측에서 먼저 다른 대처방안을 생각해 주면 동료들도 함께 생각할 수 있는 범위가 좁아지기에 빠른 결정을 내릴 수 있는 의사소통 방식이라고 생각합니다. (틀에 갇힌다는 좁아짐을 의미하는 게 아닌, 서로 어쩌지? 어쩌지? 하며 방법을 찾아야 하는 소요 시간을 줄일 수 있음을 의미합니다.)
사실 타직군들은 공감할 것 같다는 생각이 듭니다. 개발자가 "안될 것 같은데요?"라고만 말하면 우리 보고 어쩌란 거지?라는 생각이 들 수도 있거든요. 본인의 영역에서 안 됐을 땐 대처 방안도 생각하는 게 본인에게도 좋을 겁니다. 아, 이건 사수가 있다면 이야기가 달라질 수 있겠네요... 왜냐면! 사수가 있다면 사수에게 현 상황을 공유하고 솔루션을 얻을 수 있을 테니까요 ㅎㅎ 저 같은 경우에는 작은 팀이고, 프론트엔드 사수가 없어서 혼자서 헤쳐나가야 하는 팀이었기에 그렇습니다. 제가 못하면 문제인 거거든요. 제가 못하면 아예 기능 개발 자체를 보류해야 할 수도 있는 거라서요. 다른 사람이 나의 일을 도와주기엔 다 같이 주니어이고, 다들 할당받은 업무량이 많기에 도와주긴 힘든 구조라서 그렇습니다.
마무리 (회고)
신입 개발자는 개발 하나 잘하기도 바쁜데, 위와 같은 협업 능력, 커뮤니케이션 능력까지 신경 쓰려니 정신이 없을 수도 있을 겁니다. 그러나, 여기서 실수로 삐끗하면 오랫동안 주변 동료들에게 신뢰도를 얻기 힘들 수도 있습니다. 너무 과하게 생각하는 거 아니야?라고 말씀하실 수 있겠지만, 얼마나 섬세한 공유를 해주느냐에 따라 개발자들의 인상이 달라질 수도 있거든요. "아 이 개발자는 책임감이 있구나", "이렇게 공유를 해주니 신뢰도가 올라가는 기분이야" 이런 반응으로 충분히 이어질 수 있습니다.
저라고 처음부터 잘한 건 아닙니다. 쌩신입때는 가장 첫 번째 자세인 모른다고 말하는 자세부터 잘 못 했거든요. 진짜 모른다고 하면 잘릴까 봐 무서웠고, 혼도 났었어서 엄청 주눅 들어 있었습니다. 근데 여러분들은 주눅 들지 않았으면 좋겠습니다. 차라리 대가리 꽃밭처럼 순수하게 몰라용! 이러는 게 훨씬 나을 수도 있습니다...ㅎㅎ 그다음 회사에 가서는 초반에 "해봐야지 알겠는데..."라는 말도 몇 번 했었습니다 하핫. 근데 이게 시간이 흐르고 난 뒤 얼마나 주변을 답답하게 만드는 소리였는지 깨닫게 되었죠! 처음부터 완벽한 사람은 없지만, 저는 이걸 주변에서 말해주는 사람도 없었습니다~ 이미 혼나고 나서야, 깨지고 나서야 알게 된 거죠. 여러분들은 제가 말해줬으니! 회사에 들어가서 쌈@뽕한 개발자가 되십쇼!
그리고 최근 비사이드 포텐데이 사이드 프로젝트를 하면서도 엄청 크게 느낀 부분이기도 합니다. 프론트엔드 개발자라면 업무가 붕~ 뜨는 짧은 시기가 있는데요. (물밑작업도 끝났고, 디자인과 API가 나와야하는 상황) 이럴때 디자이너와 백엔드 개발자에게 업무 진행 상황에 대해 공유를 못 받으면 좀 답답함이 있습니다. 예를 들어 27일까지 API 개발 완료라고 한다면, 27일 퇴근 1시간 전인데 공유 받은 내용이 없다면 똥줄타죠. 27일이 야근까지 포함한 27일 8시 개발 완료라고 한다면..ㅎ 프론트엔드 개발자에겐 사실상 하루는 결국 대기만 하다가 지나간거고 다음날 개발 시작인겁니다. 이런 경우 미리 백엔드 개발자가 오늘 4시쯤에는 API 알려줄 수 있을 것 같다라는 말을 들으면 답답함과 조급함이 덜하죠... 저도 시간 관리를 어떻게 해야할지 다시한번 생각해볼 수 있고요. 또 하나의 예시로는 프론트 개발자가 먼저 "27일까지 개발 완료라고 하셨는데 혹시 몇 시에 알려주실 수 있나요?"라고 했을 때 백엔드 개발자가 "지금 작업 중이고, 몇 시인지는 저도 해봐야지 알 것 같아요" 이러면.... 저는 이런 경우에 한번 더 되묻긴 해요... "엇 3일 정도 개발하셔서 얼추 마무리 단계일 거라고 생각했는데 혹시 문제 있나요?" 이러긴 합니다만... 보통 본인의 어려움에 대해 잘 말을 안 합니다. 아마 이건 사이드 플젝이라 그런 걸 수도 있고요... 저는 더 이상의 딜레이는 못 참겠다 싶으면 아예 시간을 박아버리기도 합니다. 10시까지 해보고 안될 것 같은지 말씀해주세요. 그때까지 기다리겠습니다라든가... 쨌든 세세한 공유가 이루어졌음 하는 게 개인적인 바램도 큽니다
역시 늘 협업은 힘든 것 같습니다. 저 또한 부족한 게 많고요. 그래도 시간 지나 깨닫는 게 어딘가 싶기도 하네요.
'Work Life' 카테고리의 다른 글
같이 일하고 싶은 개발자란 무엇일까? (0) | 2024.06.15 |
---|---|
프론트엔드 개발자에게 코딩테스트 공부가 필요할까? (0) | 2024.04.11 |
기획은 상상력에서 나오는걸까? (1) | 2024.03.08 |
📝 2022~2023년 회고 (2) | 2024.03.05 |
📝 2020년 회고 (9) | 2021.02.21 |
댓글