기술을 비개발자에게 설명하는 방법

쉬운 설명은 전문 용어를 다른 단어로 바꾸는 일이 아닙니다

비개발자에게 기술을 설명할 때 모든 전문 용어를 없애려고 하면 중요한 조건까지 사라질 수 있습니다. 반대로 구현 구조부터 설명하면 상대가 자신의 업무와 어떤 관계가 있는지 알기 어렵습니다.

설명의 출발점은 기술이 아니라 상대가 결정하거나 확인해야 하는 일입니다.

먼저 상대가 알아야 하는 결과를 정합니다

설명 전에 다음 중 무엇이 목적인지 선택합니다.

• 변경으로 무엇이 달라지는지 알리는 것
• 일정이나 범위를 합의하는 것
• 위험과 대응 방법을 설명하는 것
• 여러 대안 중 결정을 요청하는 것
• 오류 원인과 복구 상태를 공유하는 것

목적이 다르면 같은 기술도 설명 순서가 달라집니다. 일정 합의가 필요한데 내부 클래스 구조를 먼저 설명하거나, 장애 대응 보고에서 전체 시스템 역사를 말하면 필요한 결정이 늦어집니다.

사용자 영향부터 설명합니다

기술 변경은 화면이나 업무 흐름에서 관찰되는 차이로 시작합니다.

구현 중심 설명:

“공통 Validator를 만들고 각 컴포넌트의 validation 함수를 교체했습니다.”

영향 중심 설명:

“화면마다 다르게 적용되던 입력 검증 기준을 하나로 맞춰 같은 값이 화면에 따라 통과하거나 실패하는 문제를 줄였습니다.”

상대가 영향을 이해한 뒤 필요할 때 구현 방식을 설명합니다.

동작 흐름은 세 단계로 줄입니다

복잡한 시스템도 처음에는 입력, 처리, 결과 세 단계로 설명할 수 있습니다.

• 입력: 사용자가 무엇을 제공하는가?
• 처리: 시스템이 어떤 기준으로 판단하는가?
• 결과: 사용자에게 무엇을 보여 주거나 저장하는가?

예시:

“사용자가 보고서 기간을 선택하면 시스템이 해당 기간의 데이터를 검증하고, 누락이 없을 때 문서를 생성합니다.”

세 단계에서 질문이 나온 부분만 더 자세히 설명합니다. 처음부터 데이터베이스 테이블과 클래스 이름을 모두 보여 주지 않습니다.

기술 용어는 정의보다 역할로 설명합니다

전문 용어가 꼭 필요하다면 사전식 정의보다 현재 기능에서 맡는 역할을 설명합니다.

예시:

“캐시는 자주 사용하는 결과를 잠시 보관해 같은 계산을 반복하지 않도록 하는 영역입니다. 이번 기능에서는 목록을 열 때마다 같은 기준 정보를 다시 읽는 일을 줄이기 위해 사용합니다.”

이 설명은 캐시의 모든 특성을 다루지 않지만 현재 결정에 필요한 역할과 주의점을 전달합니다.

대안을 설명할 때 비교 기준을 먼저 합의합니다

“A가 더 좋습니다”라고 말하면 기술 선호처럼 들릴 수 있습니다. 먼저 이번 결정에서 중요한 기준을 말합니다.

• 구현 기간
• 운영 위험
• 되돌릴 수 있는지
• 데이터 정확성
• 유지보수 범위
• 사용자 영향

예시:

“이번 변경은 일정 안에 되돌릴 수 있는 범위가 중요합니다. 전체 화면을 동시에 교체하는 방법은 일관성은 높지만 영향 범위가 큽니다. 대표 화면부터 전환하는 방법은 중간에 두 방식이 공존하지만 문제가 생기면 해당 화면만 되돌릴 수 있습니다.”

비교 기준이 보이면 상대도 기술 이름을 몰라도 결정에 참여할 수 있습니다.

모르는 부분과 확인된 부분을 구분합니다

기술 설명에서 신뢰를 잃는 가장 빠른 방법은 추정과 확인 결과를 섞는 것입니다.

다음 표현을 구분합니다.

• 코드에서 확인했습니다.
• 로컬 build에서 확인했습니다.
• 운영 로그에서 확인했습니다.
• 현재는 가능성이 높은 원인입니다.
• 운영 환경에서는 아직 확인하지 못했습니다.

확인하지 못한 부분을 숨기기보다 다음 확인 방법과 시점을 함께 말합니다.

비유는 한계를 함께 말합니다

비유는 처음 이해하는 데 도움이 되지만 실제 동작과 완전히 같지는 않습니다. “데이터베이스는 엑셀과 같습니다”라고만 말하면 동시 수정, 제약조건, 트랜잭션 같은 차이를 놓칠 수 있습니다.

비유를 사용할 때는 다음처럼 범위를 붙입니다.

“행과 열로 데이터를 본다는 점에서는 표와 비슷하지만, 여러 사용자가 동시에 수정하고 데이터 규칙을 강제한다는 점에서는 차이가 있습니다.”

최종 점검 체크리스트

• 상대가 해야 할 판단이나 확인이 먼저 드러나는가?
• 사용자 또는 업무 영향부터 설명했는가?
• 동작 흐름을 입력, 처리, 결과로 줄였는가?
• 전문 용어마다 현재 기능에서의 역할을 설명했는가?
• 대안을 같은 기준으로 비교했는가?
• 확인한 사실과 추정을 구분했는가?
• 비유가 실제 동작과 다른 범위를 설명했는가?

좋은 기술 설명은 기술을 단순하게 보이게 만드는 것이 아닙니다. 상대가 필요한 결정을 내릴 수 있을 만큼 정확한 정보를 적절한 순서로 제공하는 것입니다.