2/21 업무일지+약 1-2달차 배운점 회고

이번 주 목표와 현재까지 배운점

개발에는 매우매우매우... 설계가 중요하다.

개인적인 생각으로는 설계와 문서화가 잘 되어 있을 경우 프로그래밍을 하는데에는 시간이 얼마 안 걸린다고 생각한다.

물론 나는 프로그래밍을 하는데에도 시간이 필요하다^^

아무튼 개발한 프로그램에 대해서 정확하게 요구사항을 정리하고 이해한 후 설계하고 그것들을 잘 정리하는 것이 정말정말정말 중요하다는 생각이 들었고... 아래 글을 읽으면서 코드리뷰..ㄴ ㅓ무 해보고 싶다.. 라는 욕심이 생겼다.

나도 조금 더 천천히 깊게 공부하면서 좋은 프로그램을 만들어 보고 싶다.

그래서 이번 주의 목표는 현재 개발하고 있는 프로그램의 요구사항을 정리하고 설계를 정확하게 이해한 후 요약해서 전혀 모르는 사람도 이해할 수 있도록 만드는 것이다. 그에 따라 일정을 짜고 개발 일정을 대략적으로 산정해보려고 한다.

---

요즘 읽고 있는 글 - 클린 코드 정리본

https://velog.io/@tmdgh0221/%ED%81%B4%EB%A6%B0%EC%BD%94%EB%93%9C-%ED%95%B5%EC%8B%AC-%EC%A0%95%EB%A6%AC

클린코드 1~3장 요약 정리

---

https://okky.kr/article/1159036

OKKY | 나는 지금 다르게 일 하고 있다 (부제: SI - 서비스 기업 이직기)

오늘의 마음에 드는 글

비 전공 프론트엔드 개발자로, 일을 시작한지 1년 반 정도 되는 주니어 개발자입니다.

성장하기 위해

 

끊임없이 고민하기

저는 이러한 환경에 굴복하고 하던 일만 하면서 익숙해지기가 너무 싫었습니다.

물론 산출물만 잘 나오면 그만이라고 생각하고 아무 생각 없이 하려면 할 수 있었지만, 훗날의 자신을 위해 더 좋은 구조를 찾기 위해 개인 시간을 활용해 공부했습니다.

주로 했던 공부 방식은

• 깃헙에서 리액트 관련 오픈소스 뜯어보기
• 리액트 관련 유명한 개발자 레포지토리 살펴보기
• 틈틈이&꾸준히 CS 공부하기

등등이 있었습니다.

지금 생각하면 구조등을 깊이있게 살펴보며 공부하지 못했던 것 같은데, 그럼에도 다른 사람의 코드를 보는 것 자체가 굉장히 많은 공부가 되었습니다. ‘저렇게 짤 수도 있구나' ‘더 좋은 방법이 있구나' 등을 많이 느꼈습니다.

시간배분의 노하우

최대한 외부 요인으로 인한 일정 꼬임이 발생하지 않도록, 일정 자체를 ‘외부의 영향을 받는 일정' - ‘영향을 받지 않는 일정' 으로 나눴습니다.

‘외부의 영향을 받는 일정'을, ‘영향을 받지 않는 일정'으로 만들기 위해서 여러가지 시도를 했습니다.

• Mock api 만들기
• 정의 가능한 인터페이스 최대한 미리 정의하기
• 다양한 기본 UI 컴포넌트 및 재 사용성을 고려해서 비슷한 업무의 생산성 올리기
• 변경 가능성이 높다고 생각되는 기능은 구조를 러프하게(다양한 변경에 대응할 수 있게끔) 잡아두기

이 중에서 특히 mock api 작업과 구조를 러프하게 잡아두는 방법은 추후 시간을 아끼는데 정말로 유용했습니다. 좋은 설계가 개발자의 시간을 얼마나 줄여줄 수 있는지 몸으로 깨닫게 된 계기가 되었습니다.

 

나는 이렇게 일 하게 되었다

 

내가 이직한 회사

기존 회사에 불만이 없지는 않았지만, 이직을 마음먹을 정도는 아니었습니다.

그러던 중, 우연히 한 서비스 기업에서 제 블로그를 보고 관심이 생겨 간단한 티타임을 갖고 싶다고 연락이 왔습니다. 개발팀과 이야기를 나눠보니 더 재미있게 일을 할 수 있을 것 같았고, 함께 일 하면서 더 큰 성장을 할 수 있을거라는 확신이 생겨 이직하게 되었습니다.

물론 처우도 훨씬 좋아졌습니다. 약 40%정도 인상이 있었네요

 

서비스 기업에서 중요한 것

구조에 대한 끊임없는 고민

서비스 기업은 아무래도 소프트웨어의 수명주기가 SI 프로젝트와는 달리 길다보니, 유지보수와 확장성이 더욱 중요하게 여겨졌습니다.

서비스 기업에서 일을 시작하면서 본격적으로 OOP에 대해 다시 공부하고, 더 나은 소프트웨어가 무엇인지 진지하게 고민하게 되었습니다. 신기하게도 ‘객체지향의 사실과 오해' 라는 책을 1년 전에 읽었는데, 그 때 뜬구름 잡는 듯 느껴졌던 이야기들이 지금 다시 읽으니 머릿속에서 코드로 변환되어서 읽히는 신기한 경험을 했습니다.

한 프로젝트에 연관된 동료 개발자들이 아무래도 SI 시절보다 많아지다 보니, 협업에 있어 고려해야 할 점이 많아졌습니다.

PR을 통해 코드 리뷰를 진행하고, 모든 코멘트가 resolve 되어야 해당 브랜치가 머지 가능한 절차가 있었기 때문에, 코드 리뷰를 하는 동료 개발자가 읽기 좋게 가독성도 신경써야 했고, 특히나 컴포넌트 이름(변수명)은 해당 컴포넌트가 해석되는 컨텍스트, 할 수 있는 일과 해야 하는 일을 함축적으로 담고 있는 아주 중요한 것이며, 때문에 매우 신중하게 정해야 한다는 것을 깨달았습니다.

수준 높은 동료들의 코드 리뷰를 받으면서 구조와 설계, 인터페이스에 대해서 전혀 다른 시각을 갖게 된 계기가 되었습니다. (지금도 매 PR 마다 크게 배우고 있습니다)

꼼꼼함과 집요함 //장신 정신

입사한지 얼마 되지 않아, 사용하고 있는 라이브러리 중 하나가 원인인 이슈가 발견되었습니다.

버전 업데이트를 통해 손쉽게 문제 해결이 가능했는데, 이 때 해당 라이브러리의 패치기록을 보고 소스코드 내의 변화까지 한 줄 한 줄 비교해서 영향도를 확인하는 모습을 보고 매우 놀랐습니다. 당연한 것일수 있겠지만 기존 기업에서는 아무도 이렇게 하는 사람이 없었는데, 프로젝트에 영향을 줄 수 있는 요소들에 대해서 정말 꼼꼼하게 검증한다는 생각이 들었습니다.

뿐만 아니라, 버그 등의 이슈가 생겼다면 문제의 원인을 끝까지 파고들어서 파악하고, 재발 방지를 확실하게 하는 경우가 많았습니다. 단순히 ‘안 되네? 이렇게 하면 되니까 이렇게 하자’가 아니라, 문제 해결 이후에도 ‘그건 왜 안 되었던 걸까' 에 대해 끝까지 알아내고 동료들과 공유하는 방식이었습니다. //개발자의 반복 프로세스 '어 이게 되네' or '아 이게 왜 안돼?'를 없애는 감동적인 순간...

역시 커뮤니케이션

커뮤니케이션은 SI 기업, 서비스 기업과 무관하게 개발자에게 가장 중요한 능력 중 하나라는걸 다시 한 번 깨달았습니다. 다만 소통에 있어서 고려해야 할 점이 조금 달랐습니다.

서비스 기업의 경우에는 SI 기업보다는 동료 개발자와 소통을 할 일이 더욱 잦았기 때문에 확실한 워딩이 매우 중요했습니다. 같은 개발자여도 기본적인 지식이나 환경에 대한 차이가 있기 때문에, 사소한 단어의 차이에도 전혀 다른 이해를 하는 경우가 생겼습니다.

그리고 코드 리뷰를 통해 좋은 피드백을 주는 능력과, 동료의 피드백을 이성적으로 수용하는 능력이 필요했습니다.

기존 회사에서 1년동안 받은 코드 피드백의 양보다 이직 후 1달간 받은 코드 피드백이 퀄리티도 높고 양도 더 많았는데, 개인적으로는 돈 주고도 못 살 정말 값진 경험이라는 생각이 들어 동료들에게 정말 감사했습니다.

테스트는 사치일까?

테스트 코드 비용에 대한 고민

개인적으로 테스트와 테스트 코드에 관심이 많아 이전 회사에서도 공부해서 도입해 본 경험이 있었습니다.

회사에서 아무도 테스트 코드를 작성해 본 사람이 없다보니, 어떻게 해야 하는지 잘 몰라 맨 땅에 헤딩 하듯이 작성했던 기억이 납니다. 유닛테스트는 엄두도 못 내고, 정말 중요한 비즈니스 로직에 대해 검증할 수 있는 플로우별 테스트 코드를 작성했습니다.

하지만 테스트 코드 작성에 드는 시간과 비용에 비해 테스트 코드로 얻을 수 있는 효용이 얼마나 되는지에 대해 의구심이 항상 있었습니다. 테스트 코드 작성이 너무 어려웠고 그 때문에 시간이 오래 걸렸기 때문입니다.

하지만 사실 테스트 코드 작성이 어려운 이유는, 테스트 대상이 되는 코드 자체에 문제가 있었기 때문이었습니다.

가성비 있는 테스트 코드

서비스 기업, 특히나 테스트 코드를 제대로 고민해서 작성하려는 기업에 와보니, 테스트 코드와 테스트는 서비스 기업에서는 결코 사치가 아니었습니다. 테스트를 작성하면서 기존 코드의 문제점을 알 수 있었을 뿐만 아니라, 테스트가 불가능한 어려운 코드는 좋은 코드가 아니라는 원칙하에 컴포넌트간의 역할과 책임에 대해 좀 더 깊이 이해하게 되었습니다.

일을 시작하기 전에 테스트 describe를 통해 명세를 명확히 정의하고 시작할 수 있어 작업의 모호함이 줄어들었고, 무엇보다 테스트를 잘 짜 놓으니 리팩토링 및 기능 변경시에 두려움이 없어지게 되었습니다.

리팩토링을 진행하고 영향도를 체크하는데 부담이 적어지니, 검증에 필요한 시간이 줄어들면서 자연스럽게 개발 속도도 빨라지게 되었습니다.

앞으로도 성장하기 위해

끊임없는 공부

이전 회사에서 ‘끊임없는 고민’을 통해 성장했다면, 지금 회사에서는 ‘끊임없는 공부'를 해야 한다는 생각이 듭니다.

물론 스스로 하는 고민은 앞으로도 계속 중요하지만, 결국 누군가가 더 깊은 고민을 통해 체득한 선험적인 지식은 그 양과 질이 스스로의 고민보다 뛰어나기 마련입니다.

즉, 책을 많이 읽겠다는 다짐입니다.

기존에 개발 서적을 잘 읽지 않았던 이유중 하나는 읽어도 뜬구름 잡는 추상적인 말로 느껴지면서 소화가 어려웠기 때문인데, 얼마 전 개발 서적들을 읽으면서 이제는 어느 정도 소화가 가능하겠다는 확신이 생겼습니다.

사놓고 미뤄두던 서적들, 그리고 프론트엔드 팀에서 추천하는 서적들을 읽으면서 최대한 제 것으로 소화해 보려고 합니다.

동료들과 자극 주고받기

이전 회사에서도 좋은 동료분들이 많았지만, 지금 회사에서는 정말 수준 높은 동료들이 양질의 피드백을 아낌없이 주는 덕분에 개발자로 성장하는데 그 어느때보다 가속이 붙은 기분입니다.

개발팀에서 주기적으로 진행하는 세미나 역시 양질의 퀄리티로 진행이 되고 있어 들으면서도 배우는 부분이 많고, 제 스스로도 세미나를 준비하는 과정에서 배우는 것도 정말 많습니다.

이렇게 좋은 자극을 통해 성장하게 되니 자연스럽게 저도 동료들에게 좋은 자극을 줄 수 있는, 서로 성장하는 관계가 되고 싶은 생각이 듭니다. 또 이러한 생각 덕분에 개인 시간에 공부를 더욱 열심히 할 수 있게 되었습니다.

앞으로도 동료들에게 부끄럽지 않은 개발자가 되기 위해 꾸준히 노력하려고 합니다.

마치며

경험담을 적으려고 시작했던 글이, 뭔가 막연한 다짐으로 마무리되는 것 같습니다.

짧은 제 경험에 비추어 볼 때, 첫 취직을 하시는 분들이 SI 기업이라고 무작정 두려워하거나 경원시 하지 않아도 된다고 생각합니다. 저는 서비스 기업으로 이직 후 매우 만족하고 있지만, 이전 직장에서 열심히 하지 않았다면 지금 회사에 오기 힘들었을 것이라고 생각합니다. 실제로 이직 후 온보딩 프로젝트를 하고 피드백을 받으면서, 이전 직장에서의 노력이 결코 헛되지 않았다는 사실을 깨닫고 매우 기뻤습니다.

제가 했던 방법이나 경험이 결코 정답은 아니지만, 이 글을 읽는 분들 중에서 제 글을 읽고 작은 아이디어나 약간의 자극이라도 얻는다면 정말 뿌듯할 것 같습니다.

---

https://engineering.linecorp.com/ko/blog/machine-learning-engineer-interview/

LINE 머신 러닝 엔지니어 임준석 님을 만나보았습니다 - LINE ENGINEERING

 

---

“러시아의 우크라이나에 대한 사이버 공격은 2009년과 2011년에 북한이 우리나라 국방 및 금융 사이트들에 자행했던 사이버 공격과 매우 유사한 양상”이라고 밝혔다. 또 다른 보안전문가는 “러시아가 사이버 전쟁에서의 일방적인 우위를 바탕으로 침공 시점을 조율하고 있는 것으로 보인다”며 “우리나라도 북한의 대규모 사이버테러를 경험한 적이 있는 만큼 사이버전에 항시 대비할 수 있는 전력과 전략을 동시에 갖춰야 한다”고 당부했다.

https://www.boannews.com/media/view.asp?idx=104908 

러시아-우크라이나 전쟁 초읽기? 사이버상은 이미 대규모 해킹 공습중

 

4억..?

구인구직 네트워크 사이트인 래더즈(Ladders)의 CEO 마크 세네델라(Marc Cenedella)는 “IT 분야 인재들을 둔 영입 전쟁이 살벌하다”고 말한다. “기업들은 아낌없이 투자하고 있어요. IT 기술을 가지고 새로운 뭔가를 할 수 있는 사람을 비싼 값에 사들이죠. 적어도 이런 흐름이 2~3년은 더 갈 것이라고 봅니다.”

세네델라는 “모든 기업이 개발자를 찾는데, 지금 시장에 나와 있는 개발자가 없고, 앞으로도 그리 풍족한 수의 개발자가 확보되지 않을 것”이라고 말한다. “그러다 보니 IT 기술을 가진 전문가들은 현재 있는 곳에서 안정감을 누린다거나 정착하려고 애쓰지 않습니다. 한 곳에 입사하더라도 더 좋은 기회가 없는지 계속 구인구직 시장을 엿보죠.”

아마존은 왜 최저 연봉을 높였을까?
세네델라는 “아마존의 연봉 인상이 그리 놀라울 것이 없는 결정”이라고 말한다. “아마존의 개발자라는 타이틀에 비해 최저 연봉 16만 달러라는 건 애초에 너무 낮았죠. 구글이나 마이크로소프트, 애플과 같은 곳에 비교할 수 없었습니다. 그래서 기술을 보유한 사람이나 경영자나 ‘아마존에서 일한 경력’을 쌓으려면 연봉을 스스로 낮춰야했습니다. 그러니 좋은 사람들은 이력서에 ‘아마존’을 한 줄 넣는데 성공하면 더 높은 연봉을 주는 회사로 떠나기 일쑤였죠. 아마존으로서 적잖은 고민이 되었을 겁니다. 그래서 2배 이상 높인 건데, 그래도 다른 경쟁 기업들과 비교하면 높다고 말하기 힘든 수준입니다.”

그렇기 때문에 아마존이 높였으니 덩달아 IT 업계 연봉이 오를 것으로 보이지 않는다고 세네델라는 예측한다. “아마존은 연봉이라는 측면에서 애초에 그리 귀감이 되거나 모방하고 싶은 회사는 아니었습니다. ‘역시 통 큰 아마존’이라는 반응보다 ‘겨우 그만큼을 이제 올렸냐’는 반응이 더 많은 게 현재 시장의 분위기입니다.”

테크 기업들 간의 인재 영입 혈전
그렇더라도 IT 인재가 필요한 건 마찬가지지만 지갑 사정이 그리 좋지 않은 테크 기업들의 입장은 난감하다. 대기업들이 가뜩이나 IT 시장의 평균 연봉을 크게 올려놓았는데, 아마존마저 따라가기 힘든 금액으로 이 전쟁터에 뛰어들었으니 말이다. 아마 대다수 기업들이 이런 기업들과 경쟁하는 게 말이 되지 않는다며 포기하고 있을 것이다.

테크 리크루팅 기업인 솔텍(Soltech)의 엘렌 존스(Ellen Jones)는 “포춘 500대 기업과 연봉 경쟁을 펼칠 수 있는 기업은 거의 없다고 봐야 한다”고 말한다. “현금으로 경쟁하는 건 말이 안 됩니다. 인재를 영입하려는 중소기업들이라면 현금 외에 줄 수 있는 다른 게 뭐가 있을까 고민해야 합니다. 자율 근무제라든가, 부업을 가능하게 하는 등 다른 기업들이 제공할 수 없는 강력한 대가를 지불할 수 있어야 합니다.”

IT 인재 영입 전쟁이라고 말들을 하긴 하지만, 사실 대부분 시니어급 엔지니어들을 찾아 헤매고 있다. 지금 당장 결과물을 내고 혁신을 이끌어갈 사람들이 필요한 게 기업들의 사정이기 때문이다. 존스는 “연봉으로 경쟁하기 힘든 기업들이라면 눈을 좀 낮춰서 주니어급 엔지니어나 아예 새내기를 찾는 것도 좋은 방법이 될 수 있다”고 말한다. “그렇다는 건 중소기업들은 연봉 대신 훈련의 기회를 제공할 수 있어야 한다는 뜻이 됩니다. 다급한 업무는 잠깐 외주 인력의 손을 빌린다고 하더라도요.”

구인구직 앱 개발사인 하이어시티(Hirect)의 마케팅 국장 스테파니 로벨(Stephanie Lovell)은 “이미 많은 중소기업들이 창의적인 제안을 통해 인재들을 영입하고 있다”고 말한다. “식사를 무료로 제공하기도 하고, 원격 근무자들의 경우에는 식비를 따로 송금하기도 합니다. 심지어 밀키트 구독 서비스를 직원들에게 제공하는 기업도 있습니다. 하루 30달러 정도를 추가로 지출하는 거죠. 밥 편하고 맛있게 먹으면서 일하라고요.”

원격 근무 조건, 생각보다 많은 사람들이 선호한다
연봉을 많이 주는 대기업들은 복리후생도 매우 좋다. 다만 보편적으로 업무 강도가 매우 높은 것도 사실이다. 사람에 따라서는 돈을 좀 적게 받더라도 편하게 일하는 게 훨씬 나은 조건으로 여겨지기도 한다. 중소기업들은 이 점을 파고들 때 꽤나 좋은 승부를 걸 수 있게 된다. 특히, 원격 근무를 넉넉하게 허용할 때 타 기업의 높은 연봉을 두고 심각한 저울질을 할 사람들이 생각보다 많다고 로벨은 설명한다.

“팬데믹 때문에 많은 사람들이 의도치 않게 원격 근무를 경험했습니다. 물론 모든 사람들이 원격 근무를 다 좋아하는 건 아닙니다. 하지만 ‘의외로 집에서 근무하니까 편하고 좋다’는 의견들이 더 많아 보입니다. 심지어 기업들 중에서도 사무 공간 대여료나 사무 용품 절약 등의 장점에 대해서도 인지하기 시작했습니다. 그리고 이걸 아껴서 원격 근무 직원들을 지원하는 방안을 고민하고 있습니다.”

로벨의 경우 최근 이러한 조건으로 아마존에서 근무하던 고연봉 개발자를 영입하는 데 성공하기도 했다고 한다. “그 개발자의 경우 코로나 사태가 아직 온전히 진정되지 않은 시점에 사무실로 돌아오라고 하는 회사의 명령이 너무나 비인간적으로 느껴졌다고 하더군요. 또한 여러 지방에서 출장 근무하는 데에도 지쳐 있었고요. 캘리포니아와도 잘 안 맞았다는 것도 최근 알게 되었습니다.”

글 : 제시카 데이비스(Jessica Davis), IT 칼럼니스트

https://www.boannews.com/media/view.asp?idx=104862 

최저 연봉 35만 달러로 상향한 아마존, 시장에 어떤 파장 일으킬까