2일
13일
17일
- 스타트업에서의 모던 스태프 엔지니어링을 보고서 든 생각
-“내가 하고 있는 일이 무엇인가?” 에 대한 인사이트를 준 발표 였음.
- 나는 Platform Engineering 과 Staff Engineering 두가지 다 하고 있음.
- 다만 내가 일하고 있는 조직은 여러 스타트업의 묶음과 대기업의 중간 단계정도의 조직임.
- Platform Engineering 을 sidejob 으로 할 수는 없음.
- 여러 조직에서 공통된 Platform 을 사용하고, 이를 전문적으로 제공해야 함.
- Staff Engineering 은 업무 중 일부의 시간에만 하고 있음.
- 비율로 따지자면, 일주일중 3~4시간 즉 10%정도만 해당 업무에 사용함.
- 속한 조직이 작았을때는 비율이 더 높았으나 점점 줄어 들고 있음.
- Devops 는 이전에는 역활을 수행했으나 지금은 수행하지 않음.
- 전체 Product의 규모가 늘어나면서 전문적인 운영 인력이 필요해졌기 때문임
- 이것이 devops의 실패를 의미하지 않음, 단지 “내가” 그 일을 더이상 수행하지 않을뿐.
- 나는 이 글을 보고서야 소속감을 느낄수 있었음.
- 그 전까지는 조직에 온전히 소속되어 있기 보다는 내가 외부의 “컨설던트”에 가깝다고 느꼈음
- 조직에 인사이트를 공급하면서도, 직접적인 구현을 하기 보다는 방향 제시만 담당하며 그렇다고 Product에 대한 책임을 갖거나 방향을 변경을 할 권한이 없었음.
- 이제는 그것이 원래 존재하는 업무이며, 단지 내가 보고 들은 범위내의 조직에서는 암시적으로 sidejob 으로 하고 있었을 뿐이라는 것을 깨달음.
- 그래서 이런 직무나 직책, 역활을 나타내는 말이 없었음.
- 나는 단지 그 업무를 조직내에서 전담해서 수행하는 몇 안되는 직원일 뿐이며, 외부에서 와서 조언을 해주는 컨설던트가 아님.
18일
- IP ACL 은 더이상 안전하고 좋은 “인증” 수단이 아니다.
- IP ACL은 단순한 Filter 일 뿐이지 하나의 서버에 고정적으로 부여된다고 볼수 없다.
- 특히 AWS 등의 Cloud 에서는 LoadBalancing 등을 위해 IP 를 동적으로 변경 함.
- 부하가 늘어나면 Domain에 mapping 되는 IP 주소를 늘려서 대응하는등..
- IP 가 긴 호흡으로 바뀌지 않는다고 가정하는 IP ACL 은 이러한 변화에 대응할수가 없다.
- 따라서 IP ACL 은 서버 하나하나에 대한 확실한 주소가 아니라, 신뢰할수 없는 주소를 빠르게 걸러내는 필터로 작용 해야 한다.
- eg) IDC 내부 Traffic 만 허용하기 위해 10.0.0.0/8 대역만 허용. 허용하는 대역에서 온 Traffic 이더라도 TLS Cert 등 추가인증 수단 사용
- 그럼 “인증”으로써의 IP ACL의 대체재는 무엇인가?
- TLS Cert , 혹은 Server에 발급하는 Token(expire 기간이 있는..)
- 참고: https://joelgsamuel.medium.com/ip-address-access-control-lists-are-not-as-great-as-you-think-they-are-4176b7d68f20