소프트웨어 공학 100 주제 시리즈의 8번째 글이다. (카테고리: 기초와 역사)

한 줄 요약

IEEE-CS 와 ACM 의 공동 태스크포스가 만든 「소프트웨어 공학 윤리 및 전문 실무 강령」(1999)은 소프트웨어 엔지니어의 의무를 공공, 고객과 고용주, 제품, 판단, 관리, 직업, 동료, 자기 자신의 여덟 원칙으로 정리하고, 그 모든 판단에서 공공의 이익이 중심이라고 못 박는다.

왜 필요한가

윤리는 거창한 딜레마에서만 등장하지 않는다. 개발자가 실제로 마주치는 장면은 대개 평범하다.

  • 출시일이 정해져 있는데, 테스트에서 가끔 재현되는 결함이 개인정보를 다른 사용자에게 보여 줄 수 있다.
  • 영업 자료에 “AI 가 99% 정확” 이라고 적혀 있는데, 그 숫자를 어디서 측정했는지 아무도 모른다.
  • 관리자가 일정 추정을 “좀 더 낙관적으로” 다시 써 달라고 한다.
  • 해지 버튼을 찾기 어렵게 만들라는 요구가 내려온다.

이런 순간에 개인의 양심만으로 버티기는 어렵다. 강령은 “직업 공동체가 합의한 기준” 이라는 근거를 준다. 강령 서문도 이 점을 명시한다. 특정 상황에서 적극적 조치가 필요한 엔지니어와 관리자에게 직업의 윤리적 입장을 문서로 제공하고, 엔지니어에게 요구하는 것이 윤리적으로 부적절한 행동을 정의하는 데 도움을 준다는 것이다.

핵심 개념

출처와 위상

강령 전문은 IEEE Computer Society 의 Code of Ethics 페이지에 짧은 버전과 전체 버전이 함께 실려 있다. IEEE-CS/ACM 소프트웨어 공학 윤리 및 전문 실무 공동 태스크포스(SEEPP)가 개발했고, 실행위원회는 Donald Gotterbarn(의장), Keith Miller, Simon Rogerson 이다. 저작권 표기는 1999년 IEEE 와 ACM 공동이다. 승인 경위는 Gotterbarn, Miller, Rogerson, “Software Engineering Code of Ethics Is Approved”, Communications of the ACM 42(10), 1999에 실렸다.

강령은 변경하지 않고 저작권 표시를 유지하는 한 허가 없이 게시할 수 있다. 팀 위키에 그대로 옮겨 두기 좋은 문서다.

여덟 원칙 (짧은 버전)

# 원칙 요지
1 PUBLIC 공공 공공의 이익에 부합하게 행동한다
2 CLIENT AND EMPLOYER 고객과 고용주 공공의 이익에 부합하는 범위에서 고객과 고용주의 최선의 이익을 위해 행동한다
3 PRODUCT 제품 제품과 그 수정이 가능한 최고의 전문 기준을 충족하게 한다
4 JUDGMENT 판단 전문적 판단의 무결성과 독립성을 유지한다
5 MANAGEMENT 관리 관리자와 리더는 개발·유지보수 관리에서 윤리적 접근을 따르고 장려한다
6 PROFESSION 직업 공공의 이익에 부합하게 직업의 무결성과 평판을 높인다
7 COLLEAGUES 동료 동료에게 공정하고 협조적이다
8 SELF 자기 평생 학습에 참여하고 윤리적 실무를 장려한다

순서가 의미를 가진다. 2번과 6번 원칙에 “공공의 이익에 부합하는 범위에서” 라는 단서가 붙어 있다. 고용주의 이익과 공공의 이익이 충돌하면 공공이 앞선다는 구조다.

서문이 말하는 강령의 성격

전체 버전 서문에서 실무에 중요한 문장들을 골라 보면 이렇다.

  • 각 원칙 아래 조항(clause)들은 의무의 예시이며 목록은 완전하지 않다.
  • 강령은 윤리적 결정을 생성하는 단순한 알고리즘이 아니다. 기준끼리 충돌할 수 있고, 그때는 세부 규정에 맹목적으로 기대기보다 기본 원칙을 숙고해 판단해야 한다.
  • 개별 조항을 떼어 내 잘못을 정당화하는 데 쓰면 안 된다.
  • 엔지니어는 자기 일이 누구에게 영향을 주는지, 충분히 정보를 가진 대중이 결정을 어떻게 볼지, 가장 힘이 약한 사람이 어떤 영향을 받는지 생각해야 한다.
  • 이 모든 판단에서 공공의 건강·안전·복지에 대한 관심이 일차적이다. “공공의 이익” 이 강령의 중심이다.

실무에서 자주 걸리는 조항들

조항 번호는 원칙 번호.세부 번호다. 실제 상황과 연결되는 것만 추렸다.

조항 내용(요지) 걸리는 상황
1.03 안전하고, 명세를 충족하고, 적절한 테스트를 통과하고, 삶의 질·프라이버시·환경을 해치지 않는다는 근거 있는 믿음이 있을 때만 소프트웨어를 승인한다 알려진 결함을 안고 출시 승인
1.04 사용자·공공·환경에 대한 실제 또는 잠재적 위험을 적절한 사람이나 기관에 알린다 안전 문제 은폐 압력
2.06 프로젝트가 실패하거나, 너무 비싸지거나, 지식재산권 법을 위반하거나, 문제가 될 것 같으면 근거를 모아 고객·고용주에게 즉시 보고한다 “말하면 분위기 깨질까 봐”
3.09 / 5.05 비용·일정·인력·품질·결과에 대한 현실적인 정량 추정과 그 불확실성 평가를 제공한다 추정치를 낙관적으로 고쳐 달라는 요구
3.10 적절한 테스트, 디버깅, 리뷰를 보장한다 테스트 생략 지시
3.12 영향을 받을 사람들의 프라이버시를 존중하는 소프트웨어를 만든다 과도한 데이터 수집
5.11 / 5.12 관리자는 강령에 어긋나는 일을 요구하지 않으며, 윤리적 우려를 제기한 사람을 처벌하지 않는다 문제 제기자에 대한 보복
6.07 자기가 다루는 소프트웨어의 특성을 정확하게 말한다. 허위뿐 아니라 추측성·공허·기만적·오해 소지가 있는 주장도 피한다 근거 없는 성능·정확도 마케팅
7.04 다른 사람의 작업을 객관적이고 솔직하며 적절히 문서화된 방식으로 리뷰한다 형식적 코드 리뷰
7.08 자기 역량 밖의 상황에서는 그 분야 전문가의 의견을 구한다 보안·법률 판단을 혼자 내리기

3.09 와 5.05 가 사실상 같은 내용이라는 점이 눈에 띈다. 엔지니어는 정직한 추정을 제공해야 하고, 관리자는 그것을 보장해야 한다. 추정 왜곡은 양쪽 모두의 윤리 문제다.

왜 소프트웨어에 따로 강령이 필요한가

서문 첫머리가 답한다. 컴퓨터는 상업·산업·정부·의료·교육·오락과 사회 전반에서 중심적 역할을 하고, 소프트웨어 엔지니어는 그 시스템의 분석·명세·설계·개발·인증·유지보수·테스트에 직접 참여한다. 그래서 선을 행하거나 해를 끼칠 상당한 기회를 가진다. 1985~1987년 Therac-25 사고(SE100 #010 에서 다룬다)처럼, 소프트웨어 결함은 사람의 생명으로 이어질 수 있다.

실무 적용

윤리 문제가 의심될 때 쓰는 짧은 판단 절차다. 강령 서문이 권하는 질문을 순서대로 펼친 것이다.

## 윤리 점검 메모 (PR 설명이나 이슈에 첨부)

1. 무엇을 하라는 요구인가? (사실만)
2. 영향을 받는 사람은 누구인가? — 사용자, 비사용자, 가장 힘이 약한 집단
3. 관련 조항은? (예: 1.03 승인 기준, 3.09 추정, 6.07 정확한 주장)
4. 정보를 충분히 가진 대중이 이 결정을 본다면 어떻게 평가할까?
5. 대안은? — 범위 축소, 기능 플래그로 비활성, 경고 문구, 일정 재협상
6. 누구에게 알렸는가? (2.06: 근거를 모아 즉시 보고)
7. 기록: 날짜, 수신자, 결정, 근거

예를 들어 “개인정보 노출 가능성이 있는 결함을 알고도 출시” 라는 상황이라면, 1.03 의 승인 기준을 충족하지 못한다는 판단과 함께 2.06 에 따라 근거(재현 절차, 영향 범위)를 문서로 남기고, 5번의 대안(해당 기능만 플래그로 끄고 출시)을 제시하는 것이 강령이 요구하는 행동에 가깝다. “출시를 막는다” 와 “조용히 넘어간다” 사이에는 대개 여러 선택지가 있다.

팀 차원에서는:

  • 문제 제기 경로를 미리 만든다. 5.12 는 우려를 제기한 사람을 처벌하지 말라고 한다. 익명 채널이나 정기 회고의 고정 안건이 그 장치다.
  • 주장에 출처를 붙인다. 릴리스 노트와 마케팅 문구의 수치에 측정 조건을 남기는 습관은 6.07 의 실천이다.
  • 추정의 불확실성을 숫자로 말한다. “3주” 대신 “2~5주, 외부 API 승인이 가장 큰 변수” 처럼. 3.09 가 요구하는 것은 불확실성 평가까지다.

AI 시스템에 고유한 쟁점은 AI 윤리에서, 소프트웨어 실패가 사회에 미친 영향은 소프트웨어 실패의 사회적 영향에서 다뤘다.

흔한 오해와 함정

  • “강령은 법이다.” 강령은 직업 공동체의 합의다. 법적 구속력과는 별개다. 6.06 은 오히려 법을 지키되, 예외적인 경우 준법이 공공의 이익과 어긋날 수 있다고까지 언급한다.
  • “고용주 지시를 따르면 책임이 없다.” 1.01 은 자기 작업에 대한 전적인 책임을 지라고 하고, 2번 원칙 자체가 “공공의 이익에 부합하는 범위에서” 고용주를 위해 행동하라고 한다.
  • “조항 목록에 없으면 괜찮다.” 서문은 목록이 완전하지 않으며, 조항을 떼어 내 잘못을 정당화하지 말라고 명시한다.
  • “윤리는 관리자의 일.” 8개 원칙 중 관리자만을 대상으로 한 것은 5번 하나다. 나머지는 모든 엔지니어의 의무다.
  • “유지보수는 덜 중요하다.” 3.15 는 모든 형태의 유지보수를 신규 개발과 같은 전문성으로 다루라고 한다.

확인 문제

  1. 여덟 원칙 중 다른 원칙들의 판단 기준이 되는 원칙은 무엇이며, 강령 어디에서 그것이 드러나는가?
  2. 강령이 “단순한 윤리 알고리즘이 아니다” 라고 말하는 이유는?
  3. 관리자가 일정 추정치를 낮춰 쓰라고 요구할 때, 엔지니어와 관리자 각각에 해당하는 조항은?
  4. “근거 없는 99% 정확도” 문구는 어떤 조항에 걸리는가?
  5. 알려진 결함이 있는 기능의 출시를 놓고 강령이 요구하는 행동을 세 가지로 요약하라.

풀이

  1. 1번 PUBLIC(공공). 서문이 “공공의 이익” 이 강령의 중심이라고 말하고, 2번·6번 원칙에 “공공의 이익에 부합하는 범위에서” 라는 단서가 붙어 있다.
  2. 기준들이 서로 또는 다른 출처의 기준과 충돌할 수 있어, 세부 규정에 기대기보다 기본 원칙을 숙고해 판단해야 하기 때문이다.
  3. 엔지니어는 3.09(현실적 정량 추정과 불확실성 평가 제공), 관리자는 5.05(같은 내용의 보장)와 5.11(강령에 어긋나는 일을 요구하지 않기).
  4. 6.07 — 소프트웨어 특성을 정확히 말하고, 추측성·기만적·오해 소지 있는 주장을 피한다. 1.06(공개 발언에서 기만 회피)도 관련된다.
  5. 1.03 승인 기준을 충족하는지 판단, 2.06 에 따라 근거를 모아 즉시 보고, 해당 기능 비활성화나 범위 축소 같은 대안 제시.

더 읽을거리 (References)