LG유플러스

LG유플러스

개발팀 리뷰

위 내용은 LG유플러스 전 • 현 재직자의 응답 결과입니다.

기술 스택

기술 스택 정보가 없어요.

재직자가 작성한 글

profile picture

최성욱

LGU+ 데브옵스 엔지니어

팟캐스트 - 데브옵스는 무엇일까?

같이 일하는 팀원 이권수님과 함께 팟캐스트를 진행했습니다! 데브옵스에 대한 이야기를 나눴습니다. * 팟캐스트 링크: https://youtu.be/-ZzoP3mnbZc ⭐️ 목차 * 팟캐스트를 시작한 이유 * 데브옵스와 SRE는 무엇인가? * 데브옵스 팀은 필요한가? * 신입은 데브옵스 엔지니어를 하기 어려운가? * IaC의 한계

profile picture

이권수

LG U+ 소프트웨어 개발자

Python Property & Descriptor

1. 인스턴스 속성 및 프로퍼티 - 인스턴스 속성은 각 클래스 인스턴스에 고유하며, 일반적으로 init 메서드에서 정의됩니다. 이 속성들은 직접 접근하거나 getattr를 통해 접근할 수 있습니다. - 파이썬의 property 함수는 게터, 세터 및 딜리터 메서드를 정의하여 속성 접근을 사용자 정의할 수 있게 하며, 접근 패턴을 변경하지 않고 추가적인 로직을 가능하게 합니다. 2. 디스크립터 프로토콜 - 디스크립터는 get, set, delete와 같은 메서드를 구현하여 다른 객체의 속성 접근을 제어합니다. 이는 여러 클래스와 변수에 걸쳐 재사용할 수 있어 속성 동작을 관리하는 확장 가능한 솔루션을 제공합니다. - 디스크립터는 인스턴스 간에 공유되는 클래스 변수이며, 내부 사전 및 인스턴스 해시를 사용하여 인스턴스별 값을 관리할 수 있습니다. 콜백 함수가 있는 약한 참조는 삭제된 객체에 대한 참조를 제거하여 메모리 누수를 방지하는 데 도움이 됩니다. 3. 프로퍼티 조회 해결 - 파이썬은 속성 조회 시 인스턴스 사전 값보다 데이터 디스크립터를 우선합니다. dict 변수의 인스턴스 값은 비데이터 디스크립터를 재정의할 수 있습니다. property 함수는 내부적으로 데이터 디스크립터를 생성하여 인스턴스 값에 의해 대체되지 않도록 합니다. 자세한 블로그 읽어보기[EN]: https://www.zerotoexpert.blog/p/python-property-and-descriptor-zero

재직자가 좋아한 글

좋은 개발자가 알아야하는 9가지 포인트들 - 8. 결과를 내는데 집중하기  |   1. 기본기 확실히 하기 2. 학습 능력 키우기 3. 의사 소통 잘하기 4. 문제 정의 잘하기 5. 태스크 완료 시간 추정 잘하기 6. 운영을 고려한 코드 작성하기 7. 서비스 사고 대처 능력 키우기 8. 결과를 내는데 집중하기 9. 영향력 갖기 (코딩 멍키) 앞서 연차로 인한 압박에 관한 글을 쓰기도 했지만 아무래도 사교육과 선행학습이 일상인 환경에서 자라고 교육받다보니 다들 기술 지향적으로 뭘 배워두면 내 커리어가 안전해질까 등으로 항상 정답을 찾으려 많이 하려 하는 듯 하다. 다시 한번 학교 바깥의 세상에는 정해진 커리큘럼도 없고 시험처럼 정답이 정해진 형태의 테스트가 있지도 않다. 긴 커리어에서 더 건강한 관점은 내가 원하는 것이 무엇인지 고민하고 나에게 맞는 환경을 찾아 거기서 현재에 집중하며 맡은 업무 파악(의사 소통 -> 문제 정의)하고 그 업무를 성공으로 이끌어내는 경험을 하는 것이 중요하다. 피터 드러커의 "The Effective Executive"라는 책을 보면 모든 지식 노동자는 본인이 하고 있는 "공헌"이 무엇인지 고민해봐야 한다는 이야기를 한다. 여기서 포인트는 "맞는" 공헌을 하고 있는지 아니면 뭔가 잘못된 공헌을 하고 있는지 살펴봐야 한다는 점이다. 잘못된 공헌으로는 어떤 것들이 있을까? 1. 매니저로써 팀빌딩에 힘을 쓰기 보다는 개인으로 하는 코딩에 더 노력하는 것을 들 수 있다. 팀에 인력이 부족해서 라면 모르겠지만 대신할 사람이 있는데 그렇다면 큰 문제다. 2. 매니저로 모든 일에 직접 끼어들다보니 본인이 없으면 팀이 안 돌아간다면 결국 본인이 병목이 되면서 문제가 된다. 1, 2번에서 매니저라고 했지만 팀내 시니어 멤버라면 본인을 대입해서 생각해볼 필요가 있다. 프로세스로 돌아가게 하거나 나를 대신할 사람을 계속 찾는 노력을 계속해야 한다. 3. 불필요하게 새로운 프레임웍의 도입을 서두르는 것인데 일반적으로 이야기하자면 문제해결이나 가치창출에 집중하는 것이 아니라 너무 기술중심으로 가는 거다. 4. 주니어라면 처음에는 모르는 것들이 많을 수 있지만 동일한 질문이나 도움을 반복한다면 뭔가 잘못된 것이다. 팀에 공헌하는 사람이 되고 싶다면 발전하는 사람이 되어야 하며 때로는 모르거나 이해가 안되거를 대충 체면치레하며 넘어가지 말고 구체적으로 물어보고 이해해야 한다. 5. 다른 큰 범주는 문제정의를 잘 하고 맞는 방향으로 노력을 하는 것이 아니라 잘못된 "노력"을 강조하는 것이다.맞는 방향으로 노력했지만 결과가 안 좋았다면 그건 괜찮지만 열심히 했다는 이유만으로 모든 것이 인정되는 것은 아니다. 등산이라면 어느 산으로 올라가는지 먼저 파악해야지 아무 산이나 열심히 올라간 다음에 그걸 인정해달라는 건 말이 안 된다. 조직 사회에서 인정받고 자신감을 쌓는 제일 좋은 방법은 "결과"를 내는 사람이 되는 것이며 이는 내가 지금 할 수 있는 "맞는 공헌"이 무엇이 있는지 생각해보고 내 매니저나 동료들과 많이 이야기해보는 것이다. 개발자 관점에서 조심할 부분은 너무 기술적으로만 바라보는 것이다.

좋아요 165 저장 255