00pen

경쟁력 있는 커리어를 쌓고 있다고 생각되는 이유는 성장하고 변화하는 조직에 있기 때문이라고 생각한다. 그리고 특히나 이런 조직에 있으면서 좋은 경험을 쌓고 있다고 생각하는게, 링크드인에서 아래 글을 보았는데 나는 5번 빼고 모든 경험을 쌓고 있다고 생각하기 때문이다.

경쟁력있는 커리어를 위해 경험해보길 추천하는 업무 포트폴리오

첫번째는 아주 성장이 빠른 기업이나 조직경험. 아주 성장이 빠른 기업이라는 건 증가하는 인원에서 느껴진다. 내가 들어올 때가 딱 증가하는 순간이였던 것 같다. 그러다보니 조직을 리빌딩하기도 하고, 기존 방식으로는 잘 안 굴러가는 문제가 있었던 것 같다. 그러다 보니 만 2년차가 조금 넘은 나에게는 신선한 경험이었다. 조직이 커짐에 따라 기존의 방식이 잘 적용이 안되고, 새로운 규칙 또는 방식을 찾아야 했나보다. "그 때는 맞고, 지금을 틀리다" 같은 느낌. 솔직히 팀이 리빌딩되면서 (기존 맴버가 이탈하기도 하고, 외부에서 인재를 영입하기도 하고, 신입을 많이 뽑기도 하고... 등) 분위기가 어수선한 느낌은 있었지만 그래도 조금 진정되가고 있는 것 같다.
 또, 이번에 들어오신 경험이 많으신 리더 분이 인원이 늘고 성장하는 시기에 팀을 만들어가는지도 옆에서 볼 수 있는 기회인 것 같다.

두번째로는 방법론을 배울 수 있는 조직인 것도 맞는 것 같다. 스타트업이기 때문에 가능한 부분인 것 같은데, 여러 툴들을 적극 활용하려는 분위기 뿐만 아니라 새로운 방법론을 도입해보려는 시도들이 많이 보인다. 기존에서는 노션에서 문서를 정리하면서 프로젝트를 관리하다가 linear라는 툴을 적극 도입해보기도 하고, 서드파티의 데이터 파이프라인, 리포팅 툴을 도입해 여러가지 것들을 자동화하기도 하였다. 무엇보다 동료분들이 대단하다고 느낀 부분은 바뀌는 것에 대한 두려움이 별로 없고, 생각보다 적응하는데 시간이 많이 걸리지도 않았던 부분이다.

세번째 데이터 분석과 AI를 활용하여 업무의 효과, 효율을 높힌 경험은 chatGPT를 써본 경험을 들 수 있을 것 같다. 어떻게 만들지는 아는데 어떤 라이브러리를 써야하나 이런 걸 고민할 때 chatGPT를 쓰면 도움이 된다. 전 직장에서 db에서 데이터를 추출 후 엑셀 파일을 이메일에 첨부하는 코드를 짤 때 chatGPT에게 도움을 받은 적 있다. 이런 식이다. "데이터를 가지고 엑셀 파일을 만드는 python 코드를 짜줘" -> "이메일에 엑셀을 첨부해서 smtp 서버를 통해 보내고 싶은데 코드를 짜줘" 이런 식으로 하면 몇 초만에 짜준다. 근데 중요한 건 돌려보면 안 돌아갈 수도 있다. 저번에 chatGPT가 줬던 코드는 외부 라이브러리에서 method를 하나 잘 못 썼었던 같은데 그런건 에러 보고 바꿔주면 된다. (chatGPT에게 틀렸다고 말해주면 고치는 방법을 알려줄 수도 있다.)

번외로, chatGPT를 쓰면 공부하는데 도움도 많이 된다. 아래 글에서 썼다시피 큰 덩어리를 배울 때 어떤 것부터 배워야하는지 어려울 때가 있는데 선생님에게 질문하듯이 chatGPT에게 질문을 하면 큰 도움을 받을 수 있다.  

2023.01.23 - [Programming] - AWS EC2 instance, AMI, EBS 이해하기

마지막으로 네번째, 자신의 업무가 고객에게 직접 가치를 부여하는 것을 확인할 수 있는 업무 경험도 감사하게도 있었다. 우리팀 PM님이 고객사를 만나고 오면 product에 대한 피드백이나 이런저런 기능이 있으면 좋겠다는 이야기를 공유해주신다. 그럼 이런 부분이 더 보완되어야하구나, 이런저런 기능은 다음에 만들어야겠구나 하는 생각을 한다. 그리고 이런 이야기를 듣다보면 어떤 기능을 개발할 때 작게 쪼개서 보완해나가는 방법을 배워볼 수도 있다. 채팅 기능을 예로 들자면 처음에는 두 사람이 대화하는 것만을 개발하고, 후에 그룹채팅 방을 만든다던지. 처음에는 텍스트만 보낼 수 있는데 이모티콘까지 지원하는 채팅방을 만든다던지... 이런 경험은 좋은 PM님을 만나서 있을 수 있었던 경험 같다.

단 한 가지, E-to-E로 문제를 정의하고 설계하고 해결해본 경험은 없는 것 같다. 사실 db 모델을 설계하고, 개발 완료하고, 모니터링까지 하는 게 E2E 라면 E2E 겠지만은 그걸 안 해본 백엔드 개발자는 거의 없을 것 같아서 제외하고, 비즈니스적인 관점에서 기획~실행까지는 아직 못해본 것 같다. 특히나 개발팀에 있으면 기획 같은건 거의 PM님이 해주셔서 그런 것 같기도 한데 좋은 PM님과 일하면서 나중에는 기획도 어느정도 할 수 있는 개발자가 될 수 있으면 좋겠다.

Intellj에서 새로운 프로젝트를 만들고 main/test 폴더 위에서가 아닌 새로운 패키지를 만드려고 했는데 package, java/kotlin file 만들기가 new 에서 보이지 않았다. 아래처럼 보였다...

분명 package가 별 건 아니고 그냥 폴더일텐데... 폴더로 만들어서 그냥 java나 kotlin파일을 만들어서 돌려보려고 해도 안 먹는다. 사실 안 돌아가는건 말이 안 되고, intellj가 인식을 못한다.

해결방법은 {{ ProjectName }}.iml 이라는 intellj가 만들어주는 파일을 보면 xml형식으로 되어있는데 sourceFolder라는 속성이 있다. 근데 거기가 "file://$MODULE_DIR$/src" 가 아닌 "file://$MODULE_DIR$/src/main" 이런 식으로 되어있을거다. 그러면 src가 root가 아닌 main을 root로 보기 때문에 intellj가 다른 곳에 파일을 인식하지 않는다.

아래처럼 바꾸어 놓으면 다시 보인다!

<sourceFolder url="file://$MODULE_DIR$/src" isTestSource="false" />

파일 indexing을 사용자가 지정할 수 있도록 해놓은 것 같은데... 아무튼 처음 코틀린을 다루어 보려는데 책의 튜토리얼에서 한 시간 정도 헤맸다...ㅋㅋㅋ

난 신기한 걸 읽거나 보고, 그걸 이해하고 싶을 때 많이 찾아보고 공부하게 되는데 이번에는 데브시스터즈에서 장애 회고한 글을 보면서 aws ec2 와 그 외 여러가지들을 배우게 되었다.

https://tech.devsisters.com/posts/crk-launch-storage-postmortem/

위 글에서는 매우 많은 것들이 행해졌고, 내가 알지 못하는 부분이 많았다. 그 중 dd command를 통해 disk를 복사한 후 데이터를 복원하려는 시도를 했다는 것 부분에서 데이터를 snapshoot하는 방식과 그게 aws에서는 어떻게 실행되는지 궁금했고, 거기에 대해 조사, 공부해 보았다. 예전엔 이런 걸 밑바닥부터 공부하기 어려웠는데 요즘에는 chatGPT를 통해 큰 그림을 보고 자세한 건 aws나 그 외에 문서에서 보면 쉽다. 그래서 먼저 내가 지금 쓰고 있는 맥북에서 partition을 어떻게 관리하고 있고, 그걸 어떻게 하면 dd command를 통해 복사할 수 있는지 물어보았다. 자세한 내용은 생략하고, 간단하게 말하자면 diskutil이라는 command를 통해 partition이 어떻게 사용되고 있는지 볼 수 있고, /dev/* 폴더가 그 걸 나타낸다고 말해준다. 그리고 파티션을 복사하고 싶으면 파티션을 만들고, unmount하고 복사하고  source를 destination에 복사를 하라고 한다(dd command를 통해서). 그리고 친절하게도 덮어 씌워질 수 있으니 조심하고, 새로운 이름을 지어달라고 설명해준다.

그럼 이걸 이제 aws에서 어떻게 적용되고 있는지 알기 위해서 AMI, EBS 키워드로 검색을 해보면 여러 글들이 나오는데 아래 참고글 링크를 보면 자세히 설명해주고 있다. 내가 이해한 내용을 쉽게 설명하자면 일반적으로 우리가 ec2 instance를 ami로 복사하는 건 os, bootloader, volume들을 한꺼번에 복사해주는 이미지를 만들어주는거고 거고, ebs는 그중에서 volume(disk 또는 partition으로 이해하면 될 듯) 담당해 주는 것이다. 따라서 ebs에 volume만 복사해주고 싶으면 원하는 ec2 instance에 volume(ebs)를 장착하고 위에서 복사했던 대로 복사하고 detach해주면 된다. 

참고글:https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-AMI-Snapshot-%EA%B0%9C%EB%85%90-%EB%B0%B1%EC%97%85-%EC%82%AC%EC%9A%A9%EB%B2%95-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC

https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-EBS-%EA%B0%9C%EB%85%90-%EC%82%AC%EC%9A%A9%EB%B2%95-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC-EBS-Volume-%EC%B6%94%EA%B0%80%ED%95%98%EA%B8%B0

 PM의 역할은 다른 직무에 비해 꽤 광범위하고, 사람은 강점보다는 약점이 두드러져 보이기 쉽다는 점에서 PM은 참 (좋은 평가받기) 어려운 것 같다. 제품을 같이 만들어 가면서 느꼈던 PM의 역할이 어려운 이유를 적어보려고 한다.

1. 내부에서의 역할도 다양한데 외부도 신경써야 한다.
 내부에서 해내야 할 일도 많은데 타 팀이나 고객들과도 의사소통을 해야한다. 프로젝트 관리를 하다보면 일정이나 인력을 관리해야하는데 그러면 타 팀과 고객들과의 의사소통은 불가피하다. 근데 우리의 팀은 하난데 타 팀이나 고객은 제각각이다. 그래서 케이스 바이 케이스에 갑을 관계에 있으면 더더욱 힘들어 지는 것 같다.

2. B2B와 C2C에서 PM이 고객을 대하는 마인드가 달라져야 하는 것 같다.
 위에서 고객들과도 의사소통을 해야한다고 했는데 일반 소비자(C2C에서의 고객)와 회사(B2B에서의 고객)을 대할 때 마인드가 조금 달라져야 하는 것 같다. 예를 들어 일반 소비자와 니즈를 파악하고, 제품에 반영할 때는 고객 한명 한명의 니즈를 다 반영할 수도 없고, 반영해서도 안 되는 것 같다. 그리고 일반 소비자는 자기가 원하는 걸 정확히 모를 수도 있고, 원하는 것을 해결하기 위해서 근본적인 이유를 찾아야할 때도 있다. 근데 회사를 대할 때는 일반 고객보다는 적기도 하고, 갑을 관계에 있을 수도 있고, 제품을 솔루션처럼 팔 수도 있기 때문에 그 회사만을 위한 커스터마이징이 필요할 수도 있다. 그리고 니즈가 꽤 구체적일 수 있고, 가장 중요하게는 그것을 안 맞춰주면 우리 제품을 안 사용하거나 경쟁사 제품을 사용하려고 할 수 있기 때문이다. 그래서 각각 B2B, C2C사업에서의 PM은 약간 다른 면모를 가지고 있어야 하는 것 같다.

3. 잘한다는 건 사람이 평가하는 거라서 주관적이고 상대적인데 단점이 두드러지기 쉬운 것 같다.
 사람은 완벽할 수 없고, 어떤 역량은 약간 떨어질 수 밖에 없다. 어떤 PM이 완벽에 가까우려면 모든 역량이 평균 이상이여야할 것 같은데 그럼 엄청 난 것 아닐까..? 그래서 제목에 "PM의 역할이 참 어려운 이유"라고 썼지만 정확하게는 "PM이 좋은 평가 받기 어려운 이유"라고 봐야한다.

결론: 아무튼 PM은 어려운 것 같으니까 좋은 점을 보려고 노력하고, 주변에 힘들어 하는 PM이 있다면 응원해주자 :)

 직장 내 디자이너 분과 밥을 먹다가 이런저런 얘기를 나누면서 그 분이 '이런 걸 만들어보고 싶다.' 라는데서 시작했다. 회사에서 개발하다보면 개발 스펙이나 방향에 아쉬움이 남을 때가 있었는데 그런 아쉬움을 해소할 수 있으면서 재미도 있을 것 같아 그 얘기를 가슴에 담아두었다. 나는 백엔드 개발을 하다보니 프론트엔드 개발을 해줄 사람이 필요했고, 마침 잘한다고 생각하는 프론트 개발자분에게 말씀을 드렸더니 좋다고 하셔서 진행하게 되었다.

 나와 프론트엔드 개발자 분은 진짜 사이드 프로젝트처럼 지식을 쌓으려고 시작했다면 디자이너 분은 사업적인 영역까지 생각하고 있었다. 그래서 은근히 진지모드로 진행했고, 오히려 그게 책임감을 갖게해서 진행하는데 도움이 되었던 것 같다. 사실 이제 경력이 막 2년된 내가 잘 할 수 있을지 걱정이 되긴 했지만 분명히 내가 도움이 될 수 있는 부분이 있었다.

특히 이 프로젝트의 성공을 떠나서 나중을 위해서 디자이너분과 프론트엔드 개발자 분에게 다른 방면으로도 도움을 줄 수 있을 거라고 생각했다. 협업을 하면서 백엔드 개발이 어떤 거고, 백엔드 개발자가 어떤 생각을 하는지 알려드릴 수 있는 기회라고 생각했다. 두 분은 실력적으로나 다른 면으로나 신뢰할 수 있는 사람이라고 생각했고, 이번 프로젝트가 아니더라도 다른 멋진 프로젝트를 할 수 있는 분들이라고 생각했다. 그래서 가비아에서 aws에 도메인을 어떻게 연결하는지, 서버를 어떻게 구성하려는지 디자이너 분께 설명드렸다. 그리고 프론트엔드 개발자 분은 백엔드의 어느정도 지식이 있고, 프론트 개발자지만 백엔드 관련한 지식이 충분하다고 생각했기 때문에 로컬에서 spring application을 올릴 수 있도록 설치해주면서 가끔 spring security를 만지면서 이런 걸 넣으면 이렇게 변하더라 라는걸 말씀드렸다. 회사에서 vue.js를 이용해 백오피스를 만들어보면서 얕은 지식이지만 프론트 관련 지식을 쌓은게 프론트엔드 분들과 협업할 때 많이 도움이 되었던 것처럼 이런 게 추후에 내가 아니더라도 다른 분들과 협업할 때 도움이 될 것이라고 생각했기 때문이다.

며칠 전에 다행히 public하게 모든 걸 띄워놓는 것까지 완성할 수 있었다.
서비스는 이제 시작이지만, 처음부터 끝까지 서버를 만들면서 front 배포할 때는 어떤 것들을 고려하면 좋을지도 많이 고민할 수 있었고, spring에서 유용하게 쓰이는 패턴들을 익히고, 사내에서도 조금씩 적용하는 등 많은 것을 배울 수 있어서 좋은 경험이었다. aws 비용을 줄이기 위해 처음에 ec2 한 대로 front, back 서버를 같이 띄우고, 배포할 때도 green-blue 전략을 채택하지 않고 기존 container를 stop & remove하고, 새로 올리는 방식을 채택하기도 했다. 그리고 처음 live에 홈페이지를 띄울 때 nginx 설정 관련해서 우여곡절도 있어서 이와 관련해서는 나중에 시간나면 다른 포스팅으로 기록해 놓으려고 한다.