idoun.net

네스프레소 버츄오 업 (Nespresso Vertuo Up)

이도운 — Tue, 18 Aug 2026 01:02:18 +0900

지난 제주 여행에 만족했던 숙소 '유유히'에서 캡슐과 머신을 제공해주셔서 네스프레소 버츄오를 체험해 볼 수 있었다.

기존 캡슐의 특허가 만료되면서 호환 캡슐이 크게 늘어났고, 이후 네스프레소가 새롭게 내놓은 캡슐 시스템이 버츄오다. 캡슐을 고속으로 회전시키는 방식으로 커피를 추출하며, 풍성한 크레마가 만들어지는 것이 특징이다. 때문에 회전하는 독특한 소음이 발생한다. 기존 오리지널 머신보다는 크진 않은데 좀 더 길게 이어진다.

숙소에 있던 기기는 버츄오 팝이었는데, 거품이 풍부하고 맛도 훌륭해서 구매하고 싶은 마음이 들었다. 다만 버츄오 팝은 가격이 저렴한 대신 열고 닫기가 불편하였다. 상단의 레버를 돌려 잠금을 해제한 뒤 커버 전체를 들어 올리는 방식인데, 이 레버를 돌리는 데 생각보다 힘이 꽤 필요했다.

네스프레소 공식 홈페이지를 보니 지난 26년 4월에 버츄오 업 모델이 신규 출시되었고, 마침 프로모션 행사로 할인이 진행중인 것을 알게되었다. 그래도 팝이나 팝 플러스 모델에 비해 좀 더 비싼 편이다. 특히 팝이나 팝 플러스 모델은 다른 쇼핑몰에서 공식 가격보다 훨씬 저렴하게 구매할 수 있다. (거의 절반 가격)

반면 버츄오 업 모델은 기존의 오리지널 네스프레소 머신처럼 상단 래치를 들어 뒤로 젖히는 방식이라 여닫기가 훨씬 간편해 보였다. 컵 받침이 무광의 금속 재질이라 좀 더 고급스러운 느낌이 나고, 본체 폭도 팝에 비해 좀 더 날씬해서 공간도 덜 차지한다. (다만 뒤로 더 길다.) 결국 사용 편의성을 고려해 버츄오 업을 구매하게 되었다.

네스프레소 버츄오 업과 네스프레소 시티즈 모델

위 사진에서 보듯 커피 거품이 상당히 많이 만들어진다. 오리지널에 비해 2~3배 수준인데, 싫어하는 사람도 있겠지만 우리 가족은 이 부분에 만족해서 버츄오 머신을 구매했다고 보는게 맞겠다. 거품이 많다보니 잘 꺼지지 않고 오래간다. :)

커버드 콜(Covered Call)

이도운 — Tue, 18 Aug 2026 00:32:10 +0900

주식을 보유한 상태에서 그 주식의 콜 옵션을 매도해 프리미엄을 받는 전략

쉽게 말헤, 주가가 크게 오늘 가능성 일부를 포기하고 정기적인 현금 수익을 얻는 구조.

10만원인 A 주식을 내가 구매 해 가지고 있으면서 "한 달 뒤 11만원에 살 수 있는 권리", 즉 행사가 11만원짜리 콜 옵션을 팔고 3000원의 옵션 프리미엄을 받았다고 가정한다.

만기 시 주가가 9만 원이 되면? : 1만 원 손실이지만 3천 원 프리미엄으로 일부 방어, 콜 옵션 행사되지 않음(구매자 손실)
10만 원 그대로 : 프리미엄 3천 원 그대로 수익, 콜 옵션 행사되지 않음 (구매자 프리미엄 손실)
10만 8천 원 : 프리미엄 3천 원 + 8천 원 수익(미실현 수익), 콜 옵션 행사되지 않음 (구매자 프리미엄 손실)
11만 원 : 프리미엄 3천 원 + 1만 원 수익(미실현 수익), 콜 옵션은 통상 행사되지 않음 (구매자 프리미엄 손실)
11만 2천 원 : 프리미엄 3천 원 + 1만 원 수익(실현 수익), 2천 원 상승분 포기, 콜 옵션 행사 (콜옵션은 2천 원의 내재가치를 가지므로 행사하는 것이 경제적으로 유리. 3천 원의 프리미엄까지 포함하면 최종 손익은 -1,000원)
11만 3천 원 : 프리미엄 3천 원 + 1만 원 수익(실현 수익), 2천 원 상승분 포기, 콜 옵션 행사 (구매자는 프리미엄 합쳐 본전)
14만 원(급등하여 기대 이상인 상황) : 프리미엄 3천 원 + 1만 원 수익(실현 수익), 3만 원 상승분 포기(다만 옵션 프리미엄 3천 원을 받았으므로 단순 주식 보유 대비 최종 수익 차이는 2만 7천 원), 콜 옵션 행사 대상

14만 원의 예 처럼, 급등하여 초과 상승분을 얻지 못한게 크고 앞으로도 상승할 것이 기대 된다면 만기 전에 롤 오버 전략을 수행하게 된다. 시장에서 기존의 11만 원 콜 옵션을 프리미엄을 3만원을 붙여 산 뒤 16만 원 권리로 프리미엄을 6000원으로 기간을 연장한 콜 옵션을 다시 팔 수 있다. Roll Up and Out이라고 한다. 이렇게 하면 -30,000 + 3,000으로 기존 옵션 거래에서 -27,000원 손실을 확정하고, 새로운 16만 원 콜옵션을 매도하여 6,000원의 프리미엄을 받은 새 포지션을 시작한다.

여기서는 예제니까 손해 엔딩이지만 운용자는 만기, 행사가, 시장 변동성 등을 고려해 기존 옵션을 조기 청산하거나 Roll Up, Roll Out 등의 전략으로 포지션을 조정할 수 있다. 다만 롤오버가 이미 발생한 옵션 손실을 없애주는 것은 아니다.

미국 주식옵션은 일반적으로 만기 시 0.01달러 이상 ITM이면 자동행사되는 것이 표준적인 처리 방식이다. 내가격(ITM, In The Money)은 옵션을 지금 행사했을 때 바로 경제적 가치가 있는 상태를 말한다. 외가격(OTM, Out of the Money)는 이득이 없는 상태를, 등가격(ATM, At the Money)은 기초 자산 가격과 행사가가 거의 같은 상태이다.

그리고 옵션 종류가 미국형(American-style)이면 구매자가 만기 전에도 행사할 수 있다. 반대로 유럽형(European-style)은 원칙적으로 만기에만 행사할 수 있다. 미국형은 언제 조기 행사를 하게 될까? "배당"이 대표적인 경우이다. 옵션에 남은 시간가치가 500원인데 내일 배당락이고 주식을 보유하면 1000원의 배당을 받을 수 있다면 당장 옵션을 행사해서 주식을 보유하고 배당을 받는 것이 이득이다.

만기까지 시간이 남아 있어 옵션에 시간가치가 존재한다면, 옵션 보유자는 조기 행사하는 것보다 옵션 자체를 시장에서 매도하는 것이 더 유리할 수 있다. 조기 행사하면 남아 있는 시간가치를 포기하기 때문이다.

커버드콜은 하락 위험을 크게 줄이는 전략이라기보다, 일정 수준 이상의 미래 상승 수익을 옵션 프리미엄과 교환하는 전략이다.

K8S 도입 전에 '진짜' 알아두어야 할 것

이도운 — Mon, 17 Aug 2026 00:48:17 +0900

Kubernetes를 처음 검토할 때는 보통 장점부터 눈에 들어온다.

자동 복구, 오토스케일링, 롤링 업데이트, 서비스 디스커버리, 선언형 배포 같은 기능은 분명 매력적이다. 컨테이너 기반으로 여러 서비스를 운영한다면 Kubernetes가 사실상 표준처럼 느껴지기도 한다.

그런데 실제로 도입을 검토하다 보면 기능보다 먼저 알아두어야 할 부분이 있다.

K8S를 도입한다는 것은 애플리케이션뿐 아니라 K8S라는 플랫폼 자체도 계속 운영한다는 뜻이다.

설치하고 서비스를 올리는 것보다, 그 이후 몇 년간 어떻게 유지할 것인지가 더 중요할 수 있다.

1. Kubernetes는 한 번 설치하고 오래 쓰는 제품이 아니다

기존 서버 소프트웨어는 특정 버전을 설치한 뒤 몇 년 동안 유지하는 경우가 많다.

Kubernetes는 조금 다르다.

매년 여러 개의 minor version이 나오고 각 버전의 지원 기간도 비교적 짧다. 따라서 몇 년 동안 같은 버전을 유지하는 방식으로 운영하기 어렵다.

결국 이런 과정이 계속 반복된다.

1.34
 ↓
1.35
 ↓
1.36
 ↓
1.37

즉 Kubernetes에서는 버전 업그레이드가 특별한 이벤트가 아니라 정기적인 운영 업무에 가깝다.

Managed Kubernetes인 EKS를 사용한다고 해도 이 부분이 완전히 없어지지는 않는다.

AWS가 Control Plane 운영을 맡아주기는 하지만 Kubernetes 버전, Node Group, Node AMI, CNI, CoreDNS, kube-proxy 같은 부분은 여전히 신경 써야 한다.

EKS를 쓴다
≠
K8S 운영을 안 해도 된다

정도로 이해하는 것이 맞다.

2. 그런데 K8S는 왜 이렇게 운영할까?

처음 이 내용을 보면 이런 의문이 든다.

왜 Kubernetes는 Ubuntu LTS처럼 하나의 버전을 몇 년 동안 오래 지원하지 않을까?

Kubernetes가 단순한 서버 프로그램이라기보다 여러 인프라 기술 사이에 위치한 플랫폼이라는 점을 생각해보면 조금 이해하기 쉽다.

Kubernetes 주변에는 계속 변하는 기술들이 있다.

Container Runtime
Network
Storage
Cloud
Linux
Security
Observability

이 기술들이 변하면 Kubernetes도 그에 맞춰 API와 내부 구조를 계속 바꿔야 한다.

오래된 기능과 API를 계속 유지하면 사용자 입장에서는 편하지만, Kubernetes 내부에는 계속 이전 방식이 쌓이게 된다.

그래서 Kubernetes는 대체로 다음과 같은 방식을 취한다.

새로운 기능 제공
 ↓
기존 방식 Deprecated
 ↓
일정 기간 호환
 ↓
오래된 기능 제거

기존 기능을 무한정 유지하기보다는 일정 기간 전환 기회를 주고 이후에는 정리하는 방식이다.

덕분에 Kubernetes 자체는 빠르게 발전할 수 있지만, 반대로 사용하는 쪽에서도 그 변화에 계속 따라가야 한다.

기업 입장에서는 조금 불편한 부분이다.

애플리케이션은 안정적으로 몇 년씩 운영하고 싶은데, 그 아래 플랫폼은 계속 움직이기 때문이다.

결국 Kubernetes에서는 변화를 피하는 것보다 작은 변화를 계속 받아들이는 운영 방식이 중요해진다.

3. 버전만 올리면 끝나는 것도 아니다

처음에는 Kubernetes 버전만 올리면 되는 것으로 생각하기 쉽다. 실제로는 그 주변에 있는 컴포넌트의 호환성을 같이 확인해야 한다. 예를 들어 다음과 같은 것들이다.

Kubernetes Control Plane
        ↓
Worker Node / Node AMI
        ↓
CNI
CoreDNS
kube-proxy
        ↓
Ingress Controller
CSI Driver
        ↓
Helm Chart
Operator
CRD
Admission Controller
        ↓
Application

새로운 Kubernetes 버전에서 기존 API가 deprecated되거나 제거될 수도 있고, 사용하고 있는 Helm Chart나 Operator가 해당 버전을 아직 지원하지 않을 수도 있다.

그래서 Kubernetes 업그레이드는 단순히

1.34 → 1.35

숫자 하나를 바꾸는 작업이라기보다 플랫폼 전체의 호환성을 확인하는 작업에 가깝다.

4. 업그레이드를 미루면 나중에 더 힘들어진다

그러면 귀찮으니 최대한 오래 버티다가 한 번에 올리는 것이 나을까? 보통은 반대다.

오래된 버전을 계속 유지하면 여러 단계의 변경 사항이 한꺼번에 쌓인다.

예를 들어 1.31을 오래 사용하다가 최신 버전까지 따라가야 한다면 다음과 같은 작업이 될 수 있다.

1.31
 ↓
1.32
 ↓
1.33
 ↓
1.34
 ↓
1.35

그 사이에 API가 사라지고, Helm Chart가 바뀌고, Node OS가 바뀌고, Add-on 요구사항까지 변경되면 업그레이드 작업의 범위가 훨씬 커진다. 그래서 Kubernetes는 몇 년에 한 번 큰 업그레이드를 하는 것보다 지원 기간 안에서 조금씩 계속 따라가는 편이 오히려 안전하다.

5. Managed Kubernetes도 운영 부담이 사라지는 것은 아니다

AWS EKS, Azure AKS, Google GKE 같은 Managed Kubernetes를 사용하면 직접 Kubernetes Cluster를 구성하는 것에 비해 운영 부담이 크게 줄어든다. 특히 Control Plane을 직접 관리하지 않아도 되는 것은 큰 장점이다.

하지만 Managed Kubernetes가

Kubernetes 운영을 하지 않아도 된다

는 뜻은 아니다.

예를 들어 EKS를 사용하더라도 다음과 같은 영역은 계속 관리 대상이 된다.

Kubernetes Version
Managed Node Group
Node AMI
VPC CNI
CoreDNS
kube-proxy
Ingress Controller
CSI Driver
Helm Chart
CRD
Operator

Managed Kubernetes는 Kubernetes 운영을 없애주는 서비스라기보다, 운영 영역 일부를 클라우드 사업자가 대신 담당해주는 서비스에 가깝다고 생각한다.

6. Kubernetes를 도입하면 플랫폼이 하나 더 생긴다

개인적으로 Kubernetes의 숨은 비용은 클라우드 비용보다 이 부분이 더 크다고 생각한다.

예를 들어 운영하려는 서비스가 다음과 같다고 하자.

Agent API
MCP Server
LLM Gateway
Redis
PostgreSQL
Observability

Kubernetes 없이 운영한다면 주로 애플리케이션과 AWS 인프라를 관리하면 된다.

그런데 Kubernetes를 도입하면 새로운 관리 영역이 생긴다.

Application
AWS Infrastructure

+

Kubernetes
Helm
Ingress
CNI
CSI
CRD
Operator
Node Group
RBAC
Namespace
Resource Limit
Autoscaling
Pod Scheduling

Kubernetes가 애플리케이션 운영을 편하게 해주는 것은 맞다. 하지만 동시에 Kubernetes라는 또 하나의 플랫폼을 운영하는 일도 생긴다. 이 비용은 단순히 서버 비용으로 계산하기 어렵다. 이를 운영하고 문제를 분석할 사람과 경험도 필요하기 때문이다.

7. 장애 분석 범위도 넓어진다

Kubernetes가 정상적으로 동작하면 상당히 편리하다. Pod가 죽으면 다시 띄워주고, Node에 문제가 발생하면 다른 Node에서 서비스를 실행할 수도 있다. 하지만 문제가 발생했을 때는 원인 후보가 많아진다.

예를 들어 단순히

Pod가 안 뜬다.

라는 문제가 생겼다고 해도 확인해야 할 것은 많다.

Application 문제?
Container Image 문제?
Resource 부족?
Node 문제?
Scheduler 문제?
CNI 문제?
DNS 문제?
Volume 문제?
IAM 문제?
Ingress 문제?
Admission Controller 문제?

결국 Kubernetes를 사용하려면 YAML을 작성하고 kubectl apply를 할 수 있는 것만으로는 부족하다. 장애가 발생했을 때 어느 계층에 문제가 있는지를 추적할 수 있는 운영 역량도 필요하다.

8. 컨테이너를 쓴다고 Kubernetes가 필요한 것은 아니다

Kubernetes를 검토할 때 가장 조심해야 하는 판단 중 하나가 이것이라고 생각한다.

우리는 컨테이너를 사용하니까 Kubernetes로 가자.

컨테이너와 Kubernetes는 같은 이야기가 아니다.

서비스가 몇 개 안 되고 트래픽도 예측 가능하다면 다음과 같은 구조가 훨씬 단순할 수도 있다.

ALB
 ↓
ECS / Fargate
 ↓
Application Container

반대로 서비스가 계속 늘어나고 여러 팀이 독립적으로 개발하고 배포하기 시작하면 Kubernetes의 장점이 커진다.

예를 들면 이런 환경이다.

서비스 수가 많다.
서비스별 배포 주기가 다르다.
여러 개발팀이 하나의 플랫폼을 사용한다.
리소스 관리가 복잡하다.
다양한 워크로드를 운영해야 한다.
배포 전략과 트래픽 제어가 복잡하다.
회사 차원의 공통 플랫폼이 필요하다.

이 정도 규모가 되면 Kubernetes가 제공하는 표준화와 자동화의 가치가 확실히 커진다.

그래서 중요한 질문은

Kubernetes로 할 수 있는가?

가 아니다.

대부분의 서비스는 Kubernetes로 만들 수 있다.

더 중요한 질문은

우리 규모에서 Kubernetes까지 운영할 필요가 있는가?

이다.

9. 그렇다면 K8S 운영은 어떻게 해야 할까?

Kubernetes를 쓰기로 했다면 버전 업그레이드를 이벤트성 작업으로 두지 않는 것이 중요하다.

처음부터 정기적인 운영 프로세스에 넣는 편이 좋다.

예를 들어 다음과 같은 흐름이다.

1. 현재 Kubernetes 버전과 지원 종료 시점 확인

2. 다음 버전 Release Note 확인

3. Deprecated API 확인

4. CNI / CSI / Ingress / Helm / Operator
   호환성 확인

5. 개발 환경 Upgrade

6. 주요 기능 및 배포 테스트

7. Staging 환경 Upgrade

8. Production Control Plane Upgrade

9. Node Group Rolling Update

10. Add-on Upgrade

11. 모니터링 및 이상 여부 확인

12. 이전 Node 제거

중요한 것은 Production Cluster에서 바로 시도하지 않는 것이다.

Development
    ↓
Staging
    ↓
Production

순서로 먼저 검증할 환경이 필요하다.

가능하다면 몇 가지 작업은 CI/CD와 운영 도구에 넣어 자동화하는 것이 좋다.

예를 들어 다음과 같은 것들이다.

Deprecated API 검사
K8S / Add-on 버전 확인
Helm Chart 검증
배포 후 Smoke Test
Node Rolling Update
기본 Health Check
Monitoring

결국 Kubernetes 운영에서 중요한 것은 업그레이드 경험이 많은 특정 사람 한 명에게 의존하는 것이 아니다.

누가 수행하더라도 반복할 수 있는 업그레이드 절차를 만드는 것

이 더 중요하다.

10. 결국 도입 전에 확인해야 할 것

Kubernetes를 도입하기 전에 최소한 다음 질문에는 답할 수 있어야 한다고 생각한다.

서비스 규모

현재 서비스가 몇 개인가?
앞으로 얼마나 늘어날 것인가?

운영 조직

K8S를 누가 운영할 것인가?
장애 발생 시 누가 분석할 것인가?

Upgrade

정기적인 Upgrade를 수행할 수 있는가?
검증할 Development / Staging 환경이 있는가?

Platform Component

Ingress
CNI
CSI
Helm
Operator
Observability

이런 컴포넌트는 누가 관리할 것인가?

대안

ECS
Fargate
VM
Serverless

같은 더 단순한 구조로도 요구사항을 만족할 수 있지 않은가?

마무리

Kubernetes는 분명 좋은 기술이다.

서비스와 조직의 규모가 커질수록 Kubernetes가 제공하는 자동화, 표준화, 배포 방식의 장점은 커진다.

다만 Kubernetes는 설치하고 끝나는 제품이 아니다.

버전 Upgrade
Node 관리
Add-on 관리
보안 Update
호환성 확인
장애 분석
Monitoring
운영 자동화

를 계속 수행해야 하는 플랫폼이다.

그리고 Kubernetes가 빠르게 변하는 것도 우연이 아니다.

Container, Network, Storage, Cloud 같은 주변 기술의 변화를 받아들이면서 오래된 API와 구조를 지속적으로 정리하는 것이 Kubernetes 생태계가 발전해온 방식이기 때문이다.

결국 Kubernetes를 잘 운영한다는 것은 특정 버전을 오래 유지하는 것이 아니라,

계속 변하는 플랫폼을 안전하게 따라갈 수 있는 프로세스를 갖추는 것

에 더 가깝다.

그래서 Kubernetes 도입을 결정할 때는

"Kubernetes가 좋은 기술인가?"

보다 먼저

"우리 조직은 앞으로 몇 년 동안 K8S라는 플랫폼을 계속 운영할 준비가 되어 있는가?"

를 물어봐야 하지 않을까 싶다.

제주 청귤(풋귤)

이도운 — Sun, 16 Aug 2026 20:53:13 +0900

청귤청

이번 휴가에 제주도에 다녀왔습니다. 마지막 날 아이들을 위해 청귤 따기 체험과 청귤청 만들기를 했어요.

두 사람만 청귤 따기를 했는데 꽤 많이 땄는데요, 3kg 정도 되나 봅니다. 관리인 분 말씀으로는 청귤이라곤 하지만 노지 감귤이 안 익은 풋 귤이라 그대로 먹기는 어려운데, 익은 귤에 비해 비타민 등 영양가가 무척 높아서 일부러 따기기도 한다네요.

전에도 비슷한 체험을 했는데 딴 귤을 어찌할줄 몰라서 문제였어요. 풋귤을 그대로 먹기는 어렵거든요. 청귤청은 많이 만들어도 그것대로 쓸모가 제한적이라서요. 단 음식이 좋지 않기도 하구요.

그래서 뭘 할까 하다가 GPT에게 물어봤습니다.

청귤 3kg 처리 추천

1. 가장 추천: 즙 짜서 냉동
청귤을 깨끗이 씻고 물기를 완전히 닦은 뒤 반으로 자릅니다.

즙짜는 도구가 없으면:
- 반으로 자른 청귤에 포크를 꽂기
- 포크를 돌리면서 손으로 눌러 짜기
- 체로 씨만 걸러내기
껍질까지 너무 세게 으깨면 쓴맛이 날 수 있습니다.

2. 보관
바로 먹을 양만 냉장하고 나머지는 냉동합니다.
- 냉장: 3~5일 안에 먹을 정도
- 냉동: 얼음틀에 15~30mL 정도씩 소분
- 얼면 지퍼백이나 밀폐용기로 옮기기
- 가능하면 3~6개월 안에 사용
설탕은 넣지 않고 순수 즙으로 얼려두는 게 활용도가 가장 좋습니다.

청귤즙 먹는 법
가장 간단한 건 음료입니다.
청귤즙 20~30mL + 물 또는 탄산수 200~250mL
신맛에 따라 양을 조절하고, 필요하면 꿀이나 시럽을 조금 넣으면 됩니다.
탄산수에 냉동 청귤즙 큐브 한두 개 넣으면 바로 청귤에이드처럼 먹을 수 있습니다.
원액 그대로 많이 마시기보다는 물에 희석해 먹는 게 좋습니다.

즙 말고 제스트도 조금
즙 짜기 전에 상태 좋은 청귤 5~10개 정도는 껍질의 초록색 부분만 얇게 갈아두면 좋습니다.
흰 부분은 쓴맛이 나므로 피합니다.

제스트는:
- 파스타, 생선구이, 닭고기, 샐러드 드레싱, 요거트, 쿠키, 케이크, 탄산수, 하이볼
등에 조금씩 넣으면 청귤 향이 확 살아납니다.
얇게 펴서 냉동해두고 필요한 만큼 떼어 쓰면 됩니다.

3kg이라면 이렇게

제가 한다면:
- 2kg 정도는 즙으로 짜서 냉동
- 청귤 5~10개는 먼저 제스트 확보
- 나머지는 청귤청이나 슬라이스 냉동

이렇게 나누겠습니다.

핵심만 기억하면 "제스트 먼저 → 반으로 자르기 → 포크로 즙 짜기 → 체에 거르기 → 얼음틀 냉동 → 탄산수에 한두 개"입니다.

나의 의견

- 청귤즙 만드려고 스퀴저가 안보여서 위에 나온것 처럼 포크로 알갱이를 터뜨려 주고, 손으로도 꾹꾹 눌러서 짜 줬어요. 방향 잘 맞추지 않으면 사방으로 튀니 조심해야 합니다. (얼굴이나 눈에 튀면 산성이 강해서 따가워요.)

- 물 한컵에 숟가락으로 두 세 스푼 넣어주니 레몬 물 처럼 상쾌하게 먹을만 하네요. 비타민 씨 녹여먹는 느낌이 좀 있습니다. 탄산수에 타먹어도 좋아요.

- 아이들과 하면 재미있어 해서 좋네요.

날 잡고 얼른 처리해야겠네요. 즙 내서 얼음 트레이에 얼리고 보관해볼까 합니다. 큰 아이가 맘에 들어하네요.

Android build 시 VerifyError 발생

이도운 — Sat, 25 Apr 2020 22:14:21 +0900

오랜만에 Android Studio를 켜서 3.6.2로 버전업을 하였더니 빌드가 실패한다.

아래와 같은 에러들이 보인다. 숫자는 프로젝트마다 조금씩 다른 듯, Git branch와는 관계가 없다.

ERROR: Uninitialized object exists on backward branch 45
Caused by: java.lang.VerifyError: Uninitialized object exists on backward branch 45

기존에는 Oracle JDK를 1.8을 설치하여 쓰고 있었는데 Android Kotlin 관련 업데이트와 충돌을 하는 듯 싶다.

Jetifier 빌드 툴 동작중 문제가 된다. Jetifier가 무엇인지는 아래 링크 참조

https://developer.android.com/studio/command-line/jetifier?hl=ko

jetifier | Android 개발자 | Android Developers

독립형 Jetifier 도구는 동등한 AndroidX 패키지를 대신 사용할 수 있도록 지원 라이브러리에 종속된 라이브러리를 이전합니다. 이 도구를 사용하면 Android 스튜디오와 함께 번들로 제공되는 Android Gradle 플러그인을 사용하는 대신 개별 라이브러리를 직접 마이그레이션할 수 있습니다. 참고:이전을 시작하기 전에 지원 라이브러리의 버전 28.0.0을 사용하도록 라이브러리를 업데이트해야 합니다. Jetifier 설치 Jetifier를 설치

developer.android.com

검색하여보니 아래와 같이 Embedded JDK를 연결하도록 변경하면 되는 듯

https://stackoverflow.com/questions/50852086/gradle-sync-failed-uninitialized-object-exists-on-backward-branch-70

Gradle sync failed: Uninitialized object exists on backward branch 70

My android app failed to sync gradle with the following error in build log: Uninitialized object exists on backward branch 70 Exception Details: Location: com/android/build/gradle/tasks/

stackoverflow.com

아래와 같이 File 메뉴에서 Project Structure... 메뉴를 선택하고

아래와 같이 SDK Location에서 JDK location을 Embedded JDK로 바꾸니 빌드가 다시 잘 된다.

여러 프로젝트가 열려있으면 모두 적용이 된다.

Google의 Oracle 탈출의 일환인 듯..?

com.android.tools.build를 2.4.0 이상 변경 시 Failed to notify build listener 오류

이도운 — Fri, 19 May 2017 11:35:19 +0900

Google IO 2017에서 새로 발표된 Android Studio 3.0 canary 1 버전에는 새로운 Android profiler가 탑재되었다. 이 프로파일러를 동작시키기 위해서는 com.android.toos.build 버전을 2.4 이상으로 올려야 하는데, 업데이트 후 싱크 시 스튜디오에서 다음과 같은 오류가 발생하였다.

Failed to notify build listener

이럴 경우 gradle daemon에 업데이트 된 사항이 적용되지 않아 그런 것으로, daemon을 재시작하면된다. Android studio를 재시작하여도 되고, 스튜디오의 터미널 창을 열어 커맨드 명령으로 종료시킬 수 있다. 커맨드 명령은 아래와 같다.

[Windows]

> gradlew --stop

[Linux]

> ./gradlew --stop

참고 : https://androidstudio.googleblog.com/2017/04/android-studio-24-preview-4-is-now.html

텐서플로(Tensorflow) 윈도우(MS Windows) 설치 시 주의점

이도운 — Mon, 15 May 2017 14:54:05 +0900

Tensorflow 1.0부터 윈도우(MS Windows)에서 설치하여 사용할 수 있게 되었습니다. 설치시 겪었던 몇가지 주의점을 기록하였습니다. 다른 분들에게 참고가 되면 좋겠습니다.

CUDA 지원에 대해

CUDA 8.0만을 지원하므로 그 이전 버전은 호환되지 않는다. 자신의 비디오 카드가 CUDA 8.0을 지원하지 않으면 CPU only 버전으로 설치해야 한다. (참고 : https://github.com/tensorflow/tensorflow/issues/8161)
비디오카드마다 지원되는 CUDA 버전이 다르므로 아래 사이트에서 확인해야 한다.

http://developer.nvidia.com/cuda-gpus

Python 버전

64Bit만 지원하므로 Python 32bit을 사용했었다면 지우고 다시 설치해야 한다.
Python은 3.5만을 지원하므로 3.6도 안되고 3.4도 안된다.

Anaconda 버전

Anaconda는 최근 버전을 설치해도 무방하지만 python 버전 정보를 3.5로 입력해 주어야 한다.

conda create -n tensorflow python=3.5

pip 실행 시 오류 발생하면 앞에 python -m pip 라고 python을 통해 실행하게 한다.
가속기 지원하지 않는 tensorflow 설치 시, Python콘솔에서 tr.Session()으로 세션 생성 하면 아래와 같은 warning 메시지가 발생하나 문제는 아니다. warning을 끌 수 있으나 끄는 것이 귀찮아 그냥 두는게 낫겠다.

The TensorFlow library wasn't compiled to use SSE instructions, but these are available on your machine and could speed up CPU computations.

그누보드5에서 아이코드 SMS 로그인이 안될 때

이도운 — Wed, 10 May 2017 11:35:00 +0900

그누보드5에서 아이코드(www.icodekorea.com)와 연동하여 SMS를 사용자들에게 전송할 수 있다.

그런데 아이디와 비번을 바르게 입력하였는데도 인증이 되지 않는 경우가 있어 한참 고생하였다.

원인은 간단했는데, 패스워드 길이 문제였다.

아이코드에서는 패스워드에 10자 이하의 길이 제한이 있다고 안내하고 있으나, 홈페이지에서 회원 가입 시 10자보다 더 길게 입력되고 로그인도 잘 된다. 따라서 비밀번호를 10자 이내로 줄이고 그누보드에서 연동 시 정상 작동함을 확인하였다.

검색을 많이 했지만 나오지 않아 특별히 블로그에 포스팅을 남긴다...

[책] 월급 역전

이도운 — Wed, 26 Oct 2016 06:36:03 +0900

'월급 역전'이라는 책을 읽었습니다. 저자인 신우익 님은 필립스 코리아의 인사 총괄 상무로, 인재 관리를 하는 헤드에 있는 사람입니다. 이런 분은 어떤 생각을 가지고 사람을 선택하고 어떤 사람이 되기를 바라는지 궁금하였고 이 책을 통해 알게 될 것을 기대하였습니다. 특히 목차만 보고 맘에 들어 선택하였습니다.

회사 선택과 이직, 면접에서부터 시작하여 회사 생활을 잘 하는 방법, 팀장과 같은 매니저로 성장하였을 때 어떤 전략을 취할 것인가에 이르기까지 회사에서 겪을 수 있는 다양한 이슈들을 예시와 함께 설명하고 방향을 제시하여 줍니다. 전에 읽은 '18년이나 다닌 회사를 그만두고 후회한 12가지'가 회사를 다니면서 가져야할 마음가짐에 대한 책이라면 이 책은 좀 더 분석적으로 전략을 수립하여 알려주는 실용서에 가깝습니다. ^^ 책 마지막 날개부분에 간단히 전략이 요약되어 있어 첨부해 보았습니다.

뒤쪽 날개에 인쇄된 14가지 연봉 향상 전략

예전부터 알던 이야기들도 많았지만 이 책을 통해 정리하고 지나갈 수 있어 좋았습니다. 회사를 고를 때에는 어떤 점을 생각해야 할지, 단순한 연봉만 생각해서는 안된다는 이야기, 면접할 때 주의할 점들은 어느정도 알고 있는 내용이지만 한 번 짚고 넘어가기에 좋은 이야기였어요. 새롭게 알게된 부분들도 많았는데, 업무중이나 메일을 쓸 때 어떤 문장을 피하고 단어를 선택해야 하는가에 대해서는 누가 가르쳐 주지 않았었기 때문에 주의 깊게 읽어보았습니다.

지금 제게 중요한게 '성장'이라 성장 전략 부분에 관심이 갔는데, 저자는 부족한 경험은 책을 통해 채우라고 합니다. 이 책의 마지막 부분에서는 회사원들이 읽으면 좋을 책들을 소개하기도 합니다. 요즈음 책을 여럿 읽었지만 완전히 나의 것으로 받아들였다고 말하기에는 자신감이 없는 경우가 많았습니다. 때문에 어떻게 해야 내 역량이 되었다고 할 수 있을까 고민이 많았죠. 그런데 저자는 아래와 같이 간단히 정리해 주네요. 무릎을 탁 치고 공감하게 되었습니다.

단기간에 습득한 정보는 단순한 정보일 뿐이다. 머릿속에 있는 정보가 업무에 활용될 때 비로소 경험이 되고, 경험이 쌓이면 역량이 된다.

상사와 일하는 방법도 재미있었습니다. 과거의 나의 상사들이 생각나면서 그분들의 특징과 장단점을 떠올려 봤습니다. 별 생각 없이 지나친 과거였을 뿐인데 이 책에서 이야기하는 상사의 중요한 항목들을 참고하면서 내가 그들에게 잘 했던점, 잘 못했던 점들을 되돌아보고, 그 분들이 상사로서 했던 여러 사례들을 떠올려보게 되네요. 사람을 대하는데 있어서 좀 더 주의깊게 생각해가면서 커뮤니케이션을 해야겠다는 마음이 들었습니다.

다양성 전략 챕터에서는 '다른 문화권 사람들과 일하는 방법'에 대한 부분이 인상적이었습니다. 아래와 같은 표를 보여주며 문화권마다 성향이 다르니 다른 대응이 필요하다고 이야기합니다. 다양성에 대해서는 나름 열려있다고 생각했는데 사실 이를 발휘하거나 객관적으로 평가해 본 적은 없었던 것 같아 곰곰히 생각해 보게 되었습니다. 회사에도 외국 국적의 인력들이 조금씩 증가하고 있고 요즈음엔 한국인들도 많이 외국으로 진출하고 있어 팀웍을 향상시키기 위해서는 맞춤형 전략이 필요할 것이란 생각이 듭니다.

다른 문화권 사람들과 일하는 방법, 국가별 성향 도표

아래 그림은 경력 개발이 잘 되고 있는지 네가지 측면에서 생각해보는 그림입니다. 네가지 부분인 열정, 역량, 조직 문화, 직무 중 하나만 줄어들더라도 교집합 부분인 경력 개발이 매우 작아지게 됩니다. 내 경력을 네가지 측면에서 바르게 투자되고 있는지 생각해 보고 올바른 경력 개발이 되고 있는지 생각해보았습니다. 요즘엔 제 열정도 줄었고 사내의 조직 문화도 그다지 좋지 못합니다. 나아가 조직문화를 개선해 보려는 열정도 식어있다고나 할까요... 이대로라면 제대로 경력 개발이 되지 않고 있다는 생각이 들어 빠른 시일 내에 추스리고 방향을 찾아보려 합니다.

경력 개발이 효과적으로 되려면...

그밖에도 여러가지 좋은 내용이 많았지만 다 나열하기는 어려울 것 같습니다. 분석적으로 책을 써 내려간 점이 인상적이고 그런 사고방식을 배워야 할 것 같다는 생각이 듭니다. 그리고 책의 주요 주제에 대해 글로써 정리해 보면서 나만의 전략을 짜 볼까 합니다. 정리하고 다시 읽어보고 실천하여 저자가 위에서 이야기 한 것과 같이 나만의 역량으로 만들어 보려 합니다.

여러가지 주제를 이야기하다보니 어떤 부분은 좀 더 자세히 설명해 주었으면 하는 부분들이 있었습니다. 이직에 대한 책은 별로 없어서 신선하였으나 좀 더 자세하게 이야기 해 주셨으면 하였고, 다양성 전략도 좀 더 다양한 이야기를 듣고 싶었습니다. 팀의 중간쯤에 위치한 사람으로서의 전략은 어떤 것이 좋을지도 궁금하였는데 따로 언급은 없었습니다.

월급 역전: 국내도서; 저자 : 신우익; 출판 : 한빛비즈 2016.08.30

상세보기

[책] 18년이나 다닌 회사를 그만두고 후회한 12가지

이도운 — Thu, 20 Oct 2016 06:36:07 +0900

'18년이나 다닌 회사를 그만두고 후회한 12가지'라는 제목이 인상적이라 오래 전에 구매했다가 조금 읽고 말았었는데, 요즘 마음이 뒤숭숭하여 처음부터 다시 읽어 보았습니다. 저자가 회사를 그만두고나서 후회가 되었던 점들을 담담하게 적어내려가는데, 어떤 점들은 나의 모습과 겹쳐 보여지기도 해서 마음에 와 닿기도 하였습니다.

목차는 아래와 같습니다. 전체적인 책의 주제는 회사를 다니는 동안에는 주어진 일에 최선을 다해 임하라는 것 입니다. 말은 간단한데 쉽지 않은 이야기예요. 거의 '중용'과 같은, 회사 내에서 회사원이 취할 수 있는 최고선을 추구해야 한다는 겁니다. 맘에 안드는 상사에게도 잘하고, 주변 사람과 어울릴 수 있는 운동을 하고, 창의적이기 보다는 건실해야 한다는 등의 이야기를 합니다. 각자의 개성은 최소화 하고 회사의 성공을 위해 매진해야 한다는 것은 요즘의 개인주의의 사람들에게는 쉽지 않은 이야기입니다.

책의 목차

그러나 여러면에서 많이 생각해보고 자신을 되돌아보는 계기가 되었습니다. 회사 생활을 하면서 뚜렷한 목표가 없이 현재 맡아 하고있는 일만 오래오래 할 수 있겠다고 생각했던 것들에 대해 다시 생각해 보게 되었습니다. 더 높은 곳을 추구하여도 되었을터인데, 그랬더라면 미리 준비를 많이 했을 것이었고 놓쳐버린 좋은 기회들도 많았음에 후회가 되었습니다. 영어 점수를 미리 높여 놓았더라면 얻을 수 있었던 기회들, 알고리즘 공부를 체계적으로 해 두었다면 받았을 상들과 해외 연수 기회 등, 현 직장에서 스쳐 지나간 좋은 기회들이 떠오르네요.

사내 인간관계에 대해서도 반성하게 되었습니다. 좀더 주변 사람들과 친하게 지내고 위아래 사람들에게 살갑게 해 줄 수도 있었을 터인데 그러지 못한 점들이 아쉽습니다. 주변 사람들에게 인간적으로 어떤 평가를 받고 있을지.. 고칠 수 있을지는 모르겠지만 노력해 볼까 합니다.

그리고 9장의 '신념을 버렸어야 했다'는 이야기가 가장 인상적이었습니다. 사람들은 누구나 양보할 수 없는 '신념'을 자랑스레 말하는데, 저자는 이 신념을 과거의 성공 경험을 크게 부풀려 받아들인 바람에 마음에 굳게 박혀버린 옹고집이라고 이야기합니다. 이러한 신념 때문에 신념과 충돌하는 선택에 대하여서는 보편 타당한 것이더라도 격렬히 반대하는 자세를 취하게 된다는 것입니다. 때문에 저자는 '신념 있는 사람'이라는 말을 들으면 '완고한 사람'이라고 돌려 말하는 것이라 이해하고 고쳐야 한다고 이야기 합니다. 제 자신도 간혹 특정 사안에 대해 반대하는 입장을 취하면서 시니컬하게 비난한다던가 고집을 부리기도 하는데, 그런 점들이 신념이나 편견으로 자리잡은 것에서 비롯되지는 않았나 곰곰히 생각하면서 살아볼까 합니다.

저자는 지금은 작은 사업을 하면서 만족한다고 합니다. 구제 기모노를 취급하며 인터넷으로도 판매하는 상점이라고 하는데, 가족들과 함께 경영을 하면서 가족과도 사이가 좋아지고 만족스럽다고 합니다. 큰 회사에 집착하여 아웅다웅 스트레스 받으며 일하는 것 보다 개인의 강점을 살려 작은 사업을 하는 것도 좋은 모습인 것 같습니다. 특히 가족이 함께 한다는 것, 가족과 화목해졌다는 것이 무척 인상적입니다.

현재 주어진 일에 최선을 다하고, 아닌것 같다면 과감히 길을 바꾸라는 것이 저자의 조언이었습니다.

18년이나 다닌 회사를 그만두고 후회한 12가지: 국내도서; 저자 : 와다 이치로 / 김현화역; 출판 : 한빛비즈 2015.09.10

상세보기