토종 한국인🇰🇷 개발자의 외국 회사에서의 우당탕탕 1년 회고 🤯

입사를 한 지 어느덧 일년 차가 되었다.

일년 단위가 아니면 어느 단위로 회고를 하겠는가 🥹 
취업을 했던 1년 전부터 지금까지를 돌이켜보며 개발자로서 어떤 고민과 성장이 있었는지를 정리해보았다.

 

첫 취업과 코흘리개 신입 개발자의 고군분투 

취준을 하던 시기에는, 유저가 실제로 존재하는 서비스에 기여하는 것에 대한 갈망이 있었다.

그렇게 취업을 했을 때는 개발로 진짜 세상에 영향을 끼치는 '일'이라는 걸 할 수 있음에 설렜다.

 

좋은 점을 우선 이야기하자면, 한 회사에서 개발자로 일하면서 어느 순간 개발이라는 일이 정말 재미있다는 것을 깨달았다.

코드 치는 게 재미있었다기보다는, 티켓을 받고, 문제의 원인을 찾고, 어떤 액션을 통해 문제를 해결할 수 있을 지 파악하고, 실제로 해결하여 나의 온전한 노력으로 끝까지 결과를 이끌어내는 과정이 재미있었다. 한국인의 긍지를 보여주마! 이런 느낌 .. 그 과정에서 우리 팀의 백그라운드를 이해하고 도메인 지식을 넓혀가는 감각도 좋았다. 

개발이 재미있다는 깨달음은 상당히 큰 소득이다. 개발자라는 나의 첫 직업에 대한 자신이 생기고 앞으로도 이 직업으로 먹고 살기 위해 투자해도 되는 근거가 된다.

 

하지만 회사 일은 당연하게도 재미있는 일만 있지는 않았다. 내가 이걸 해결할 수 있을까 의문이 들 정도로의 어려움을 경험하기도 했다.

가장 크게 느낀 어려움은 커뮤니케이션이었다.

팀원들과의 디스커션에 적극적으로 참여하지 못하는 상황이 특히 힘들었다. 나에게 이게 유독 힘들었던 건 물론 언어 차이의 문제도 있다. 초반에는 아예 언어적인 장벽 때문에 알아듣지 못하는 대화가 있었고, 무언가 말하고 싶은게 있더라도 한 문장을 제대로 완성하지 못해 자신감이 많이 떨어졌다. 한 마디도 꺼내지 못하고 디스커션이 종료되는 상황이 적지 않았다.

그러나 팀과의 대화에서 위축되었던 이유는 비단 언어 문제 때문만은 아니었다. 이는 무엇보다 타인의 시선에서 나를 평가하는 습관에서 비롯되었다고 생각한다. 질문을 하기 전에 많이 고민하고, 혹시 틀린 질문일까 고민한다. 일을 하는 과정에서 무언가 잘 안되는 모습을 보여주기보다는 혼자 잘 해결해서 완성된 결과를 보여주고 싶어한다. 즉, 의견을 내거나 상황을 공유하여 평가받는 것보다는 맡은 일을 성실히 수행하는 편을 선택했다. 

시간이 지나면서 내 습관이 나의 성장을 얼마나 저해하고 있는지 느끼게 되었다. 내가 모든 걸 다 혼자 해결할 수 있는 능력자가 아닌 이상 나의 상황을 더 많이 공유하고 더 많이 질문하고 더 많이 소통하는 것이 나에게 도움이 된다는 사실을 깨달았다.

 

이걸 깨달았다고 해서 문화, 교육으로부터 오랜 시간 축적되어 온 습관이 금방 변하지는 않았다. 컴포트 존이 상당히 견고해서 한 발 밖으로 나가볼 때마다 낙담하고 다시 숨기 마련이었다. 그래서 이게 과연 해결되는 문제가 맞을까 의문이 들기도 했다. 

 

하지만 최근의 나의 모습을 보면 꽤 자신감이 붙었고 회의에서의 참여도 주저하지 않는 나의 모습을 볼 수 있었다.

이는 영어 실력이 조금 상승한 덕분도 있고, 팀원들과 안면을 트며 친밀감을 가진 덕분도 있고, 시간이 지나 뻔뻔함이 상승한 덕분도 있다.

무엇보다도 도움이 되었던 건 두렵더라도 조금씩 시도해보며, 제대로 된 이야기를 하지 않더라도 괜찮다는 걸 스스로 학습한 부분이다. 긴장되더라도 한 마디씩 더 얹었던 경험이 당시에는 좌절감을 주는 것 같았지만 알게 모르게 자신감이 쌓이는 요인이 되었나보다.

 

하라는 거 성실히 잘하는 것도 중요하지만 나의 상황을 적극적으로 공유하고 질문하며 소통하는 것이 필요함을 깨달을 수 있었다.

앞으로도 잘 말해야한다는, 틀리지 않아야한다는 부담감을 내려놓고 일단 말해보자.

 

커뮤니케이션을 잘하는 방법에 대해

좋다! 언어의 차이를 극복하고 습관을 극복해서 무언가 말을 하기 위한 마음의 벽을 허물었다고 하자.

하지만 아직 신생아 걸음마 수준임을 느끼고 있다.

 

문제를 조사하면서 얻은 지식을 정리하고 팀과 공유하여 토론을 이끌어내는 것은 상당한 스킬이 필요하다. 이렇게 생각한 이유는 다음과 같다. 

• 질문을 하는 것도 결국에는 상황을 입체적으로 보며 창의적인 사고를 할 때 자연스럽게 떠오르는 것이다.
• 그리고 상대방이 이해하기 쉽게 설명하고 매끄럽게 대화가 이어지도록 하는 것도 아직 어렵다.
• 도메인 지식이 충분하고 서비스가 어떻게 돌아가는 지 잘 알고 있어야 풍부한 대화가 가능하다.

결국에 커뮤니케이션은 '창의성'과 '도메인 지식'과 '대화 능력'이 어우러진 아름다운 결과물이라고 정의 내렸다. 

커뮤니케이션을 '하는 것'까지는 성공했으니 '잘 하는 방법'에 대해 배워갈 차례이다. 내가 나름 내린 액션 플랜은 다음과 같다. 

• 창의성을 키우기 위해서는 당연한 것에 의문을 가지고 질문해야한다.
• 도메인 지식을 키우기 위해서는 우선 주어진 티켓에 열심히 임한다.
• 대화 능력을 키우기 위해서는 내가 하고자 하는 말을 들을 상대방 입장을 생각하고 이해 가능하게 말하도록 노력한다.

요즘은 창의성이 가장 중요한 부분이라 생각하면서도 가장 어렵다.

문제를 다각도로 보거나, 문제를 문제라고 인식하거나, 솔루션에 의문을 가지는 등의 액션이 창의성의 결과라고 생각한다. 창의적인 사람은 몸에 배여있는 '의문 제동 장치'가 있는 것 같다. 왜? 라는 물음을 습관적으로 던지고 그걸 입 밖으로 내뱉으며 사람들로 하여금 한번 더 고민하게 한다. 그런 커뮤니케이션 스킬이 현재 나에게 가장 부족한 것 같으면서 가장 필요하다고 느낀다.

아직은 좀 어렵다. 창의적인 사람들이 모여있는 여기서 어깨 너머로 많이 배우기를 바라는 마음이다.

 

오너십이란? 개발자가 프로덕트에 오너십을 갖는 방법에 대해

우테코 때의 팀 프로젝트 경험을 통해 개발자로서 '사용자 가치'를 신경쓰며 개발하는 게 중요하다고 생각하게 되었다. 

내가 만드는 프로덕트의 영향을 고려하며 개발한다는 것인데, 이렇게 오너십이 있을 수록 더 재미있게 일할 수 있고, 더 성장할 수 있다는 것을 알게 되었기 때문이다. 당시 팀 프로젝트는 기획 단계부터 개발, 배포, 운영까지 책임지니 오너십을 가지기 쉬운 환경이라 사용자 가치를 고려하는게 당연하고 또 중요하다고 생각했다.

 

하지만 회사에서 일하는 건 팀 프로젝트와 달랐다. 

기획 / 디자인에 관여할 수 있는 범위가 줄어들고, 프로덕트가 크고 여기저기 연결되어있는 곳이 많고, 매니저와 PM 레벨에서 주로 필요한 내용이 정해져서 내려오니 개발자는 개발만 하면 되는 일이었다.

회사 일 적응하고 받은 티켓을 처리하는 데만 시간을 쏟다보니 처음 6개월 정도는 오너십이라는 건 생각도 못했다. 그러다 어느 순간 가벼운 매너리즘에 빠진 적이 있다. 뭔가 능동적으로 일한다는 느낌보다는 기계적으로 주어진 솔루션을 개발만 하고 있다는 생각이 들어서이다.

취준 시기에 그렇게 중요하다고 여긴 '사용자 가치'는 저 멀리 멀어져있고 수동적으로 일하고 있다는 생각을 했다.

 

처음에는 회사의 구조, 일하는 방식이 문제라고 생각했다. 스타트업이 일하는 방식처럼 기획 단계에도 참여하고, 정해진 문제를 푸는 게 아니라 유저와 가까운 거리에서 직접 문제를 찾을 수 있다면 능동적으로 일할 수 있을 거라고 생각했다. 하지만 매니저나 PM 급이 아닌 이상 기획에 참여하기는 제한적이었고 이러한 환경에서도 주도성을 발휘할 수 있는 방법을 찾지 못해 헤맸다.

 

하지만 환경 탓도 잠시, 개발자로서 어떻게 하면 능동적으로 일할 수 있을지 알 수 있었다. 새로 팀에 들어온 팀원이 보여준 능동적인 태도 덕분이다. 소프트 스킬이 좋으시고 공유하는 것에 토론에 참여하는 것에 능숙하신 그 분은 누가 시키지 않아도 팀 채널의 알람이나 이런 저런 토픽을 먼저 조사하시며 적극적으로 임하셨다.

 

그 분을 관찰하며 이렇게 자신의 영역을 벗어나 다른 부분에도 호기심을 가지고 찾아보고 개선점을 찾는 등 주도적으로 일할 때 기술적인 도전을 할 기회를 더 얻게 되고, 더 성장할 수 있음을 알게 되었다. 

그 분을 내가 '능동적인 사람'이라고 평가할 수 있었던 것도 결국 그 분이 혼자 찾아본 게 아니라 꾸준히 잘 공유를 하셨기 때문이다. 공유를 하시며 문제에 대한 토론이 진행됨에 따라 팀 전체의 이해도를 높이는 계기가 된다.

자신이 맡은 티켓에 대한 부분에서도 해당 문제가 정말 문제인지, 이 기능이 왜 필요한 지, 더 좋은 방법은 없는 지 등등 다양한 관점에서 제안하거나 의문을 제기해볼 수 있다.

 

능동적으로 일하는 방법은 세 가지 단계로 정리할 수 있다.

• 인풋 채우기 : 문제를 찾고 정의하고 조사하고 솔루션을 생각해보고 어떤 게 좋은 솔루션일 지 고민한다. 당연해 보여도 질문하는 사고를 가지고 창의적으로 문제를 바라본다. 엣지 케이스를 미리 찾아본다.
• 아웃풋 내기 : 조사한 것을 팀이 이해하기 쉽게 정리하여 공유하면서 디스커션이 필요한 부분을 제기한다. 디스커션에 참여하며 질문을 던지고 의견을 요청하고 나의 생각을 제안한다. 
• 잘 마무리하기 : 디스커션의 결론을 실행하고 스테이징에서 테스트한다. 팀에 공유하여 피드백을 받는다. 배포 후 프로덕션에서 테스트한다. 배포가 마무리되었다고 공유한다.

가장 이상적인 방식의 일하는 방법을 정리해보았다.

현실적으로는 이 모든 걸 다 신경쓰며 일하기 어렵겠지만 깨달은 바를 열심히 실천해나가다보면 조금씩은 좋은 방향으로 발전할 수 있을 것이다. 아잣

 

 

AI 시대에서 살아남는 개발자란!

취업 직후부터 점점 현업에 AI가 들어오기 시작하면서 개발자들의 일하는 방식을 많이 바꾸어놓았다.

개발자가 코딩하는 시대가 끝났다는 말이 정말 현실이 되었고 하드 스킬보다는 소프트 스킬이 더 중요해짐을 느끼는 요즘이다. 

앞서 내가 더 발전해야한다고 생각했던 부분들도 개발 능력보다는 대부분 소프트 스킬에 대해서이다. 

 

나는 다음과 같은 능력들이 더 중요해질 것이라고 생각한다.

• 문제를 발견하고 제기하는 능력
• 다양한 해결책을 비교하고 토론하는 능력
• 테스트하고 검증하는 능력
• 의문을 가지고 깊이 파고드는 능력
• 리스크를 미리 보고 공유하는 능력
• 소통을 통해 결과를 만들어내는 능력
• 문제를 끝까지 해결하려는 집요함

프로덕트와 사용자의 커넥션은 앞으로도 계속, 혹은 더 많아질 것이다. AI 가 생기면서 풀 수 있는 문제가 많아지기 때문에, 사람들은 더 편리함을 원할 것이라 생각한다. 

그래서 프로덕트의 주인은 항상 필요할 것이다. 프로덕트를 개발하고 유지보수하며 세상과의 커넥션을 위해 노력하는 사람은 필요하다. 

내 시간과 노력이 프로덕트에 기여하는 데 도움이 되는 상태를 유지하기 위해서는 결국 프로덕트에 주인 의식을 가져야 한다. 주인이 아닌 도구가 된다면 대체되기 쉽기 때문이다. 

 

앞으로 해야할 것은 지표나 로그를 하나라도 더 보면서 모니터링하고, 엣지 케이스를 확인하고, 회의나 대화에서 한 문장이라도 더 말하면서 팀 내에서 능동적으로 일하는 태도를 배우고 갖추는 것이다. 

 

최근에는 사이드 프로젝트를 하나 시작해서 주변 사람들이 사용하는 서비스를 만들었다.

직접 만든 서비스이고 다른 사람들이 실제로 사용하고 있으니 자연스럽게 주인 의식을 가지게 되고 재미있게 개발하게 된다.

이렇게 현업에서도 조금 더 '내 서비스'라는 걸 인지하고 더 주도성을 발휘할 수 있다면 좋겠다. 

 

다음 1년도 화이팅!