Eunice Hong

커뮤니케이션 스킬 레벨업

48 min read

Header

들어가기

요즘 어느 회사든 개발자를 채용할 때 “커뮤니케이션” 역량을 요구한다. “개발자 커뮤니케이션”이란 도대체 무엇일까? 단순히 코드를 알아보기 쉽게 쓰는 것만을 의미하지는 않을 것이다. 개발 지식과 노하우 외에 개발자가 갖춰야할 커뮤니케이션 능력에 대한 내 안의 정의를 명확히 하고자 위 강의를 듣게 되었다.

읽고 나서

강의를 듣고, 내가 개발자로서 갖추어야할 역량은 배려심이라는 결론을 내렸다.

우선, 코드나 프로젝트를 설명하는 다이어그램을 작성하는 것부터 배려가 바탕이 되어야 한다. 책에 따르면, 독자를 고려하여 색상을 선택부터 다이어그램의 구조, 표기법, 레이블, 범례, 심지어는 이모지 사용까지 모두 배려해야한다.

돌이켜보면, 다른 동료가 그려놓은 다이어그램이 거미줄 문제를 가지고 있어 이해하기 어려웠던 경험이 있다. 나 또한 많은 정보를 한 다이어그램에 넣고 싶고, 그러다 보니 다양한 요소간 관계를 표현하기 위해 선을 많이 사용하게 되는 일이 자주 있었다.

문서를 작성할 때도 마찬가지다. 내가 하고 싶은 말을 내용으로 삼되, 형식은 독자 및 커뮤니케이션에 참여하는 모든 사람들에게 친숙한 방식으로 작성해야한다. 피라미드 구조로 글쓰기를 통해 내용을 구조화하고, 단락 구성원칙을 준수하여 읽기 쉽게 작성해야한다.

비동기 소통을 할 때에도, 상대방의 시간을 존중하고 내가 전달하고자 하는 내용을 명확히 하는 메시지 인코딩하기를 해야한다.

결국, 개발자로서의 배려심은 단순한 매너 이상의 가치를 지니고 있다는 것을 깨달았다. 내가 작성한 코드, 다이어그램, 문서, 그리고 메시지가 모두 누군가에게 전달되고 해석된다는 점을 잊지 말아야겠다. 이 과정에서 배려는 단순히 상대방을 고려하는 데 그치지 않고, 내 작업 결과물의 품질을 높이고 팀워크를 강화하는 중요한 도구가 된다.

앞으로는 내가 작성하는 모든 산출물에 “독자를 위한 배려”를 담는 습관을 길러야겠다고 다짐한다. 작은 배려가 더 나은 협업과 결과를 가져온다는 것을 기억하며, 이 강의에서 배운 내용을 실천으로 옮길 준비를 해본다.

참고 도서

강의 노트

2. 난잡함 정리하기

색상 과부화 문제 피하기

  • 컬러 팔레트 최소화, 메시지 전달에 필요한 색상만 사용한다.
  • 색상별 의미를 정의한다.
    • 기능을 공유하는 구성 요소끼리 동일한 색상을 사용하게한다.
    • 함수 혹은 객체의 유형을 나타낼 때 색상을 사용한다.

상자 속 상자 속 상자 문제 피하기

상자 속 상자 속 상자

다양한 내용을 동일한 형태의 상자로 중첩하여 표현

  • 상자 이외의 다른 표현방법을 고려한다.
    • 컴포넌트에 레이블 추가한다.
    • 상자의 윤곽선과 배경의 색상 및 패턴 재활용한다.
  • 불필요한 세부 사항 제거, 다이어그램을 여러개로 분할한다.
  • 공백을 활용한다.
    • 눈이 쉴 공간을 제공하고, 인지 부하를 줄여 다이어그램 시인성을 향상시킨다.

관계 거미줄 문제 피하기

관계 거미줄 문제

다이어그램에서 관계를 나타내는 선이 복잡하게 얽힌 상태

  • 관계를 나타내는 화살표를 직각으로 변경한다.
  • 레이블 위치를 조정한다.
    • 관계의 시작부분이나 선의 중간에 배치한다.
    • 직각인 위치에서 멀리 두거나 다른 레이블에서 멀리 배치한다.
  • 두 선이 겹치지 않음을 명확히 표시하기 위해, 선 점프(line jump) 를 사용한다.
  • 필요 시, 다이어그램을 분할한다.

텍스트 균형 잡기

  • 일부 정보를 텍스트 또는 표 형식으로 변경한다.
  • 문장으로 작성된 정보는 축약하거나 별도의 텍스트로 작성한다.
  • 관계형 데이터는 표로 표기한다.
  • 메시지 전달에 필요하지 않은 정보는 모두 제거한다.
  • 필요한 경우 다이어그램을 사용하도록 한다.

3. 접근성

접근성

모든 독자가 메시지를 완전히 이해할 수 있는 상태 일시적 또는 영구적 장애가 있는 사람뿐만 아니라 모든 독자를 위한 것

주요 고려사항

  • 다양한 독자층: 지식 수준, 비즈니스 기능, 제품 또는 도메인에 대한 친숙도가 다양한 사람들
  • 상황적 요인: 사용중인 화면 크기, 정보를 소비하는 시간

색상에 의존한 소통 해결하기

색상에 의존한 소통

의미를 나타내기 위해 색상만을 사용하는 것

  • 다이어그램에 요소에 면적이 있는 경우, 패턴을 넣어 사용한다.
  • 레이블이나 기호를 활용한다.
    • 예를 들어, +와 - 등이 있다.
    • 단, 문화적 맥락을 고려해야한다.
  • 채도가 다른 색상을 사용하도록한다.

범례 사용하기

범례

다이어그램의 요소와 의미를 설명한다.

범례의 이점

  • UML에 익숙하지 않은 독자도 다이어그램을 이해할 수 있다.
  • 기술적 세부사항을 명확히 전달할 수 있다.

고려사항

  • 내용의 적절성
  • 배치의 중요성
  • 글꼴 선택
  • 정보량
    • 과도한 정보 포함 지양
    • 부족한 정보로 인한 혼란 방지

레이블 사용하기

주의사항

  • 필요한 정보만 간결하게 보여준다.
  • 레이블이 어느 요소를 설명하는지 명확히 표시해야한다.
  • 유사한 요소에 대해 일관된 레이블을 사용한다.
  • 접근성 고려 폰트 사용. 예를 들어 Atkinson Hyperlegible Font 가 있다.

참고사항

4. 내러티브

효과적인 다이어그램은 독자를 순차적으로 이해 가능한 스토리를 담고 있어야한다.

큰 그림 우선 패턴

큰 그림 우선 패턴

내러티브의 순서를 정할 수 있도록 돕는다.

주요 원칙 전체적인 구조 및 목적을 설명한다.

  • 큰 그림을 모르면 세세한 내용은 혼란스럽거나 지루할 수 있다.

다이어그램 흐름을 기대에 맞추기 패턴

다이어그램 흐름을 기대에 맞춘다?

정보의 흐름을 독자의 예상과 일치시킨다

독자의 주요 예상

  • 시작 위치는 왼쪽 상단 또는 왼쪽 가운데에서 시작한다.
  • 위에서 아래, 왼쪽에서 오른쪽으로 진행한다.
  • 편집이나 재정렬이 불가능한 경우, 시작 위치에 레이블이나 기호를 추가한다.
  • 시작, 중간, 끝을 명확히 구분한다.

구조 다이어그램

  • 일반적인 배치
    • 액터 또는 사용자: 최상단
    • 시스템 및 컨테이너: 중간
    • 인프라 요소: 맨 아래
  • 계층화된 아키텍처 다이어그램
    • 논리적으로 위에서 아래로 배열한다.
    • 사용자 인터페이스나 API 레이어를 최상단에 배치한다.

명확한 관계 패턴

주요 원칙 단방향 관계 표현을 주로 사용하도록 한다.

  • 양방향 화살표는 실제로 양쪽 방향에서 동일한 프로세스가 발생하는 경우에만 사용한다.

5. 표기법

다이어그램 표기법

  • UML: 통합 모델링 언어
  • BPMN: 비즈니스 프로세스 모델링 표기법
  • 그 외 비표준 표기법

아이콘 소통 피하기

  • 아이콘은 정보 전달의 보조 수단으로만 사용해야한다.
  • 아이콘 제거 시에도 의미가 전달되어야한다.
  • 아이콘과함께 명확한 레이블과 텍스트를 병행해야한다.
  • 모든 독자가 아이콘의 의미를 이해한다고 가정하면 안된다.

불필요한 UML 사용 피하기

  • 모든 독자가 UML 다이어그램을 이해한다고 가정하면 안된다.
  • 작성 및 업데이트에 많은 시간이 소요될 수 있다.
  • 애자일 환경에서 빠른 구식화를 고려해야한다.
  • C4 등을 대안으로 사용한다.

동작과 구조 분리하기

다이어그램에도 단일 책임 원칙을 적용하자!

  • 구조 다이어그램: 시스템 간 관계, 하드웨어/소프트웨어의 물리적 위치 표시
  • 동작 다이어그램: 데이터 흐름, 시스템 내 상태 변화 표현

독자의 예상에서 벗어나지 않기

  • 독자의 기대나 통념을 무시하는 다이어그램은 혼란을 야기하고 메시지 전달력을 저하시킨다.
  • 독자의 멘탈모델을 고려하여 다이어그램을 작성해야한다.
  • 예상을 벗어나는 요소를 사용하기 위해서는 명확한 정당성이 필요하다.

예시

  • 색상: 빨간색(위험, 행운 등 다양한 의미로 해석이 가능하다.)
  • 도형
    • 삼각형: 행동, 역동성을 나타낸다.
    • 정사각형, 직사각형: 신뢰/질서를 나타낸다.

6. 문장의 구성

다이어그램의 가독성

  • 적절한 캔버스 크기와 비율을 사용해야한다.
    • 16:9, 16:10 을 권장한다.
  • 화면에 맞는 다이어그램을 작성해야한다.
  • 한 방향으로 너무 긴 다이어그램은 분할하여 별도의 슬라이드로 나타낸다.

스타일 커뮤니케이션

메타스타일

시각적 요소를 통한 메타 메시지를 전달한다.

불문명한 문장 구성 피하기

  • 차트 작성 시, 동일하거나 명확한 척도를 사용하여 독자의 해석에 혼란을 주면 안된다.
  • 논리 다이어그램에서 각 요소가 동일한 단계를 나타낸다면, 동일한 크기로 표현해야한다.

7. 서면 커뮤니케이션

서면 커뮤니케이션의 형태

  • 이메일
  • 유구사항 문서
  • 보고서

기본 원칙

  • 단순한 언어와 어휘를 사용하여 이해도와 의사소통 효율을 높인다.
  • 풍자와 관용구 사용을 자제해야한다.
  • 적절한 여백과 구조화된 텍스트를 만들어야한다.

축약어 사용

축약어 지옥 (Acronym Hell)

정의되지 않은 축약어 사용으로 발생하는 혼란 예. API에서 발생한 CSRF 이슈를 ASAP 해결해야한다.

피라미드 구조로 글쓰기

민토 피라미드 원칙

1960년대 바바라 민토가 개발한 정보 구조화 방법으로, 중요한 아이디어를 상위에 배치하고 하위에는 구체적인 정보와 세부 내용을 논리적으로 배치한다.

주요 구문 규칙

강동사 지향하기
  • 약동사:
    • ‘있다’, ‘하다’, ‘되다’, ‘이다’와 같은 동사
    • 명확한 의미를 전달이 어렵고 모호할 수 있다.
    • 예. 이 시스템에는 세 가지 기능이 있다.
  • 강동사:
    • ‘확인하다’, ‘개선하다’, ‘생성하다’, ‘전달하다’와 같은 동사
    • 더 구체적이고 명확한 의미를 전달 할 수 있다.
    • 예. 이 시스템은 세가지 기능을 제공한다.
짧은 문장 구성하기
  • 가독성 향상
  • 오류 발생 가능성 감소
단락 구성원칙
  • 한 단락에 주제는 하나만 다룬다.
  • 3-5줄 정도로 적절한 길이로 작성한다.
  • 첫문장에 단락 핵심 내용을 전달한다.
일관적인 어휘 사용
  • 독자의 혼란 방지에 도움이 된다.
  • 동일한 개념에 대해 일관된 용어를 사용한다.
  • 필요한 경우, 용어에 대한 정의를 제공해야한다.

독자 중심의 접근 방식

독자와의 공감대 형성

체크리스트

  • 독자는 내가 글을 쓰는 주제에 대해 얼마나 알고 있는가?
  • 독자가 비슷한 내용을 알고 있는가?
  • 독자가 오랫동안 사용하지 않은 지식을 가지고 있는가?
  • 독자가 뒤떨어진 지식을 가지고 있는가?
  • 독자가 달성하고자 하는 목표는 무엇인가?
  • 독자는 목표를 달성하기 위해 무엇을 배워야 하는가?
기술 문서 작성 팁
  • 요점부터 시작하자
  • 범위를 표시하자
  • 범위가 아닌 것을 명시하자
  • 대상 독자를 분명히 하자
  • 필요한 사전 지식 또는 읽어야할 내용을 명시하자

8. 언어적 및 비언어적 커뮤니케이션

메시지 인코딩하기

  • 수신자가 해독할 수 있도록 언어를 바꾸는 과정을 말한다.
  • 메시지가 의도대로 전달되었는 여부가 중요하다.
수용 예언

수용 예언(Acceptance Prophecy)

긍정적 기대가 긍정적 결과를 유도한다. 자기 충족적 예언의 한 형태

  • 원리:
    • 상대방이 나를 좋아할 것이라 생각하면 더 따뜻하게 행동하게 된다.
    • 그 결과 따뜻한 행동이 상대방의 호감을 유도한다.
  • 적용:
    • 회의나 발표 전 긍정적인 마인드를 형성한다.
    • 새로운 팀원이나 고객과의 첫 만남에서 활용한다.
온전히 집중하기
  • 중요성:
    • 상대방에 대한 존중과 인정 표현하는 수단이다.
    • 정보를 획득하고 이해도를 높이는 데에도 도움이 된다.
  • 방법:
    • 눈 맞추기
    • 휴대폰이나 노트북 사용을 자제하고, 필요시 양해를 구한다.
    • 전자기기 알림을 끈다.
    • 상대방 말에 끼어들지 않는다.
    • 필요시 명확한 질문한다.
  • 적용:
    • 1:1 미팅, 고객 상담, 팀 회의 등
보디 랭귀지와 제스처 활용
  • 방법:
    • 적절한 제스처 영역 유지한다. (대략 어깨에서 배꼽사이)
    • 목적을 가지고 제스처를 사용해야한다.
  • 주의사항:
    • 과도하거나 빈번한 제스처는 자제해야한다.
    • 원격 회의 시 카메라 프레임을 고려해야한다.
    • 원격 회의 시 보다 강조되어 보일 수 있음을 고려해야한다.
  • 적용:
    • 손가락 숫자 표현: 항목을 나열할 때 유용하게 사용할 수 있다.

메시지 디코딩하기

  • 받은 메시지를 이해하려면 감각과 두뇌를 사용하여 해독해야한다.

사고 시스템

  • 시스템 1:
    • 의식적으로 무언가 하지 않아도, 경험과 본능에 따라 사고가 수행된다.
    • 지나치게 의존할 경우, 편견과 판단 오류가 발생할 수 있다.
  • 시스템 2:
    • 이성적이고 논리적인 사고를 한다.
    • 시스템 1의 영향을 받는다.
    • 과도하게 사용할 경우, 분석 마비가 발생할 수 있다.
  • 인지 편향(cognitive bias)
    • 무의식적인 사고의 오류를 말한다.
    • 시스템 1 사용 중 발생하기 쉽다.
  • 확증 편향(Confirmation Bias)
    • 기존 신념을 강화하는 정보만 수용하는 현상을 말한다.
  • 사후 확신 편향(Hindsight Bias)
    • 사건 발생 후 예측 가능했다고 믿는 경향
  • 집단사고(Groupthink)
    • 조화를 위해 비판적 사고를 억제하는 현상
현재에 집중하기
  • 선입견 배제하기
    • 예. 특정 아키텍처 스타일에 대한 불호, 인지 편향 등
  • 판단 유보하기
    • 예. 상대방의 의도에 대한 판단
  • 적극적 경청 기술 활용하기

영향력과 설득

  • 이해관계자, 고객, 동료와의 소통을 말한다.
  • 가치 입증: 아이디어가 실질적 이익을 가져다주는지 보여줘야한다.
  • 경청: 상대방의 요구와 피드백을 반영한다.
  • 목표 일치: 청중의 목표와 맞추면 더 쉽게 설득할 수 있다.
설득을 위한 효과적인 기법
  • 헤드라인 문장 활용하기
    • 예. “이번 릴리즈로 처리량 150% 증가”
  • 강력한 단어 사용하기
    • 긍정적이고 확신있는 표현을 사용한다.
    • 불확실한 단어 사용을 피한다. 예를 들어, ‘노력하다’, ‘아마도’ 등이 있다.
  • 신뢰성 진술 활용하기
    • 전문성과 경력을 강조한다.
    • 예. “15년 경력의 국제 공인 소프트웨어 아키텍트”
  • 호혜성: 도움을 주고 받는 원리 활용한다.
  • 의도적 침묵: 침묵의 시간동안 청취자가 제대로 정보 획득을 할 수 있도록 하여 메시지에 동의하도록 유도한다.
  • 선택지 제공: 청취자에게 통제감을 부여한다.
  • 반복: 메시지를 지속적으로 노출하면, 청취자는 그 가치를 보다 잘 받아들일 수 있다.
  • 인지 재구성: 상황을 다른 관점에서 해석한다.
  • 재정의: 우려사항을 새로운 방향으로 유도한다. 예를 들어, 비용에 대한 우려가 있다면, 보안과 규정 준수를 통한 장기적 이익으로 전환한다.
설득 커뮤니케이션 유의점
  • 예상치 못한 질문에 대비한다.
    • 질문을 반복하고 명확하게 답변한다.
    • 답을 모를 경우, 정직하게 처리하고 후속 조치를 약속한다.

9. 수사학 3요소

수사학 (rhetoric)

다른 사람을 설득하고 영향을 끼치기 위한 언어 사용법을 연구하는 학문

에토스(Ethos)

  • 화자의 신뢰성과 신빙성
  • 예. 특정 기술이나 방법론을 제안할 때, 사람들은 화자를 믿을 수 있는가를 가장 먼저 판단한다.
  1. 전문성 입증하기
    • 관련 자격증, 경험, 수상 경력
    • 작성한 블로그 게시물
    • 연설 및 발표 경험
    • 멘토링
    • 오픈 소스 기여
    • 자원 봉사 활동
    • 추천 및 피드백
    • 출간물
  2. 신뢰할 수 있는 출처 활용하기
    1. 학술지와 전문가 저서 등 공신력 있는 자료를 사용한다.
    2. 방법: 웨이백 머신, Archive.is 서비스를 활용한다.
  3. 투명성 유지하기
    • 고용 관계, 재정적 이해관계, 개인적인 관계 등을 충분히 설명해야한다.
  4. 지식 드러내기
    1. 주제에 대한 이해력을 증명한다.
    2. 최신 지식을 유지한다.
    3. 피상적인 지식은 드러내지 않는다.
    4. 모르는 것은 인정한다.

파토스(Pathos):

  • 청중을 몰입시키기 위한 감정적 호소
  • 예. 레거시 시스템으로 인한 야간 장애 대응, 복잡한 배포 프로세스로 인한 팀 스트레스 등 실제 겪고 있는 어려움에 대한 공감을 보여주는 것
  1. 스토리 전달
    • 스토리 유형으로 성공 사례, 실패 사례, 의사결정 과정 소개하기
    • 성공 사례: 어려웠던 점과 극복 방법을 반드시 소개한다.
    • 실패 사례: 교훈을 반드시 소개한다.
    • 의사 결정 과정: 이전에 일어난 일, 변화가 필요하게된 순간, 앞으로 할 일, 앞으로 일어날 일 순으로 작성한다.
  2. 진심 전달하기
    • 개인적인 이야기 활용한다.
    • 적극적으로 경청한다.
  3. 생생한 언어와 강렬한 이미지 사용
    • 오감에 호소하는 감각적 언어 사용
      • 프레젠테이션 시, 감각언어와 함께 시각 및 청각 자료를 사용한다.
    • 은유, 직유, 비유 사용

로고스(Logos)

  • 논리적이고 이성적인 논거
  • 예. 성능 테스트 결과, 사용자 피드백 통계 등 정량적 통계를 말한다.
  1. 데이터와 사실 활용
    • 데이터 출처 표시를 해주는 것이 좋다.
  2. 논리적 연결
    • 논리적 구성 방법
      • 체계적인 내용 구조화
      • 전환 단어와 문구 활용
      • 예시를 통한 설명
    • 시각 자료 활용
      • 다이어그램
      • 순서도
  3. 추론 및 논거 - ADR 구조
    • 식별자 & 제목
      1. 상태 (초안/결정/대체)
      2. 맥락 (결정 배경, 제약사항)
      3. 평가 기준
      4. 선택 사항
      5. 결정
      6. 예상 결과
      7. 논의
    • 장점
      • 의사 결정 과정 투명성을 높인다.
      • 향후 참조 가능성을 높인다.

10. 지식 관리의 원칙

지식 관리 원칙

지식 관리와 문서화 개선을 위한 원칙이 필요함

  • 명시적 원칙
    • 회사 보안 원칙
    • 아키텍처 원칙
    • 클라우드 프레임워크 설계 원칙
  • 암묵적 원칙
    • 모든 구성원이 인지하지 못할 수 있음
    • 학습자들의 의식적/무의식적 준수

프로젝트보다 프로덕트

프로젝트별 지식 정리의 문제점 및 한계
  • 프로젝트 종료 후 지식 찾기 어려움
  • 지식 유실 가능 성 높음
  • 다른 프로젝트에서 참조/재사용 어려움
  • 프로젝트는 일시적 성격
  • 하나의 프로덕트에 여러 프로젝트가 기여한다.
프로덕트 마인드셋 장점
  1. 장기적 집중 가능
    1. 변화하는 요구사항을 더 잘 충족할 수 있게된다.
  2. 협업과 재사용성이 향상된다.
  3. 일관성 유지 가능
  4. 가시성
    1. 프로덕트 전체에 대한 관점을 제공한다.
    2. 변경 영향 파악 용이하고 개선 필요 영역 식별이 가능하다.
  5. 고객 중심성
    1. 고객 요구사항 지식이 유지된다.
  6. 지속적 개선 가능성
    1. 정보의 총체적 특성을 활용할 수 있다.
프로덕트별 지식 정리 방법
  1. 문서 중앙화
    1. 중앙 포털에 모든 지식 통합 저장
    2. 외부 문서와 상호 연결
  2. 태그 활용
    1. 다중 카테고리 분류 가능
    2. 프로덕트, 프로젝트, 아티팩트 유형 등으로 태깅
  3. 폴더 및 계층 구조
    1. 가능한 높은 수준에서 프로덕트별 정리
    2. 부서별 등 다른 기준 하위 정리 시 전체적 시각 유지
  4. 메타데이터 활용
    1. 태그 외 추가 메타데이터 사용
    2. 키-값 형태로 구체적 정보 명시
    3. 지식관리 앱의 메타데이터 기능 활용
  5. 관점 중심 접근
    1. 이해관계자의 관심사 기반 정리
    2. 관점 별 문서화 구조화

텍스트보다 추상화

목록
  • 효과:
    • 정보의 효과적 전달
    • 핵심 아이디어 부각
    • 시각적 휴식 제공
  • 글머리 기호 작성 시 유의할 점:
    • 가장 중요한 요점부터 시작
    • 같은 품사로 시작한다.
    • 순서가 중요한 경우만 숫자 사용
    • 균등한 길이 유지
표
  • 효과:
    • 많은 텍스트가 필요한 경우
    • 정보가 관계형일 때
    • 데이터 비교 분석 필요시
  • 소프트웨어 아키텍처에서의 활용:
    • 요구사항 추적성 매트릭스
    • 컴포넌트 인터페이스 사용
    • 성능 지표 보고서
    • 테스트 매트릭스
    • 이해 관계자 분석 매트릭스
시각적 추상화
  1. 별점 시스템
  2. 하비 볼
    1. 점수/척도의 시각적 표현
    2. 제한된 공간에 효과적
    3. 시계방향 채움으로 모호성 감소
  3. 워드 클라우드
    1. 단어 빈도를 크기로 표현
    2. 트렌드와 중요 단어 시각화
  4. 차트, 그래픽, 다이어그램
  5. 인포그래픽
  6. 이미지, 일러스트레이션, 애니메이션
  7. 동영상, 오디오

관점 중심 문서화

관점

  • 정의
    • 특정 이해관계자의 문제를 다루는 아티팩트 집합
    • 웹페이지, 다이어그램, 테이블 등 포함
  • 정의 프로세스:
    • 이해 관계자와 관점 작성자의 협업
    • 템플릿/체크리스트를 통한 구체화
    • 회사 전반의 문서 기반 제공
  • DRY(Don’t Repeat Yourself) 원칙 적용
    • 아티팩트 중복 방지
    • 하나의 아티팩트를 여러 관점에서 활용한다.
    • 구현 방법
      • 아티팩트 임베딩
      • 내구성 있는 하이퍼 링크
      • 자동 업데이트 지원
    • 주의사항
      • 특정 시점 표현 필요성 고려
      • 명시적 복사본 활용
  • 프랙탈 관점
    • 관점의 중첩 가능
    • 아티팩트 그룹의 재사용
    • DRY 원칙 준수

관점 구현하기

  1. 태그와 메타데이터
    1. 아티팩트의 다중 관점 지원
    2. 특정 유형/프로덕트별 검색
    3. 메타데이터로 속성과 표시 순서 정의
  2. 임베딩 및 참조
    1. 맥락 전환 없는 임베딩지향
  3. 플랫 구조
    1. 태그 기반 유연한 구조
    2. 중앙 집중식 자료 저장/검색
  4. 템플릿과 체크리스트
    1. 이해관계자별 아티팩트 정의
    2. 레이아웃 템플릿 지원
  5. 레이어
    1. 다이어그램 요소의 레이어별 분리
    2. 단일 파일에서 다중 애셋 생성, 동기화 상태 유지

11. 지식과 사람

피드백은 일찍, 자주 받자
  • 지연된 피드백은 설계 방향 오류 수정에 큰 비용을 발생시킨다.
  • 매몰 비용 오류(sunk cost fallacy): 이미 투자한 자원 때문에 비합리적 결정을 내리는 경향
    • 예를 들어, 실행 불가능한 프로젝트를 지속하는 것, 비효율적 기술, 도구를 계속 사용하는 것이 있다.
  • 매몰 비용 오류 방지 방법
    • 정기적인 프로젝트 재평가
    • 객관적 지표 활용
    • 초기 피드백 시스템 구축
  • 피드백 시점
    • 가정을 문서화 할 때: 문서화된 가정이 시스템 설계에 영향을 미치기 전에 검토해야한다.
    • 중요한 결정을 내리기 전: 주요 결정이 오류를 초래하지 않도록 해야한다.
  • 비공식적 방법
    • 동료에게 직접 물어보기
    • 작업중인 내용 보여주기
  • 공식적인 방법
    • PR을 생성하여 프로세스에 통합을 시도한다
    • **아키텍처 결정 레코드(ADR)**을 활용한다
    • 기존 회의나 리뷰를 활용한다.
    • 변경 요청(RFC) 프로세스를 활용한다.
짐을 나누기
  • 문서 작성 및 유지 관리의 공동 책임
  • 문서 작성 및 유지 관리 공유 필요
  1. 비독점 형식 활용하기
    • 누구나 자유롭게 접근하고 사용할 수 있는 애플리케이션이나 파일 형식을 사용한다.
    • 예를 들어, Markdown, YAML 등이 있다.
  2. 협업 도구 활용하기
    • 예를 들어, 구글 문서 도구, 슬랙 등이 있다.
  3. 역할과 책임 분배
    1. 역할 분담 방식: 작성자와 검토자를 분리하기, 문서 유형별 담당자 분배하기 등
  4. 지식 공유 세션 또는 Lunch&Learn 활용하기
JIT 아키텍처

YAGNI 원칙

“You Aren’t Gonna Need It” 미래의 필요성을 예측하지 않고 지금 필요한 것에만 집중한다.

JIT(Just-In-Time) 아키텍처

필요한 시점에 필요한 결정을 하고 문서화하는 원칙

  • 필요할 때만 아키텍처와 문서를 생산하므로 낭비를 줄일 수 있다.
  • 변화하는 요구 사항에 빠르게 대응이 가능하여 민첩성과 유연성 향상된다.
  • 최신 상태 유지로 시간과 노력이 절약된다.
  • 최신 정보에 기반한 의사 결정이 가능해진다.
  • Time2Market을 개선할 수 있다.
  • 미래의 중요한 정보를 놓칠 가능성이 있다.
    • 위키 페이지 등으로 관련 정보를 기록할 공간을 마련해야한다.

12. 모범 사례

ADR

ADR (Architecture Decision Record)

아키텍처 의사결정 및 근거의 기록

장점

  • 위험한 결정 변경 방지
  • ‘두더지 잡기’ 상황 방지. 즉, 동일한 사안에 대한 반복적인 논의를 줄일 수 있다.
  • 효율적인 지식 전달
  • 퇴사로 인한 지식 손실 방지

사용 시점

  • 개발에 영향을 미치는 중요한 결정
  • 변경이 어렵거나 비용이 많이 드는 결정
  • 자주 질문되는 결정 사항
  • 장기적으로 영향을 미치는 결정
  • 복잡하거나 이해하기 어려운 결정
ADR 구조
# 식별자와 제목: 내려진 결정에 대한 진술 
- 예. "001 이벤트 기반 아키텍처 사용"
 
## 상태: 초안/결정/ADR-XXX에 의해 대체됨
- 워크플로우는 간단해야한다.
- 예. 결정. 2023-10-14 [ADR-031 서버리스 기능 사용]을 대체함
 
## 맥락: 결정을 내려야 하는 이유. 가정, 제안, 결정 추진 동인 
 
## 평가 기준  
- 이 결정을 내리는 데 있어서 중요한 것은 무엇인가?  
- 이 결정을 내리는 데 있어서 어떤 아키텍처 특성이 적용되는가?  
- 기준이 되는 제약 사항이나 결정의 추진 동인이 있는가?  
 
## 선택지: 평가 기준(점수나 등급)에 따라 고려된 선택지들의 개요, 또한 평가 기준 외의 트레이드오프 
  
## 결정: 내려진 결정과 그 이유 
 
## 예상 결과: 내려진 결정의 긍정/부정적인 결과 
 
##논의: 
다른 이들의 의견을 받는 경우, 이곳에 작성하게 한다. 실제 의견을 제시하든 하지 않든, 초대된 사람들에 대한 사항도 기입할 수 있다. 논의는 결정이 내려진 후에 일어나지만, 길이가 길어지고 결정 자체가 가려 질 수 있기 때문에 마지막에 기록된다.
ADR 작성 팁
  • 세부 정보 수준은 결정의 파급 효과에 비례해야한다.
  • 모든 정보는 선택의 이유를 명확히 설명해야함
  • 계산 과정이나 데이터 출처를 포함해야한다.
  • 외부 자료 참조시 링크를 제공해야한다.
  • 날짜 정보를 포함해야한다. (작성, 업데이트, 다음 검토 일정)
ADR 보관
  • 모든 이해 관계자가 접근 가능한 중앙 저장소를 사용해야한다.
  • 프로젝트가 아닌 프로덕트 기준으로 보관해야한다.
  • README 파일에 ADR 위치 링크를 포함해야한다.
ADR 문화 조성
  • 주간 검토 회의에 의사결정 논의를 포함해야한다.
  • 온보딩 프로세스에 ADR 검토를 추가해야한다.
  • 새로운 질문에 대해 ADR 작성을 권장해야한다.
  • 프로세스 구축 시, 작성과 접근이 쉽도록 해야한다.
  • 점진적인 문화 변화를 유도해야한다.

아키텍처 특성

  • 시스템 또는 프로덕트의 우선순위를 나타내는 특성
  • 아키텍처 특성 도출 시 이해관계자의 우선순위를 충족하는 아키텍처 설계가 가능하다.
아키텍처 특성 예시

일반적인 아키텍처 특성

  • 접근성: 모든 사용자가 시스템을 성공적으로 사용할 수 있는지 여부
  • 가용성: 사용자가 필요할 때 시스템을 사용할 수 있는지 여부
  • 구성 가능성: 최종 사용자가 소프트웨어 요소를 쉽게 변경할 수 있는지 여부
  • 연속성: 재해로부터 복구할 수 있는지 여부
  • 확장성: 새로운 기능 추가가 용이한지 여부
  • 이식성: 시스템을 여러 플랫폼에서 실행할 수 있는지 여부
  • 프라이버시 보호: 시스템이 내/외부 사용자로부터 데이터를 숨길 수 있는지 여부
  • 규모 확장성: 사용자 수 증가에 따라 시스템이 정상적으로 작동하는지 여부

암묵적으로 고려할 수 있는 특성

  • 실현 가능성: 현재 제약 조건(비용, 시간, 리소스 등)을 고려할 때 솔루션으로 가능한지
  • 유지보수성: 시스템을 효율적으로 유지보수할 수 있는지
  • 보안: 권한이 없는 사람이 시스템에 접근하지 못하도록 관리할 수 있는지
  • 단순성: 시스템이 복잡하지 않고 단순한지
선택 및 관리

  • 상위 7가지 특성을 선정한다.

  • 프로덕트 생명 주기에 따라 주기적으로 재검토한다.

  • 기록 항목

    • ID: 특성 식별자
    • 특성: 아키텍처 특성 이름
    • 적용 가능: 시스템의 어느 영역에 적용되는지
    • 출처: 요구사항 등 특성의 근거

  • 날짜 정보를 포함해야한다.

  • 상위 3개 특성은 별도로 표시하고 근거를 문서화 해야한다.

문서를 코드처럼

코드를 작성하는 것과 동일한 환경에서 마크업 언어로 문서를 작성하는 것

핵심 원칙

  • 문서 소스 파일을 버전 관리 시스템에 저장한다

13. 원격 시간

  • 시간 동기화 하기
  • 근무 패턴 존중하기
  • 알림 관리하기

14. 원격 근무의 원칙

동기식 회의
  • 원격 동기식은 대면보다 에너지 소모가 많다.
대면 상황원격 회의
목소리, 보디 랭귀지, 표정 쉽게 파악 가능일반적 대화 흐름 방해
무의식 중 단서 해독 가능이해를 위해 더 많은 노력이 필요

회의 개선하기

  • 회의 목표 신중하게 선택하기
  • 활동과 목표의 연관성 확인하기
  • 합의된 기준을 설정한다.
  • 적절한 참석자만 초대한다.
  • 진행/발표자에게 시간을 명시한다,
  • 회의 전후 비동기식 커뮤니케이션을 계획한다.
  • 결정사항과 조치 문서화한다.
  • 45-60분 마다 휴식 시간을 배치한다.

동기식 회의 줄이기

  • 비동기식 정보 공유 방법 마련
  • 프로젝트/지식 관리 앱 활용
  • 비동기식 업데이트 공간 도입
  • 회의 금지 블록/요일 시험 도입
  • 필수 회의 재설계
  • 비동기식 전환 장점 강조

방향도 중요하다

  • 단방향 커뮤니케이션
    • 성과 보고, 공지, 정보 공유
    • 비동기식 진행 적합
  • 양방향 커뮤니케이션
    • 피드백, 질문, 논의 필요
    • 상황에 따른 방식 선택

비동기식 커뮤니케이션 기준 (4W)

  • Who
    • 포함/제외할 사람
    • 답변 책임자
  • What
    • 기대사항
    • 도구와 워크플로
  • When
    • 날짜, 시간, 시간대
    • 마감 기한
  • Wah-Wah(대응)
    • 무응답 시 대처
    • 영향 설명

15. 원격 채널

대칭 이메일 (symmetrical email pattern)

이메일 요구사항

제목에 정보 포함

  • 긴급 이메일: “[긴급, 날짜/시간 명시]”
    • 긴급 남용 주의
  • 정보 전달용: “[공유]” 제목
  • 특정인 회신: “[회신 요망 - 이름]”

요구사항 명시적 표현

  • 소요 시간 구체적 명시
    • 회의: “30분 정도”
    • 설문: “5-7분 소요”
    • 검토: “30분 검토”
  • 수신자별 요구사항 명시

이메일 작성 팁

  • 요점부터 시작하기
  • 이메일당 하나의 주제에 집중하기
  • 전체 답장 대신 기본 답장으로 설정
  • 보내기 실행 취소 활성화
  • 보내기 전에 교정하기
  • 로봇 말투 지양하기
    • 인간적 접근: 직접 지칭 사용 등
    • 소리내어 작성

온라인 발표

  • 질문 방식 사전안내
  • 실시간 반응 유도
  • 집중력 유지
    • 더 많은 슬라이드 사용
    • 시각적 휴식 제공
    • 45-60분마다 휴식
  • 주제 설명 슬라이드 지양
  • 효과적인 시작
    • 임팩트 있는 이미지
    • 대담한 문구
    • 핵심 통계
    • 관련 스토리
  • 명확한 다음단계 제시

슬라이드의 종류

  • 슬라이드 데크(slide deck)
    • 발표자 발표용 시각 자료
    • 청각 요소와 결합
  • 슬라이드 문서 (slide document)
    • 모든 정보 포함
    • 독립적 문서 형태
  • 인포데크 (infodeck)
    • 발표자 없이 단독 사용
    • 레이아웃 제어 용이

그 외

Graph View

Backlinks

  • No backlinks found