~ 4월

올 상반기 대부분은 작년 하반기부터 투입되어있던 프로젝트에서 시간을 보냈습니다.

아쉬운 점이 참 많았는데 그 중 일하는 방식에 대한 부분이 가장 아쉬웠던 것 같습니다.

저는 평소 '구현할 수 없다'는 말을 쓰지 않으려고 하는데요.
실제로 제가 만드는 프로덕트에 구현할 수 없을 정도로 신박하게 복잡하거나 고도화된 기능이 없기도 하거니와, 대부분 '구현은 할 수 있는데 비용(인력/시간/돈)이 많이 들어요'나 '구현을 할 수 있는지 검토하려면 비용이 많이 들어요' 가 더 정확하고 책임감있는 표현이라고 생각하기 때문입니다.

하지만 안타깝게도 처음에는 고객이 '비용이 얼마가 들어도 좋으니 구현 또는 검토해주세요' 라고 했다가 결국에는 'N월 N일 전에 반드시 되어야합니다' 또는 '현재 개발인력 내에서 반드시 되어야합니다' 또는 '추가 라이센스 비용 없이 반드시 되어야합니다' 등등 말을 바꾸는 경험을 여러번 겪다보니
앞뒤 생략하고 '(인력/시간/돈 그 어느것도 늘려주지 않을 것을 알고 있으니)구현할 수 없다'가 먼저 나오게 되는 것 같습니다.
개발팀의 사기도 떨어지고 고객의 신뢰도 떨어지니 프로젝트의 분위기가 점점 더 안좋아지는 것은 당연한 수순이겠죠.

투입된 시점에 이미 이런 분위기가 있었고, 저도 별 다른 노력 없이 그냥 분위기에 맞춰서 소극적으로 일했습니다. 시간이 좀 지나서야 적극적으로 일하기 시작했지만 역부족이었던 것 같구요.

나에게 이 판의 분위기를 바꿀만한 리더십과 커뮤니케이션 능력이 있었으면 조금 괜찮았을까 아쉬운 프로젝트였습니다. 다음엔 잘할 수 있을까요?

5월

안식휴가를 다녀왔습니다. 입사한지 5년이 넘었다니 흑흑

6월 ~

새 프로젝트에 투입되었습니다. 인원이 많은 프로젝트라 두근두근 했던 것 같아요. 느낀점도 많구요. 나열해보자면...

• 개발자 입장에서 스토리에 좁게 몰입하다보면 스스로 도출해낸 해결방법 두세가지가 나름 막상막하 처럼 보여서 고민이 길어지곤 하는데요. 리뷰어 입장에서 보면 생각보다 그 중 가장 합리적인 한 개가 눈에 확 띄더라구요. 쓸데없는 고민을 했던거죠 ㅋㅋ 의도적으로 한발 물러서서 고민하는 습관을 들여야겠다는 생각을 했습니다.
• SA 입장에서 개발자가 자유롭게 정할 수 있도록 풀어줘야하는 영역과 규칙을 정해 제한해야하는 영역을 명확히 하기가 굉장히 어렵다는 생각을 했습니다. 자유도를 높이면 개발자가 스토리를 이상하게 해석하는 경우가 생겨버리고 (뒷처리는 덤...ㅜㅜ), 제한을 높이면 리뷰가 저의 주 업무가 되어버림 + 스토리에 deep dive 해서 떠올려낼 수 있는 아이디어나 구멍을 놓치게 됨 + 개발자들의 불만 증폭 등등 추가적인 문제가 또 생기니 어느 쪽도 정답이라고 할 수 없겠더라구요. 적당한 선에서 개발자들의 성향을 봐가며 해야하는데... 아직 많이 부족한 것 같습니다.
• 협상 스킬이 중요하다는 생각을 했습니다. 욕을 먹지 않으면서 일을 덜 할 수도 있고, 욕을 먹으면서 일을 더 할 수도 있다는거!
• 개발자들의 성향은 참 다양하고, 나만 저 개발자를 그렇게 생각하는게 아니고, 내가 느낀 분위기를 다들 느끼고 있고, 역시 사람하고 하는 일은 관계와 분위기가 중요하다는 생각을 했습니다.
• 스트레스가 높아지면 기억력 & 꼼꼼함이 급격히 감퇴하는 것을 몸소 체험했습니다. 오래 잘 일하기 위해서는 정말 정신건강이 중요한 것 같아요.
• 아직 프론트엔드, 백엔드 어느쪽에서도 특출난 전문가가 되지 못한 것 같습니다. 분발해야겠습니다.
• ERD 설계 능력이 조금 늘어난 것 같습니다. 테이블을 어떻게 설계하냐에 따라서 무한히 확장할 수도 있고, 요건 하나만 바뀌어도 대응을 못하게 될 수도 있다는 점도 느꼈고요. 또 Spring이다 React다 프레임워크/라이브러리 공부만 했는데 SQL이 정말 중요하다는 것도 느꼈습니다. 기본적인 성능은 SQL을 잘 짜는것부터..
• 새로 만나는 모든 분에게는 배울 점이 한 개씩은 있는 것 같습니다! 많이 배웠습니다.
• 뭐든지 내가 내 언어로 설명할 수 있을 정도로 이해를 하고 써야 진짜라는 걸 다시 한번 다짐했습니다. 생각보다 이해 못하고 쓰는 사람도 많다는 점도 새삼 느꼈고, 거기에 휩쓸려서 나까지 이해 못하고 쓰는 사람이 되지 않도록 조심해야겠다고 생각했습니다. 더 연차가 쌓여도 모르면 모른다고, 이해 안되었으면 이해 안되었다고 말할거에요.
• 측정 -> 개선 -> 측정 -> 개선 -> .. 여러 번의 테스트를 걸처 성능을 개선해나가는 작업이 정말 어렵다는 것을 느꼈습니다. 테스트를 하는게 어려운게 아니라 그 끈기가요. '이 정도면 되지 않을까요?' 라고 농담으로라도 말하지 않겠다고 다짐했습니다.

11월

회사에서 발표형 시험을 봤습니다. 프로젝트 중간이라 제대로 준비하지 못했는데도 불구하고 참여만으로 느낀점이 많았습니다.

• 저는 발표를 매우 못합니다. ㅋㅋㅋㅋㅋㅋ 🥲
• 나도 모르게 우물 안 개구리가 되어가고 있었던 것 같습니다. 부지런하게 찾아보고, 읽어보고, 써봐야겠습니다. ㅜㅜ
• 개발자에서 아키텍트로 진화하는 과정이 생각보다 심오한 것 같습니다. 개발자가 연차가 쌓이면 자연스럽게 아키텍트가 되는건가 막연히 생각해왔는데 (ㅋㅋ 글로 써놓고 보니 정말 말도 안되는..) 두 롤의 문제 접근방식이 많이 다른 것 같아요.
• '지금 이 구조에서 잘 구현하는 법이 뭘까?' 고민하는게 일상이라 잊고 있었는데, '더 나은 구조는 뭐였을까?' 고민한지가 정말 오래된 것 같아요. 프로젝트마다 짧게는 몇 달, 길게는 몇 년 기간이 길기도 하고 비슷한 인원이 프로젝트 세팅을 하게 되면 기존에 익숙했던 아키텍처를 재활용하는 습관이 들어서 그런걸까요? 색다른 아키텍처를 경험할 기회가 많지 않기 때문에 이런 고민이 더욱 가치 있는 것 같은데 말이죠.

마무리

아직 한 달 남았는데, 올해도 아쉬운 점 가득이네요! 내년에는 올해보다 좀 더 잘할 수 있을것같아요. 화이팅 ✌️