반응형

시간위를 걷는 프로그래밍 (Programming Over Time)

- 소프트웨어 엔지니어링: 코드를 작성하는 행위에 더하여, 시간의 흐름에 발맞춰 한 조직이 코드를 구축하고 유지보수하는 데 이용하는 모든 도구와 프로세스 포괄

- 시간이 흐르면 -> 변경 발생, 규모 증가, 조직 성장
                             (아키텍처링, 설계, 코딩 시 이러한 변화에 따른 비용과 트레이드오프를 고려해 의사결정)

 

 

소프트웨어 엔지니어라면

- 코더 < 프로그래머 < 개발자 < 소프트웨어 엔지니어

- 흐르는 시간 위에서 순간순간의 프로그래밍을 합산한 것

 

 

★ 자신의 현 위치와 처한 상황을 파악하고, 한 걸음 내딛으려면 무엇 무엇이 필요하고 무엇이 우선순위인지 고민해주세요.

 

 

시간은 변경을 가로 막는다

하이럼의 법칙

- API 사용자가 충분히 많다면 API 명세에 적힌 내용과 상관없이, 시스템에서 눈에 보이는 모든 행위(동작)를 누군가는 이용하게 될 것이기 때문이다.

-> 제품이 성공할 수록 (더 오래 살아남고 더 많은 이가 사용할수록) 변경하기가 어려워진다.

 

 

규모가 확장돼도 개발 효율을 유지하려면?

- 전문성: 여러 방법에 대한 충분한 지식 쌓기

- 안정성: 짧고 규칙적인 릴리스로 릴리스 사이의 변경량 줄이기 (Faster is safer!)

- 순응: 거의 모든 코드가 업그레이드를 경험해봄

- 익숙함: 정기적으로 업그레이드하는 과정에서 중복 작업을 찾아 자동화 하기

- 정책: 비욘세 규칙과 같은 유용한 정책과 절차 갖추기

 

 

★ 100m 달리기만 해서는 마라톤을 뛸 수 없다. 엔지니어들에게 지구력도 함께 키울 여유를 주자.

 

프로그래밍 vs. 소프트웨어 엔지니어링

- 프로그래밍: 코드를 생산하는 즉각적인 행위

- 소프트웨어 엔지니어링: 활용 가치가 남아 있는한 오랫동안 코드를 유용하게 관리하고 팀 간 협업을 가능케 하는 정책, 관리, 도구 모두를 아우르는 종합개념

 

 

천재 vs. 팀

- 우상을 찾고 흠모하는 건 사람의 본능이라 많은 사람이 자신도 누군가의 우상(천재)이 되고 싶어 함

- 천재만 부각되어 '팀'의 중요성이 묻히고 불안과 잘못된 문화 조성 '나를 바보라고 생각하면 어떡해? 완성 전의 코드는 숨겨야 해!'

- 진실은 위대한 업적은 결국 팀이 이루어 냄

천재 신화 진실 (더 중요한 일)
리누스 리눅스 커널 개발 수천 명의 인재들이 협업하여 지속적으로 개선하도록 이끔
귀도반 로섬 파이썬 개발 첫 번째 버전 이후로는 수천 명이 직간접적으로 참여하여 개발
빌 게이츠 PC용 베이식 언어 인터프리터 개발 마이크로소프트라는 회사를 일굼
마이클조던 약팀의 선수로 데뷔하여 NBA 6회 우승을 이끔 필 잭슨 감독이 조던을 중심으로 드림팀 구성

 

 

모든 건 팀에 달렸다

초월적인 업적 대부분 위대한 팀이 이루어낸다.

비전을 공유하고, 역할을 나누고, 다른 이로부터 배우며 멋진 팀을 만들자.

 

위대한 팀

- 겸손(Humility): 당신은 모든 것을 알지도, 완벽하지도 않다. 겸손한 사람은 배움에 열려 있다.

- 존중(Respect): 동료를 진심으로 생각한다. 친절하게 대하고 그들의 능력과 성취에 감사해한다.

- 신뢰(Trust): 동료들이 유능하고 올바른 일을 하리라 믿는다. 필요하면 그들에게 스스로 방향을 정하게 해도 좋다.

 

신뢰가 그냥 생기지는 않는다.

- 신뢰할 수 있는 사람 뽑기

- 스스로 신뢰받을 수 있게 행동하고 노력하기

- 신뢰할 수 있는 사람으로 키워내기

 

 

위대한 팀 만들기

겸손, 존중, 신뢰 실천하기

 

자존심 버리기

- 개인의 자존심보다 집단적 자존심을 높이려 노력하자 (팀의 성취와 단체의 자부심)

비평하고 비평받는 법 배우기

- 선의의 비평이라도 사전 조율과 공감 없이는 맹렬한 공격이 될 수 있다.

- 동료를 존중하며 건설적이고 공손하게 비평하는 법을 배워야 한다.

- 전문적인 제도와 문화가 큰 도움이 된다. (예: 코드 리뷰, 멘토링)

빠르게 실패하고 반복하기

- 실패를 '배우고 다음 단계로 넘어갈 수 있는 절호의 기회'로 생각하는 문화 필요

비난 없는 포스트모템(사후 검토) 문화 만들기

- 담겨야 할 내용: 배운 것, 배운 것을 토대로 앞으로 바꿀 것

- 담기면 안 되는 내용: 사죄, 변명, 지적

 

 

지식 공유 = 함께 자라기

왜 공유하는 가?

- 초심자를 전문가로 키워내기

- 조직 규모와 문화에 적합한 지식 공유 방법 찾기

- 전문가가 빠져도 굴러가는 팀(프로젝트) 만들기

 

지식이 제대로 공유되려면?

- 전문가

- 지식 전파 매커니즘

- 배움의 문화

 

 

심리적 안전이 가장 중요

- 심리적 안전: 모름을 인정하는 게 부끄럽다거나 모름을 알린다 하여 불이익이 생기지 않는다는 믿음

- 질문에 답하는 자세가 중요 (No! 2년차쯤 됐으면 그 정도는 알아야지, 저번에도 알려줬잖아요...)

 

개인 차원에서는

- '질문하는 자가 가장 빠르게 성장'함을 기억하고, 굴하지 말고 꾸준히 질문하자

- 질문 노하우 쌓기

   - 항상 공손하게

   - (잘 답해주는) 전문가 찾기

   - 질문이 특정인에게 집중되지 않도록

   - 적절한 보담 (칭찬과 인정, 커피 사기, 성장 후 감사 ..)

- 나부터 잘 답해주기

 

 

 

직원 성장의 책임은? 개인 or 조직

- 장기적으로 조직의 성패는 인재를 얼마나 잘 키워내느냐에 달려 있다.

 

리더의 역할

- 주변인 성장 이끌기

- 팀의 심리적 안전 개선

- 팀워크와 협업 문화 조성

- 팀 내 긴장 해소

- 조직 문화의 가치 설정

- 더 활기차고 신나는 일터로 가꾸기

 

직원 성장에 '관심이 큰' 조직이라면?

- 긍정적인 자세로 협력, 아이디어 적극 제시

- 개인과 조직은 우선순위가 서로 다를 수 있음을 감안

- 급격하고 일방적인 변화는 역효과 -> 공감대 형성, 완급 조절

 

직원 성장에 '관심 없는' 조직이라면?

- 작게 시작하기 (나와 내 주변만이라도 성장할 수 있는 방법 찾기)

- 꾸준히 실천하기

 

 

어떤 사람이 리더가 되어야 하느냐

- 경영진은 이 차이를 잘 고려하여 리더 역할을 잘 할 사람을 리더로 선출해야 함

- 리더로 성장하고 싶다면 사회적 스킬도 갈고 닦고 어필하여 리딩도 잘할 수 있음을 보여줘야 함

팀원(개인 기여자) 역할 리더 역할
설계
코딩
문서화
디버깅
...
팀에 활기 불어넣기
생산성 높이기
팀 섬기기 (섬기는 리더십)
겸손, 존중, 신뢰 분위기 조성
사회적 건강 관리 (팀원 멘탈 케어, 동기 부여, 팀원 간 갈등 중재...)
기술적 건강 관리 (필요한 기술/인프라 확보 ...)

 

 

리더 역할을 나누는 이유

리더가 한 명일 경우

- 팀 내 '모든' 일을 관장

- 부작용

   - '모든' 일 -> 세분화/전문성 부족

   - 우선순위 (일정 >> 기술 >>>> 팀원 케어 - 전체 비용 요소 중 가장 큰 비중을 차지)

 

행 (긴급도) / 열 (중요도)

2순위 - 중요하지만 급하지 않음 (팀원 케어 위치) 1순위 - 중요하고 급함
4순위 - 중요하지도 급하지도 않음 3순위 - 중요하지 않지만 급함

 

 

 

성공적인 리더가 되기 위한 조언 1

안티패턴 올바른 패턴
만만한 사람 고용하기
저성과자 방치하기
사람 문제 무시하기
만인의 친구 되기
채용 기준 타협하기
- 적합한 사람을 찾는 비용 << (뽑지 말았어야 할 직원 관리비용 + 무너진 신뢰 복구 비용)
팀을 어린이처럼 대하기
- 마이크로매니징
- 어떻게 까지 모든 일을 자시이 겨정
- 과잉친절
자존심 버리기
마음 다스리기
촉매자 되기
장애물 치우기
선생이자 멘토되기
- 주의: Too Much Talker 되지 않기
명확한 목표 세우기
정직하기
- 거짓말은 대부분 들통 남 (모르는 척할 뿐) -> 신뢰 무너짐
- 칭찬 샌드위치 주의
행복한지 확인하기

 

 

 

성공적인 리더가 되기 위한 조언 2

구글이 리더에게 권장하는 그 외 조언과 요령

- 위임하되, 곤란한 일은 직접 처리

- 여러분을 대신할 사람 찾기

- 파도를 일으켜야 할 타이밍 알기

- 혼란으로부터 팀 보호

- 팀에 공중 엄호

- 팀이 잘하고 있다면 칭찬하기

- 실패해도 쉽게 되돌릴 수 있는 일에는 '해보세요'라고 말하기 (할 수 있는 '여건'을 만들어주는 일까지)

 

외적 동기 < 내적 동기 (즉, 행복)

내적 동기 부여 방법

- 자율성(주도성) 부여 (원하면 기획 회의에도 참여할 수 있는 문화)

- 목적(일의 의미) 인식 (구현해야 할 기능뿐 아니라 의미도 공유)

- 숙련(전문성 향상 -> 성장) 기회 제공 (OKR, KPI 등에서 개인 목표 설정 시 개개의 직원이 바라는 성장 방향까지 고려하자.)

 

 

더 읽어보기: https://brunch.co.kr/@wegra/12

반응형
반응형
  • 점검 내용
    • DBA 계정의 Role을 Public으로 설정하는지 점검

 

  • 점검 목적
    • DBA 계정의 Role을 점검하여 일반 계정으로 응용프로그램 테이블이나 DBA 테이블의 접근을 차단하기 위함

 

  • 보안 위협
    • 응용프로그램 또는 DBA 계정의 Role이 Public으로 설정되어 있으면, 일반 계정에서도 응용프로그램 테이블 및 DBA 테이블로 접근할 수 있어 주요 정보 유출 위험이 존재함

 

  • 판단 기준
    • 양호: DBA 계정의 Role이 Public으로 설정되지 않은 경우
    • 취약: DBA 계정의 Role Public으로 설정되어 있는 경우
  • 점검방법

 

 

  • 점검 및 조치 방법 
    • DBA 계정의 Role 설정에서 Public 그룹 권한 취소
      • MSSQL
        • 1) 각 Object의 사용 권한이 불필요하게 Public, guest 권한이 부여된 경우 제거
        • revoke [권한] on [Object] from public | guest;
      • MySQL 해당사항 없음

 

  • 조치 시 영향
    • 일반적인 경우 영향 없음
반응형
반응형

아침에 일어나는 게 이렇게 무겁고 힘들다는 걸 생애 처음 알게 된 것 같다.

그저 늦잠이라고 표현하기에는 조금 다른 그런 느낌이다.

 

2월달까지 새벽 5시에 일어나서 무언가를 했다는 게 믿기지 않을 정도니 말이다.

 

우울증 검사 결과를 확인해봐야 알겠지만 말이다.

나는 우울증인거 같다.

 

하루 종일 무기력한 표정과 나날들.

무언가를 손에 잡을 듯 잡을 수 없는 그런 느낌들.

 

하루가 나에게 짧은 듯 긴 듯한 이 느낌.

 

처음엔 번아웃인가 싶었지만 이 깊은 수렁은 아닌 거 같다.

 

어떻게 나는 이 굴레를 벗어나야 할지 잘 모르겠다.

반응형

+ Recent posts