개발자가 되기로 하면서 연말마다 매 번 하고 있는 한 가지가 있는데 그 해에 있었던 개발과 관련된 경험을 회고록으로 정리를 하고 있습니다. 가끔 매너리즘에 쌓여서 내가 뭘 위해 개발을 하고 있는건가... 라는 마음이 들때마다 예전에 쓴 것들도 보면서 내가 그 시절 어떤 마인드와 목표랑 이루었던 것들을 보면서 다시금 초심을 다잡게 되는거 같아요. 저도 향로님만큼의 경력과 위치에 오르게 되면 내가 원하든 원치않든 나를 바라보는 사람들이 많아서 부담스럽...겠다 이 생각 들곤 하는데 요샌 이게 내가 겪을 운명이겠구나 받아들일려고 합니다ㅋㅋㅋㅋ.... 늘 건승하십쇼 화이팅!
저희 회사는 반대로 새로운 기술 도입에 유연한 분위기입니다. 덕분에 많은 개발자분들께서 기술 도입에 적극적으로 도입하고 좋은 곳으로 이직을 많이 가더라고요. 결국 유지보수는 도입에 적극적이지 않았던 사람들이 하고 있습니다. 어쩌면 팀원분들의 이직 사유가 새로운 기술도입이라했을때 그말이 사실인지는 검증이 필요할꺼 같아요. 새로운 기술 도입 여부가 아니라 다른 이유일지도..
@@ujty207 적극적인 사람이 이직에 유리한건 동의하나, 새로운 기술을 도입하는 것이 곧 실력이 좋은건가는 잘 모르겠습니다. 새로운 기술을 써보고 싶은건 좋은데, 그게 개인 프로젝트가 아니라 실제 프로덕트라면 유지보수를 어떻게 하는지도 고민이 필요하다 생각됩니다. 그부분이 아쉬웠습니다. 결론은 나도 새로운 기술 도입하고 이력서 한줄 추가해서 런할꼬얌
현재 내가 가진 역량 이상의 일이 요구될 때 누구나 자존감이 부분적으로 위태로워질 수 있는 것 같아요. 그렇지만 나의 부분적 미흡함 때문에 나란 사람 전체에 대한 회의감에 빠지지 않도록 하는게 중요한 것 같습니다. 시니어 역시 이런 고민을 한다는게 저같은 주니어에게는 위로가 돼요. 이겨내실거에요!
저도 비슷한 고민을 하고 있는 것 같아요. 팀 내 여러 개의 마이크로 서비스가 있어요. 각자 담당자들이 달라요. 저는 필수 기술 범위를 제한하고, 개발부터 배포까지 표준을 만들고 싶어합니다. 서비스 담당자 A가 부재중이여도, 아무것도 모르는 개발자 B가 A의 서비스에 접근해서 상태를 점검하고, 로그를 확인하고, 서비스를 재시작 하거나 배포를 할 수 있으려면 우리가 일정한 표준 내에서 개발을 준수해야 가능한 일이거든요. 그래야 서로 마음 놓고 휴가를 가도 전화를 하지 않죠. (
매니징을 하게 되면 책임질 범위가 더 커지는데, 작은 책임의 시절에는 새로운 걸 시도하는 과정에서 문제가 발생해도 내가 해결할 수 있는 영역이라는 안정감을 얻기가 비교적 수월하다고 생각합니다. 그런데 큰 범위, 제가 겪어본 적없는 C레벨의 의사결정 상황이 되면 새로운 시도가 사업의 방향과 잘 맞는지, 충분한 시너지가 있는지, 새로운 것을 시도하는동안 발생하는 비효율의 기간을 어떻게 감당할건지, 문제가 생겼을 때 어떻게 해결할지를 더 큰 단위에서 접근할 것 같아요. 그러면 당연히 보수적인 입장으로 자연스럽게 변화하는거라 생각합니다. 이런 경우에는 새로운 것을 시도하려는 구성원이 더 유리한 입장이라고 생각하는데, 마치 기획자-개발자 관계에 있어서 무엇인가를 새로 구현하자는 사람이 항상 더 잘 준비해서 상대를 설득할 기회가 있기 때문이죠. 의사결정자 입장에서는 본인의 보수성을 반성하는 것도 중요할 수 있지만, 새로운 것을 시도하는 사람에게 이 시도가 불러일으킬 수 있는 다양한 효과를 조명해주고, 더 큰 관점에서 봤을때에 생기는 효과들을 고려했을때도 이 도입이 필요하다고 느끼다면 그 필요를 잘 프레젠테이션해서 공동체가 필요성을 공감하게 하는게 중요하다고 생각합니다. 단순히 리더십으로 휘어잡아 진행시켜, 진행시키지 마. 이런건 실제로는 리더십이라기보단 인사권과 평가권이 강하고 조직 자체가 대체불가능한 편인 (이를테면 회사로서의 구글이나 국내의 네이버 같은 빅테크) 곳에서 직원들이 따르기 더 수월한 다양한 장치들을 마련하고 있기에 그렇게 보이는게 아닐까 싶거든요. 결국 새로운 시도에 열려있다, 닫혀있다는 나의 태도 자체의 문제라기보단 고려해야 할 영역 범위의 변화로 인해 안정성이란 가치에 가점이 매겨진 것이고, 이것을 설득할 수 있는 기회는 새로운 도전을 원하는 사람에게 주어져 있으니 그가 잘 준비해서 가점 이상의 가치를 보여줘야한다.. 이게 정론이라고 생각합니다. 이런 부분이 개인의 발전, 재미, 흥미, 욕망과 충돌하는건 회사라면 당연한 것이지만 어느 정도의 출구를 제시하기 위해서 작은 범위에서의 자율성을 보장하는 것도 도움이 될 것 같고요.
퇴사자를 막을 수 있는 방법은 불가능하다고 생각하시겠지만 예방밖에 없죠.. 근데 예방이 불가능한 부분이라면 박수쳐주며 보내줘야죠뭐.. 예방 가능한 부분은 뭐 잘 고민하실것 같지만.. 여튼 이렇게 방송에서 이야기 할정도로 고민하시는 것 보면 다른건 몰라도 퇴사하시는 세분이 아주 많이 좋은 사람이자 엔지니어였다는 것이 느껴집니다..
User Experience, Voice of Customer의 중요성에 비해 오히려 내부 구성원, 동료의 목소리는 상대적으로 중요하다고 인지 하는 의사 결정권자, 경영자, 리더가 흔치 않죠...! 동료와의 이별이 좀 헛헛하고 섭섭할 수는 있지만 그래도 내가 떠날 때, 내가 조직에서 불편함이 있을 때 내 말을 귀 기울여 들어줄 존재가 있다는 것만으로도 인프랩 동료분들한테 큰 힘이 될거에요...! 화이팅화이팅!
새로운 기술 도입과 관련해 개인적으로 떠올린 부분은, 전체 흐름의 영향을 주지 않는 한에서 모두 같이 합의된 룰이 있으면 자유롭게 테스트를 할 수 있는 스콥(열정적인 주니어의 플레이존)을 정한다면 어떨까요? (예로, 어드민 도구의 특정 부분에서만 적용해보자)
어떤 도구이든 기존의 개념 하에서 개선이 이뤄진 것이 있고, 기존의 개념을 무너뜨리며 사용자에게 새로운 개념으로 사용하게 하는(+개선) 도구가 있다고 생각합니다. 그렇기에 컨택스트에 따라 혁신적인 개선을 만드는 도구와 그저 갈아끼우기가 되는 도구가 있을 것 같습니다. 그렇기에 요는 납득 가능한 도구 변별 및 적용 프로세스를 합리적으로 납득가능한 범위에서 합의해서 만드는 것이라고 생각해보았습니다.
아무래도 실서비스를 하는 스타트업이라 더 그런 고민에 빠지시는게 아닌가 싶습니다. 투자받고 실서비스는 아직 남았으면 뭐든 시도해볼텐데 이미 서비스가 돌아가고 있으면 라이브러리든 스택이든 뭐든 바꾼다는게 리더로서 선뜻 내키지 않는 일이죠. 그러면 서비스가 어느정도 자리잡으면 새로운걸 하고 싶은경우 무조건 이직해야 맞는가? 개발자는 새로운걸 받아들이지 못하면 바로 도태되기에 또 있으라고 강요 할수도 없는 노릇이고 딜레마에 빠지게 되죠. 저는 그래서 MSA 인프라는 기본으로 가져가고 회사내에서도 사이드 프로젝트를 해서 현재 서비스에 크게 영향이 없는 별도의 프로젝트를 규모가 커질수록 해야 한다고 생각 합니다. 그 프로젝트에선 자유롭게 이것저것 해보는것이고 그 스택이나 모듈이 괜찮다면 실서비스에도 리팩토링해서 적용 가능한것이고 그리고 코드 리팩토링이 꼭 같은 프레임웤 라이브러리에서만 한다고 발전 한다고 생각되진 않는것 같습니다. 목수가 새로나온 일자톱만 쓰다가 새로나온 신상전기톱에 적응되기까진 시간이 걸려서 기존제품엔 적용하기가 힘들긴 하지만 적용만 하면 결국 생산력을 폭발적으로 올려주거나 제품의 마감을 높여주니까요.
정말 T적인 생각이라... 글쓰기에 좀 조심스러운데, 개발자분들이 보면 대부분 인문학적 결핍증에 걸린 것 같아서... 무슨 말이냐면 하는 일의 성격이 타직업들에 비해 확실히 하드하다보니까 소프트한 일에 대해서는 상당히 수용적이라는... 그릇이라는 인문학적인 단어가 좀 그 대표적인데... 사람의 그릇이라는 건 뭔가 더 넓은 의미를 가지는데에도 불구하고 특정 일에 갖다붙여셔 생각을 하고, 사실은 그릇이라는 단어 자체가 애매한 단어입니다. 뜻도 모호하고 사람마다 그 뜻에 대해 주관적이라서요. 범죄관련 전과나 그에 준하는 인성을 갖고 있는 것도 아닌데 사람 인성이란건 정상인 범주 안에서는 누구나 다 비슷한거 아니냐? 생각하는 사람도 많아서... 폭행, 직장 내 괴롭힘 등의 범.죄급의 일이 아니라면 복잡하고 다사다난한 사회생활 중에서 딱히 인성이니 그릇이니 하는건 없는것 같습니다... 그냥 사람들의 성향들만 있을뿐... 한국 사회생활 문화에서... 인.성이라는 단어가 근래 많이 대두되는데 뭔가 소승불교에서 나오는 정신수련의 의미보다는 번듯한 사회인이 갖추어야할 소양적인 의미가 강해서... 오히려 인성이라는 사람을 평가하는 새로운 스펙, 잣대를 만들어내서 그걸로 또 사람을 점수화, 평가화 시키는 부작용이 더 크다고 생각합니다 저는...
공감이 안가는... 생태계의 변화라는 건 현재 쓰고 있는 것들에 대한 피드백의 반영이라 할 수 있을텐데요. 이전에 있던 문제는 개선하고, 불필요한 것은 제거하거나 생략하고, 이 두 가지가 모두 기반 아이디어, 그러니까 컨셉 때문이라고 여기면 새로운 기반 아이디어 아래 다시 새 것이 등장하는 식으로 변화하고 있으니까요. 그래서 우리는 이 변화에 대응하지 못하는 상태를 두고 기술 부채가 쌓이고 있다 하고요. 그런데 영상에서 말하듯이 이걸로도 충분히 가능하고, 어떤 것은 선택의 문제일 뿐... 이라 하면 이게 부채를 지겠다는 말 아닐까요? 부정적인 의미에서의 고인다는 방향으로. 툴이나 언어와는 상관 없지만 변화의 수용이라는 점에서는 궤가 같을 것 같은데, 변화의 수용을 사전에 점검하는 UX 엔지니어, 컨셉을 스스로 만들고 거기에 필요한 툴을 가져오거나 생산하는 프론트엔드 시스템 엔지니어라는 직군이 나오는 것에 개발자들이 관심을 가져보는 게 어떠한가 싶네요.
애초에 퇴사자가 생기면 그렇게 생각하시는 게 너무 좋네요. 저희는 퇴사하면 퇴사자 이상한 사람으로 몰아붙이기 바쁘고 안타깝게도 그게 일반적인 거 같더라고요
이게 레알임 조금이라도 약점보이거나 육아등으로 힘들때도 약점캐서 물고뜯고 물고뜯은 사람 평가 빠지는 만큼 자기 평가 올리기 바쁜 인간같지 않은 짐승들도 많음
향로님은 어떤 문제든 척척 잘 해결하실 것 같았는데, 이런 고민을 공유해주셔서 너무 좋은것 같습니다. 생각보다 더 솔직하게 나눠주셔서, 제가 혼자 하던 고민에 대해서도 나만 그런게 아니구나 하고 위로가 된것 같아요. 좋은 영상 감사합니다!
최근에 향로님을 면접장에서 뵀었는데, 그때 나눴던 말들을 떠올리며 영상을 보니 참 느끼는게 많은 것 같습니다. 좋은 영상 감사합니다.
이 문제는 생각보다 복잡하고 중요한 문제 같아요. 직설적으로 말하긴 조심스럽지만, 새 기술에 대한 고민을 우리 업계가 다같이 전반적으로 고민을 더 해봐야 할 거 같아요. 정말 어려운 문제네요.
개발자가 되기로 하면서 연말마다 매 번 하고 있는 한 가지가 있는데
그 해에 있었던 개발과 관련된 경험을 회고록으로 정리를 하고 있습니다.
가끔 매너리즘에 쌓여서 내가 뭘 위해 개발을 하고 있는건가... 라는 마음이 들때마다 예전에 쓴 것들도 보면서 내가 그 시절 어떤 마인드와 목표랑 이루었던 것들을 보면서 다시금 초심을 다잡게 되는거 같아요.
저도 향로님만큼의 경력과 위치에 오르게 되면 내가 원하든 원치않든 나를 바라보는 사람들이 많아서 부담스럽...겠다 이 생각 들곤 하는데 요샌 이게 내가 겪을 운명이겠구나 받아들일려고 합니다ㅋㅋㅋㅋ....
늘 건승하십쇼 화이팅!
향로님 말씀에 많이 공감이 가면서도 호돌맨님 말씀에도 동의가 갑니다 ㅋㅋㅋㅋ 역시 개발 쪽 특히 기술에 관해서는 정답이 없는 것 같네요. 그래도 한 가지 확실한 건 향로님이 이런 고민을 하고 계신다는 것 자체가 이미 좋은 CTO 임을 증명하는 것 같습니다.
저희 회사는 반대로 새로운 기술 도입에 유연한 분위기입니다. 덕분에 많은 개발자분들께서 기술 도입에 적극적으로 도입하고 좋은 곳으로 이직을 많이 가더라고요. 결국 유지보수는 도입에 적극적이지 않았던 사람들이 하고 있습니다.
어쩌면 팀원분들의 이직 사유가 새로운 기술도입이라했을때 그말이 사실인지는 검증이 필요할꺼 같아요.
새로운 기술 도입 여부가 아니라 다른 이유일지도..
그 상황은 더 적극적이고 도전적이고 진취적인 사람들이 실력도 더 빨리 늘고 좋은 곳으로 이직하는 사람들로 이해하면 되지 않을까요? 당연해보입니다.
적극적이지 않았던 사람들이 더 좋은 곳으로 이직할 리가 없잖아요.
@@ujty207 적극적인 사람이 이직에 유리한건 동의하나, 새로운 기술을 도입하는 것이 곧 실력이 좋은건가는 잘 모르겠습니다.
새로운 기술을 써보고 싶은건 좋은데, 그게 개인 프로젝트가 아니라 실제 프로덕트라면 유지보수를 어떻게 하는지도 고민이 필요하다 생각됩니다.
그부분이 아쉬웠습니다.
결론은 나도 새로운 기술 도입하고 이력서 한줄 추가해서 런할꼬얌
IT 관련 업무를 하고있는데 너무 공감되는 고민과 혜안을 주셔서 감사하네요!
스타트업 cto의 고충이죠. 향로님이 부족한거라기보단 이런 시리즈abc급 스타트업이 좋은 배경이니까 이 배경을 잘활용한거라 봅시다ㅎㅎ
테크 팀 리더이기보다 조직 리더로서의 고충…공감합니다 👍
이렇게 또 발전하시네요!
재밌고 유익하게 봤습니다!
현재 내가 가진 역량 이상의 일이 요구될 때 누구나 자존감이 부분적으로 위태로워질 수 있는 것 같아요. 그렇지만 나의 부분적 미흡함 때문에 나란 사람 전체에 대한 회의감에 빠지지 않도록 하는게 중요한 것 같습니다. 시니어 역시 이런 고민을 한다는게 저같은 주니어에게는 위로가 돼요. 이겨내실거에요!
개발바닥보면서 향로님의 인간 성장과정을 보는것 같아서 흥미롭네요..!
항상 응원합니다
저도 비슷한 고민을 하고 있는 것 같아요.
팀 내 여러 개의 마이크로 서비스가 있어요. 각자 담당자들이 달라요.
저는 필수 기술 범위를 제한하고, 개발부터 배포까지 표준을 만들고 싶어합니다.
서비스 담당자 A가 부재중이여도, 아무것도 모르는 개발자 B가 A의 서비스에 접근해서
상태를 점검하고, 로그를 확인하고, 서비스를 재시작 하거나 배포를 할 수 있으려면
우리가 일정한 표준 내에서 개발을 준수해야 가능한 일이거든요.
그래야 서로 마음 놓고 휴가를 가도 전화를 하지 않죠. (
저 또한 팀 리더를 맡게 되면 어떻게 할지 객관적으로 생각해보게 되네요
롤모델이신 향로님도 이런 생각을 한다는 걸 알게 되서 좋네요
향로님 의견에 완전 동의합니다👍
매니징을 하게 되면 책임질 범위가 더 커지는데, 작은 책임의 시절에는 새로운 걸 시도하는 과정에서 문제가 발생해도 내가 해결할 수 있는 영역이라는 안정감을 얻기가 비교적 수월하다고 생각합니다. 그런데 큰 범위, 제가 겪어본 적없는 C레벨의 의사결정 상황이 되면 새로운 시도가 사업의 방향과 잘 맞는지, 충분한 시너지가 있는지, 새로운 것을 시도하는동안 발생하는 비효율의 기간을 어떻게 감당할건지, 문제가 생겼을 때 어떻게 해결할지를 더 큰 단위에서 접근할 것 같아요. 그러면 당연히 보수적인 입장으로 자연스럽게 변화하는거라 생각합니다. 이런 경우에는 새로운 것을 시도하려는 구성원이 더 유리한 입장이라고 생각하는데, 마치 기획자-개발자 관계에 있어서 무엇인가를 새로 구현하자는 사람이 항상 더 잘 준비해서 상대를 설득할 기회가 있기 때문이죠. 의사결정자 입장에서는 본인의 보수성을 반성하는 것도 중요할 수 있지만, 새로운 것을 시도하는 사람에게 이 시도가 불러일으킬 수 있는 다양한 효과를 조명해주고, 더 큰 관점에서 봤을때에 생기는 효과들을 고려했을때도 이 도입이 필요하다고 느끼다면 그 필요를 잘 프레젠테이션해서 공동체가 필요성을 공감하게 하는게 중요하다고 생각합니다. 단순히 리더십으로 휘어잡아 진행시켜, 진행시키지 마. 이런건 실제로는 리더십이라기보단 인사권과 평가권이 강하고 조직 자체가 대체불가능한 편인 (이를테면 회사로서의 구글이나 국내의 네이버 같은 빅테크) 곳에서 직원들이 따르기 더 수월한 다양한 장치들을 마련하고 있기에 그렇게 보이는게 아닐까 싶거든요. 결국 새로운 시도에 열려있다, 닫혀있다는 나의 태도 자체의 문제라기보단 고려해야 할 영역 범위의 변화로 인해 안정성이란 가치에 가점이 매겨진 것이고, 이것을 설득할 수 있는 기회는 새로운 도전을 원하는 사람에게 주어져 있으니 그가 잘 준비해서 가점 이상의 가치를 보여줘야한다.. 이게 정론이라고 생각합니다.
이런 부분이 개인의 발전, 재미, 흥미, 욕망과 충돌하는건 회사라면 당연한 것이지만 어느 정도의 출구를 제시하기 위해서 작은 범위에서의 자율성을 보장하는 것도 도움이 될 것 같고요.
퇴사자를 막을 수 있는 방법은 불가능하다고 생각하시겠지만 예방밖에 없죠.. 근데 예방이 불가능한 부분이라면 박수쳐주며 보내줘야죠뭐.. 예방 가능한 부분은 뭐 잘 고민하실것 같지만.. 여튼 이렇게 방송에서 이야기 할정도로 고민하시는 것 보면 다른건 몰라도 퇴사하시는 세분이 아주 많이 좋은 사람이자 엔지니어였다는 것이 느껴집니다..
User Experience, Voice of Customer의 중요성에 비해 오히려 내부 구성원, 동료의 목소리는 상대적으로 중요하다고 인지 하는 의사 결정권자, 경영자, 리더가 흔치 않죠...! 동료와의 이별이 좀 헛헛하고 섭섭할 수는 있지만 그래도 내가 떠날 때, 내가 조직에서 불편함이 있을 때 내 말을 귀 기울여 들어줄 존재가 있다는 것만으로도 인프랩 동료분들한테 큰 힘이 될거에요...! 화이팅화이팅!
영상을 보고 드는 생각을 한자 적습니다.
리펙토링과 새로운 라이브러리로의 교체의 공통점을 잘 생각해보세요~
직원분과 같은 가치관을 가지고 계신 것 같은데 캐치를 못하고 계신 것 같습니다^^
극공감 하면서 너무 잘 봤습니다!
댓글로나마 소신발언해봅니다....! 회사는 실험실이 아니드아!!!
(비슷한 내용의 영상을 찍어놨는데 '너무 꼰대 주의 보인가...?'의 걱정이 있었는데 이 영상에 용기를 얻고갑니다ㅎㅎ)
저도 향로님 쪽 성향인데 저랑 정 반대인 팀메이트 때문에 고생중입니다. ㅠ
잘 보고 가요
고민하는 리더라는 거 자체가 귀감이 되네요
Chief Technical Officer 최고 기술 관리자 라니 너무 부럽네요 언제 저렇게 될수있을까
실서비스인데 자기 플레이그라운드 장난감처럼 다루면 안 되긴 하죠.
새로운 기술 도입과 관련해 개인적으로 떠올린 부분은, 전체 흐름의 영향을 주지 않는 한에서 모두 같이 합의된 룰이 있으면 자유롭게 테스트를 할 수 있는 스콥(열정적인 주니어의 플레이존)을 정한다면 어떨까요? (예로, 어드민 도구의 특정 부분에서만 적용해보자)
어떤 도구이든 기존의 개념 하에서 개선이 이뤄진 것이 있고, 기존의 개념을 무너뜨리며 사용자에게 새로운 개념으로 사용하게 하는(+개선) 도구가 있다고 생각합니다.
그렇기에 컨택스트에 따라 혁신적인 개선을 만드는 도구와 그저 갈아끼우기가 되는 도구가 있을 것 같습니다.
그렇기에 요는 납득 가능한 도구 변별 및 적용 프로세스를 합리적으로 납득가능한 범위에서 합의해서 만드는 것이라고 생각해보았습니다.
개발자가 아니라 매니저나 경영진이라면 기술의 타당성만 보는 것이 아니라 개발자의 욕망을 잘 컨트롤 해야하는 것 같습니다.
팀원간에 초기에 협의점을 찾아서 그걸로 통일하는 방법도 있을거 같아요. 좀 길어질수도 있지만 결국 다 수긍하고 넘어가게 되니까요
경험이 늘어가면서 생각의 편향도 커지기 때문인 것 같아요ㅋㅋ 모두 그렇게 점점 꼰대가 되어가는 겁니다...
아무래도 실서비스를 하는 스타트업이라 더 그런 고민에 빠지시는게 아닌가 싶습니다. 투자받고 실서비스는 아직 남았으면 뭐든 시도해볼텐데 이미 서비스가 돌아가고 있으면 라이브러리든 스택이든 뭐든 바꾼다는게 리더로서 선뜻 내키지 않는 일이죠. 그러면 서비스가 어느정도 자리잡으면 새로운걸 하고 싶은경우 무조건 이직해야 맞는가? 개발자는 새로운걸 받아들이지 못하면 바로 도태되기에 또 있으라고 강요 할수도 없는 노릇이고 딜레마에 빠지게 되죠. 저는 그래서 MSA 인프라는 기본으로 가져가고 회사내에서도 사이드 프로젝트를 해서 현재 서비스에 크게 영향이 없는 별도의 프로젝트를 규모가 커질수록 해야 한다고 생각 합니다. 그 프로젝트에선 자유롭게 이것저것 해보는것이고 그 스택이나 모듈이 괜찮다면 실서비스에도 리팩토링해서 적용 가능한것이고 그리고 코드 리팩토링이 꼭 같은 프레임웤 라이브러리에서만 한다고 발전 한다고 생각되진 않는것 같습니다. 목수가 새로나온 일자톱만 쓰다가 새로나온 신상전기톱에 적응되기까진 시간이 걸려서 기존제품엔 적용하기가 힘들긴 하지만 적용만 하면 결국 생산력을 폭발적으로 올려주거나 제품의 마감을 높여주니까요.
퇴사할때 사람문제로 나가는게 많더라구요 물론 그 말을 하진않습니다 ㅋㅋ
호돌님 확신의 T… 3:03 힘내세요 ….
낄낄
❤
다큐찍는 시니어 판타지 원하는 주니어 장르 고민하는 리더 의 시대인것같습니다.
.... 아아.. 입장..
6:08 ㅋㅋㅋㅋㅋㅋㅋㅋ
결국...밥그릇문제...잘정리하세요...
향로님 멘탈 붕괴오신거 같네요. 힘드셔서 그럴수도 있으니 너무 생각을 많이 하기보다는 좀 쉬어가시는것도 방법이지 않을까요
단단해 보이는 사람도 내적으로 이런 고민을 하고있구나.
다 똑같구나
정말 T적인 생각이라... 글쓰기에 좀 조심스러운데,
개발자분들이 보면 대부분 인문학적 결핍증에 걸린 것 같아서...
무슨 말이냐면 하는 일의 성격이 타직업들에 비해 확실히 하드하다보니까 소프트한 일에 대해서는 상당히 수용적이라는...
그릇이라는 인문학적인 단어가 좀 그 대표적인데...
사람의 그릇이라는 건 뭔가 더 넓은 의미를 가지는데에도 불구하고 특정 일에 갖다붙여셔 생각을 하고, 사실은 그릇이라는 단어 자체가 애매한 단어입니다. 뜻도 모호하고 사람마다 그 뜻에 대해 주관적이라서요.
범죄관련 전과나 그에 준하는 인성을 갖고 있는 것도 아닌데 사람 인성이란건 정상인 범주 안에서는 누구나 다 비슷한거 아니냐? 생각하는 사람도 많아서...
폭행, 직장 내 괴롭힘 등의 범.죄급의 일이 아니라면 복잡하고 다사다난한 사회생활 중에서 딱히 인성이니 그릇이니 하는건 없는것 같습니다... 그냥 사람들의 성향들만 있을뿐...
한국 사회생활 문화에서... 인.성이라는 단어가 근래 많이 대두되는데 뭔가 소승불교에서 나오는 정신수련의 의미보다는 번듯한 사회인이 갖추어야할 소양적인 의미가 강해서...
오히려 인성이라는 사람을 평가하는 새로운 스펙, 잣대를 만들어내서 그걸로 또 사람을 점수화, 평가화 시키는 부작용이 더 크다고 생각합니다 저는...
요약좀해주세요
공감이 안가는...
생태계의 변화라는 건 현재 쓰고 있는 것들에 대한 피드백의 반영이라 할 수 있을텐데요.
이전에 있던 문제는 개선하고, 불필요한 것은 제거하거나 생략하고, 이 두 가지가 모두 기반 아이디어, 그러니까 컨셉 때문이라고 여기면 새로운 기반 아이디어 아래 다시 새 것이 등장하는 식으로 변화하고 있으니까요. 그래서 우리는 이 변화에 대응하지 못하는 상태를 두고 기술 부채가 쌓이고 있다 하고요.
그런데 영상에서 말하듯이 이걸로도 충분히 가능하고, 어떤 것은 선택의 문제일 뿐... 이라 하면 이게 부채를 지겠다는 말 아닐까요? 부정적인 의미에서의 고인다는 방향으로.
툴이나 언어와는 상관 없지만 변화의 수용이라는 점에서는 궤가 같을 것 같은데,
변화의 수용을 사전에 점검하는 UX 엔지니어, 컨셉을 스스로 만들고 거기에 필요한 툴을 가져오거나 생산하는 프론트엔드 시스템 엔지니어라는 직군이 나오는 것에 개발자들이 관심을 가져보는 게 어떠한가 싶네요.
저 좀 뽑아주세요. 취업이 안 돼요.. 일 공부 다 열심히 할 수 있는데. 이력서 자체 통과가 안 돼요..
^^;