[Python]PEP 570을 보며.. (feat. 커뮤니티의 중요성 & 커뮤니케이션)

안녕하세요, 이번 포스팅에서는 지난 Function Parameter, Argument를 공부하면서 읽게 된 문서와 느낀점을 써보려고 합니다.

 

지난 포스팅
https://leffept.tistory.com/418?category=927799 

[Python]Function Parameter, Argument 에 대하여

 

PEP (Python Enhancement Proposals)란?

파이썬에는 PEP 라는 "파이썬을 개선하기 위한 개선 제안서" 라는 것이 존재합니다. 파이썬에 관련된 정보를 제공하거나 여러 제안들을 통해 파이썬에 새로운 기능이나 이슈를 해결하는 커뮤니티이자 문서입니다.

 

PEP Types(종류)에는 총 3가지가 있습니다.

• Standard Track - 파이썬의 새로운 기능 또는 구현을 설명합니다.
• Informational - 파이썬 디자인 문제를 설명하거나 정보를 제공합니다.
  (새로운 기능을 제안하지는 않습니다)
• Process - 파이썬을 둘러싼 프로세스를 설명, 변경을 제안합니다.

 

PEP 570 - Python Positional-Only Parameters

https://peps.python.org/pep-0570/

PEP 570 – Python Positional-Only Parameters | peps.python.org

PEP Type 중 Standard Track에 해당되는 문서를 보고 느꼈던 생각을 말씀 드리려고 합니다.

 

우선, 저는 "PEP라는 것이 있다" 정도로만 알고 있었습니다. 관련 규칙을 찾아볼 때도 깊게 읽어본 적은 없었습니다. 하지만 이번에 Function Paramter 부분을 공부하면서 과거에 제안이 되었던 PEP 570 문서를 접하게 되었습니다.

 

문서의 주요 목차를 간단하게 요약하자면 다음과 같습니다.

• Abstract - 요약
• Motivation - 동기
• Rationale - 이론 설명
• Specification - 스펙
• How To Teach This - 어떻게 가르쳐야 하는지

위의 목차들 중 제가 놀랐던 부분은 Motivation, Specification, How To Teach This 입니다. 각 파트별로 조금 더 자세한 설명을 이어 나가겠습니다.

 

Motivation

이 파트에서는 파이썬에서 과거에 positional-only paramter가 존재했던 역사에 대한 설명으로 시작이 됩니다. 그러면서 파이썬 1.0 에서 positional-or-keryword로 semantic이 변경 되었음을 설명해주고 있습니다. 자연스럽게 설명이 이어지면서 positional-only paramter가 없으면 발생하는 문제 & 얻게되는 장점들에 대해서 언급하기 시작합니다.

 

해당 기능이 필요한 주요 목적은 라이브러리를 만드는 author를 위함이라고 설명이 나와 있습니다. 간단하게 요약하자면, positional-only parameter를 도입함으로써 API를 호출하는 호출자에 관계 없이 라이브러리 author는 parameter를 자유롭게 변경할 수 있게 됩니다.

또한, 라이브러리 author는 의도된 API 사용법을 더 잘 표현할 수 있고 이전 버전과 호환되는 방식으로 발전해나갈 수도 있습니다.

 

제가 해당 파트에서 놀랐던 부분은 역사부터 시작해서 생겼던 문제점, 얻게되는 이익 등 관련된 context에 대해서 상세한 정보를 공유하고 있다는 것이었습니다.

 

우리는 종종 개발을 하다보면 이전에 짜여진 코드에 이상함을 느끼게 되는데요, 그 때 당시의 context를 파악하고 나면 그렇게 작성된 이유를 이해할 수 있게 됩니다. 이런 측면에서 여러가지 내용을 공유한다는 점이 파이썬 생태계가 잘 성장할 수 있었던 원동력이 아닌가 합니다.

 

Specification

해당 파트에서는 Syntax 와 Semantics에 대해 상세하게 설명되어 있습니다. 제가 놀랐던 파트는 "/"가 구분자로 생겨난 유래였습니다.

Alternative proposal: how about using ‘/’ ? It’s kind of the opposite of ‘*’ which means “keyword argument”, and ‘/’ is not a new character.

"/" 구분자는 keyword argument 의미의 정확히 반대이고 새로운 character가 아니라고 설명하고 있습니다. 구분자 하나를 사용할 때도 의미 없는 character가 아니라 그 이유가 명확하다는 점이 굉장히 놀랐던 포인트 입니다.

 

제가 현재 일하고 있는 팀에서도 코드리뷰를 하면서 종종 위의 사례와 같은 일을 겪었던 경험이 있습니다. 구성원 모두가 어느 하나 그냥 넘어가는 것이 아니라 명확한 근거와 합리적인 이유를 늘 제시하고 있다는 점이었습니다. 

 

How To Teach This

마지막 파트에서는 이러한 목차 자체가 있다는 것에 놀라게 되었습니다. 단순히 제안만을 하고 끝나는 것이 아니라 커뮤니티의 사람들에게 어떻게 가르쳐야 하고 무엇을 주의해야 하는가에 대한 것 까지도 설명이 되어있습니다. 

 

역사부터 시작해서 문제점, 장점, 가르치는 방법의 내용까지 정말 문서 하나만 보더라도 제안을 하게된 그 배경을 완벽하게 이해할 수 있었습니다. 이러한 오픈되고 공유하는 문화가 개발 생태계에서 가장 재미있고 매력을 느낄 수 있는 포인트가 아닌가 합니다.

 

조직에서의 커뮤니케이션 (주저리 주저리..)

어떠한 조직에서 일을 하더라도 가끔은 제안해야 할 포인트(프로세스, 문화 ..etc)들이 생기곤 합니다. 제안을 했을 때 돌아오는 피드백은 3가지 중 하나일 것 같습니다. 부정적으로 받아들이는 경우, 긍정적으로 받아들이는 경우, 무시하는 경우.

 

정말 잘 형성된 커뮤니티에서의 제안 문서를 보고나니, 다음과 같은 내용이 포함된 제안이라면 조직 구성원들로부터 조금 더 긍정적인 시그널을 받을 확률이 늘어날 것 같습니다.

1. 해당 제안을 하게 된 배경을 구성원들에게 설명하고 이해시킬 수 있어야 한다
2. 제안을 통해 얻을 수 있는 장점(문화, 시간, 돈 ..etc)에 대해서 어필할 수 있어야 한다
3. 제안을 조직원 모두가 잘 수행하기 위한 방법도 함께 소개한다

 

하나의 기술 문서를 읽는 것이었지만 정말 여러가지 많은 생각을 해보고 느낄 수 있었던 시간이었던 것 같습니다. 개인적으로는 오픈 커뮤니티와 조직 커뮤니케이션이 많은 상관관계가 있는 것 같습니다.

 

PEP 문서의 내용은 일부 틀린 것이 있을 수 있습니다. 수정이나 기타 의견을 주고 받고 싶으신 분은 댓글을 남겨주시면 답글 남겨드리겠습니다.

 

읽어주셔서 감사합니다 :)