[p5.js KO] 음차 번역 기준 및 표기 제안

[yinhwa]

안녕하세요,

기여자님들이 진행해주신 3월 2주차 연습과제와 더불어, 이 파일상 제기된 여러 논의를 토대로 아래의 제안 사항을 작성해봅니다😀

이 문서는 2024년 p5.js 번역 기여 프로젝트 진행 기간 내내 계속해서 업데이트 됩니다!

음차 번역 표기 관련 (last updated: Mar 12 2024)

다음의 경우 ⭐한글(영문) 병기⭐된 음차번역을 하는 것이 어떨지 제안드려봅니다 ^^

• 음차 번역어가 이미 상용화된 경우

• 직역시 혼선을 빚을 것으로 예측되는 경우

  • 예: " 반복 실행(iteration)", "절두체(frustrum)", "단위 테스트(unit test)", "프레임워크(framework)", "인스턴스 모드(instance mode)", "그래픽 버퍼(graphic buffer)", 고유명사: "포럼(Forum)")

• 적절한 한국 번역어를 찾을 수 없는 경우

그 외 여러 경우도 있을 것 같은데요, 일단은 이정도로 물꼬를 터봅니다 :)

문장 주술관계 (last updated: Mar 14 2024)

• 일명 "번역 어투"(예: 주술 관계가 바뀐 수동체)는 가급적 피해주시길 바랍니다!

• 번역 후, 문장의 가독성을 검토해주세요!

어조 (last updated: Mar 14 2024)

• p5.js 홈페이지나 기여자 문서 등의 원문을 확인하시면, 생각보다 서술적이고 구어체가 많습니다. 특히, 원문이 초보자들에게 친근하게 다가가는 점을 고려해서, 기여자님들도 적절한 어조를 선택하시면 되겠습니다.

참고자료

• 상기된 내용들은 대체로 p5.js 웹에디터 친근한 오류 시스템 번역 가이드라인 중 번역자 간의 약속에 포함되어있습니다. 한 번 훑어보시면 도움이 되실 것 같습니다. 기존 한국어 번역자들의 고민과 노하우가 수록된 페이지 입니다.

그 외, 다양한 의견들 댓글로 남겨주시면, 계속해서 이 게시글에 반영하겠습니다!

[designerSejinOH]

프로그래밍 커뮤니티 자체가 영어 기반이라그런지 1번의 경우가 다수일 것 같네요..🥹

[yinhwa]

맞아요 ㅋㅋ,,, 진짜 어쩔수없는 현실인가 싶으면서도 이거 계속 이래도되나싶은.... 프로그래밍 언어 장벽을 유지+답습하는 기분이랄까...

[ienground]

지금은 다른 단어가 생각이 나지는 않지만,
Resource는 한국어로 자원이라는 단어가 분명 존재합니다.
그럼에도 프로그래밍 언어에서는 그냥 리소스라고 하는 경우가 9할을 넘는 것 같아요. 이에 대해서 단어를 어떻게 번역하는 것이 좋을지에 대해 같이 얘기를 나누었으면 좋겠습니다.

[yinhwa]

맞아요. 기술 문서에서 말하는 '리소스'들은 개인적으로는 '자원'보다 '자료'에 가까운 느낌이기도해서 저는 '참고 자료' 라고 쓰기도합니다 ㅎㅎ 물론 '자원'이 원칙적으로는 맞지만, 참고자료를 '자원'이라고 표기했을 때. 나를 도와주는 자료들이라기보다는 뭔가.... 더 거대한... 석유 자원.... 이런 느낌?이라서 ㅋㅋ

[ienground]

참고 자료라.. 일단 확인했습니다 ㅎㅎ

[Orwiss]

Redirect 같은 경우는 어떻게 번역하는 것이 좋을까요?

한국어로 바꿔서 부르지도 않는 것 같고.. 음차 번역을 어떻게 할까 검색을 해보아도
리다이렉트와 리디렉션이 팽팽하네요 ..
글자가 쓰인 것을 보면 리다이렉트가 맞지 않을까 싶다가도
구글에서는 리디렉션이라 쓰고 있네요..!

혼자 결정하기 힘들어서 이야기 나눠보고 싶습니다!

[yinhwa]

저도 그냥 음차해서 '리디렉션'이라고 번역해왔는데, 이분들 리다이렉트냐 리디렉트냐 말씀나누시는거 재밌네요 ㅋㅋㅋ 사실상 영국식이냐 미국식이냐 발음 차인데

아무튼, 영국/미국식 발음차이로 인해 자연스레 음차번역도 리다이렉트/리디렉트 두가지로 나뉜것 같구요! 개인적으로 '리디렉션'쪽으로 굳히게된건 감독을 '다이렉터'라고 안하고 '디렉터'라고 하는 것과 동일한 이유인데요, 언어는 어쨌든 간결하고 효율적인 쪽이 선호되니깐요 ㅎㅎ 좀더 친절하게 번역하자면 리디렉션(경로 재설정(?), redirection) 정도로 쓸 수 있을것 같아요!

한편, 개인적으로 "리디렉션됩니다"를 "리디렉트됩니다"보다 선호하는 이유는, 우리나라 문장 구조 영향도 있는것 같아요. 동사+동사가아닌, 명사+동사 결합...

[yinhwa]

근데 이 redirection 케이스 진짜 재밌는 것같아요. 전문용어 언어 장벽을 최소화하기위해 번역하는건데, 결국 주요 개념어들은 음차번역이되니,영국/미국발음 다른 경우엔 오히려 원래 영어 단어보다 더 헷갈리게 만드는 경향이 있었네요. 꼭 영문 병기를 해야겠습니다...^^

[ienground]

https://www.i-boss.co.kr/ab-1486505-38030
진짜 묘하긴 하네요. 사전에는 리디렉션이라고 하는 것 같기는 합니다.

[designerSejinOH]

저도 현업에서는 “리디렉션 시켜죠~“ 이런식으로 들어서 처음에 왜 리다이렉트라고 안 하고 리디렉션이라고 하지 했네요.. IT업계상 빠르고 효율적인 워크플로우를 지향하다보니 용어도 웬만하면 단축시키거나 간편하게 부르려고 하는 것 같아요.. 저도 리디렉션에 한 표입니다…

[yinhwa]

@yunyoungJang @wooknick @ienground @designerSejinOH

리포지토리(repository) vs. 저장소

윤영님의 이번주차 PR게시글을 리뷰하며 든 고민입니다. 윤영님은 "저장소"라고 직역해주셨는데요, 실제로도 꽤나 쓰는 표현인 것으로도 알고있습니다.

한편, 3월 2주차 연습과제 중 1문단 번역 연습 > 현우님이 확인하기를, 깃허브 한국어문서에서는 공식적으로 "리포지토리"라고 번역합니다.

참고로, 민욱님도 이번 주차 PR에서 우선은 "리포지토리"로 번역하였습니다.

개인적으로는 최대한 많은 단어를 한국어로 직역하는게 언어 보존 차원에선 필요하다고 생각하기도 해서요, "저장소(repository, 줄여서 'repo')" 뭐 이런식도 가능할 것 같습니다. 관련해서 여러분들의 의견을 여쭙고 싶었습니다 ㅎㅎ

[ienground]

GitHub가 영어 -> 한국어의 음차가 아닌 실제 번역을 '저장소'로 해줬으면 하는 게 가장 큰 바람이지만,
개인적인 의견은 - 현재는 그런 상황이 아니니 GitHub에서 제공하는 공식적인 번역으로 진행하는 것이 최선의 방법이라고 생각합니다.
하지만 말씀하신 것처럼 다른 예시와 비슷하게 병기하여 쓴다면 오인 가능성도 줄어들고 최대한 직역한다는 개념에서는 조금 더 적합한 것 같네요.

[yinhwa]

다른 한편으로는 리포지토리가 깃헙발 고유명사인가....? 싶은 생각도 드네요...ㅎㅎ;;

[designerSejinOH]

제 생각도 저희가 그저 번역기를 돌리는 작업이 아니라 직접 저희가 살아오면서 체화한 언어로 번역 그 이상의 작업을 한다는 의의가 있다고 생각이 들어서... 최대한 한글로 번역하고 병기하는 편이 좋다고 생각합니다. 리포지토리 또한 처음부터 '저장소'로 번역하고 사용해왔다면 지금 저희가 "repository가 저장소이다"도 어색하게 느끼지 않았을 것 같네요.. 조금씩 한글 원형이 개발 분야에서도 잘 스며들 수 있도록 저희부터 시작해보면 좋을 것 같습니다...!
저장소(repository) 에 한 표!

[yinhwa]

"Friendly Error System" -> "친절한 오류 메시지 시스템"

이유: 친절한 오류 메시지 시스템 프로젝트 리드(Alm Chung, 정앎님)의 한국어 표현 유지 (참고: https://almchung.github.io/p5-fes-i18n-book/)

[yinhwa]

어조 관련

원문에서 고수하는 친근한/구어체적 어조, 그리고 이 어조를 살리고자한 기존의 p5.js 한국어 번역 기여자님들의 스타일을 고려하는 건 어떨까요!

예:

• you ▶ '당신' 대신 '여러분'
• 종결어미 ▶ '주십시오' 대신 '주세요' 등

[yunyoungJang]

넵 기존의 p5.js 한국어 번역 기여자님들의 스타일을 고려해서 수요일까지 반영해보도록 하겠습니다! 공유해주신 자료도 참고해볼게요 🌸감사합니다.

[designerSejinOH]

코드베이스(codebase)는 어떻게 번역하는 편이 좋을까요?
코드베이스란 '소프트웨어를 빌드할 수 있는 코드가 저장된 저장소'인데 길게 풀어내야 이해가 되는 것 같고 이 내용을 함축적으로 담을 수 있는 단어가 생각이 안 나네요.. 그냥 코드베이스로 표기할지, 다른 한글 단어로 번역할지 의견을 구합니다..!

(해당 단어는 @ienground 님의 PR에서 사용되었습니다.)

[yinhwa]

일단 '코드베이스' 인터넷 검색결과를 살펴보니, '코드베이스'는 1) 어떤 저장소에 한 데 모여 저장된다, 2) 사람이 직접 작성했다 (위키피디아 참고) 는 특징이 있는것 같습니다 ㅎㅎ

위 성질에 따라 정말 직역하자면 "원천 코드 모음(codebase)"도 가능할 것 같고,
'코드'와 '베이스' 각각이 통어로서 사용되는 음차번역어임을 고려한다면 '코드베이스'도 나쁘진 않지만,

초심자의 이해도 + 단어의 효율성(글자수)를 고려한다면 **코드베이스(codebase, 원천 코드 모음)**와 같이 영문, 한글 풀이 모두를 병기하는 것도 좋을 것 같습니다. 물론 단어 최초 등장 시점 1회에 한해서요 ㅎㅎ

윤영님도 1차 과제 PR에서 '코드베이스'라는 표현 사용한 점 참고로 기록합니다!

[designerSejinOH]

@yinhwa 오오 넵넵!! 최초 등장 시점에 병기해서 표현해주면 괜찮을 것 같네요..! 감사합니다 ☺️

[ienground]

다른 분들은 Pull Request를 어떻게 번역하셨나요? 풀 리퀘스트 / 풀 요청 등등…
PR 처럼 줄여져 있는 건 상관없는데, 줄임말 없이 풀로 적혀 있는 아이들은 공식 번역어가 따로 없어서 조금 애매합니다.

그리고 command의 경우 저는 명령어로 번역하였는데, 명령/명령어 둘 다 전혀 이상하지 않아서 통일이 필요한 것 같습니다

[yinhwa]

좋은 질문 감사드립니다 ㅎㅎㅎ 제가 저희 풀리퀘 가이드라인 첫 줄에 포함시킨 깃허브 공식문서에 따르면 "끌어오기 요청"이라고 번역하는 것 같습니다.

음차번역 "풀 리퀘스트" (또는 심지어 더 줄여서 "풀 리퀘")나 깃허브 공식 번역어 "끌어오기 요청" 둘다 사실상 처음 접하는 분들 입장에서는 어려운 단어이기는 매한가지이네요 ^^; 이 둘을 합친 "끌어오기 요청(Pull Request, PR)"도 가능할 것 같구요!
한편, 공식문서에서 push는 또 그냥 "푸시"라고 번역하는 것 같습니다.

우선 우리팀 번역자님들의 이번 주차 과제에서나, 그 외 이전 p5.js 번역자님들은 "풀 리퀘스트(Pull Request, PR)" 음차번역(영문 병기)을 해온 상황인 점 참고로 말씀드립니다!

[yinhwa]

dependency = 종속성 vs 의존성?

저는 종속성이라고 써왔던것 같은데, 예원님은 의존성, 성훈님은 종속성이라고 번역해주셨네요 ㅎㅎ

어느것이 더 나은 표현일까요...

[designerSejinOH]

저는 또 의존성이라고 많이 써왔던 기억이... 흠...

[yinhwa]

흐흫 우선은 예원님은 의존성, 성훈님은 종속성 유지해두었습니다만 (영문병기 포함)

이것도 참... 용례가 사바사라 번역하기 어려운 단어같네요...^^

[yinhwa]

저는 또 의존성이라고 많이 써왔던 기억이... 흠...

다시 생각해보니 의존성이 종속성보다 덜 위계적인 표현이라, p5.js 커뮤니티 성향을 고려했을 때 부합하지않나싶네요...^^

[yinhwa]

제친구 금지원 큐레이터님 @ji.__.geum 의견 공유해봅니다 ㅎㅎ 미술 이론 관점에서는 이렇게 볼 수 있나봐요🤩 유의미한 해석입니다...ㅎㅎ

[yinhwa]

메서드 vs 메소드

라떼는 메소드라고 배웠는데, 요새 추세는 메서드인것같아서 한번 의논드려봅니다,,,^^

위키, 나무위키에는 메서드라고 표기하는 것같고, 관련 업계분들은 "메서드"가 더 정확한 표현이다라고 논의하는것같아요! (국립국어원에선 메소드 연기는 또 그냥 메소드라고하더라구요)

[wooknick]

이번에 새로 제작한 2024 한국어 색인에는 method가 포함되어 있지 않고, 2020년 색인에는 메소드라고 되어 있어서 요걸 기준으로 '메소드'로 사용중이었습니다.

근데 사실 저도 '메서드'가 더 익숙하긴 해요..😅

[yinhwa]

아아맞아요 ㅠㅠㅠㅠ그때만해도 아마 제가 메소드로 확인했어서 그렇게 번역했던것같은데,
이제는 메서드가 대세인?것같기도해서 민욱님께서는 한번 고민해보시고 더 나은 + 편하신 표현으로 사용하시는게 좋을것 같습니다 ㅎㅎ 그리고 빠른 리뷰리퀘들 감사드립니다! 곧 캐치업할게요오

[designerSejinOH]

저 또한 여러 글에서 메소드라고 봐왔어서 메소드로 사용해왔는데... 메소드 연기 라는 국어원 예시를 보니 갑자기 메소드라고 번역했던게 어색해지네요😅 우선 메서드에 한 표 던지겠습니다!

[ienground]

String 문자열 Constant 상수로 맞춰서 번역하고 계신 걸로 알고 있는데,
Any는 어떻게 하고 계시는지 궁금합니다.
(참고: 코틀린 언어에서 아무 타입이나 다 될 때도 Any를 사용하고 있는데, 이를 그냥 Any로 할지 아니면 타입 상관 없음 정도로 할지...)
일단은 Any로 두려고 합니다

[yinhwa]

매개변수의 하위 내용 설명이라면, Any = "모든 변수 유형" 도 가능할 것 같습니다!

그리고 매개변수라는 서브헤딩자체가 어느정도 설명해주는 것이 있기 때문에, 상수/숫자/정수/문자열은 굳이 영문 병기는 안해도될것같습니다!

[ienground]

감사합니다~

[ienground]

번역을 하면서 타입을 그냥 원문을 살리는 게 맞다는 생각이 계속 드네요.
String을 문자열로 번역해왔지만, String[] 이런 식으로 적혀있다는 건 문자열 배열 이렇게 쓰는 게 아니라 그냥 타입 자체를 나타내는 것으로 보여서..

[yinhwa]

아아! 저는 가독성때문에 말씀드렸던건데, 보다 정확한 정보 전달 차원에서 현우님께서 그리 생각하신다면 저도 동의합니다 :) 의견 공유 감사드려요오오!!

[designerSejinOH]

저 또한 현우님 의견대로 String[]으로 살려두는게 좋다고 생각이 드네요. 코드상세서 String 혹은 []자체가 배열을 사용할 때 직접 쓰이는 코드 자체이기에 번역본이어도 살리는 편이 좋다고 생각합니다..!

[yinhwa]

primitive shape = 기초 조형 vs. 기본 조형 / 기초 도형 vs. 기본 도형

현우님 이번주차 풀리퀘에서 나온 논의안입니다. 다른 기여자님들께서도 혹시 번역 작업중에 이 단어 발견하시면 의견 부탁드립니다 ㅎㅎ @ienground @wooknick @Orwiss @yunyoungJang @YewonCALLI @designerSejinOH

[yunyoungJang]

제가 보기엔 조형이 더 큰 개념으로 해석되어서
레퍼런스에 적합한 단어를 선택하면 좋을 듯해요.

도형(점, 선, 면) < 조형(모양, 크기, 비례, 질감 등)

[yinhwa]

@yunyoungJang 대박쓰 ^^ 전공자의 코멘트 감사드립니다! 현우님 경우에도 그렇고 primitive shape 로 표기한 레퍼런스/예제 모두 다 "기초/기본 도형"이 맞는 맞겠다는 생각이 듭니다 :)

[ienground]

넵 1차 리뷰 피드백 내용 주셨을 때 같이 수정해서 커밋하겠습니다 👍 👍

[designerSejinOH]

Geometries

기하 vs 지오메트리

민욱님 이번주차 p5.js 예제 번역에서 나온 저희가 흔히 3D 도형을 만들때 접하는 단어, Geometries 입니다!
기존 p5.js 한국어 사이트에서는 "기하"라고 번역해주셨었는데요. 여러 번역기를 통해서도 기하 또는 기하학으로 번역되는 경우를 보았습니다. 다만, 주변에 3D 그래픽 관련 종사자 분들의 이야기를 들어보면 민욱님께서 번역해주신 것처럼 "지오메트리" 영문 그대로 사용하는 경우가 많다고 합니다. 해당 예제는 p5.js 상에서 3D 도형들을 그리는 예시입니다! 관련해서 다른 분들도 의견주시면 감사하겠습니다 :)

[yinhwa]

논의 감사드립니다! 우선, 예제 맥락상 "기하학"은 아닌것 같은데요! (기하의 원리를 학문적으로 파고드는 건 아니기 때문에...?ㅎㅎ)
기존 번역에서 저는 학창시절 수학과목에서 '기하'로 배웠던 점(즉, '기하'라는 단어의 범용성)을 고려해서 '기하'라고 번역해두었음을 참고차 말씀드립니다. 기하(geometry)로 병기하는 것도 가능할 것 같구요 :)

[designerSejinOH]

@yinhwa 병기하는 편이 좋아보이네요!! 감사합니다 :)

[YewonCALLI]

저도 고등학생때 자주 들어서 그런지, '기하'라는 단어가 더 익숙한 것 같아요! 지오메트리라고 부르는 곳도 있군용..👀👀

[wooknick]

제목으로 사용되는 경우에는 '기하'가 적당해 보이는데, 맥락에 따라 '지오메트리' 그대로 번역해야 하는 상황도 있지 않을까 합니다. 이를 테면, 지오메트리를 생성하거나 변경한다는 표현은 익숙한데, 기하를 생성하거나 변경한다는 표현은 다소 어색하게 느껴지는 것 같아서요. 개념을 이야기할 때에는 '기하'를, 실제로 생성되는 객체를 이야기할 때에는 '지오메트리'를 쓰는건 어떨까요?

[YewonCALLI]

anchor를 어떻게 번역할지 고민하다 발견한 글입니다!
디자인 업계에서도 anchor, handle과 같은 외래어를 어떻게 한국어로 번역하여 소통할지 막막한 경우가 많은가 봐요.

https://11172.kr/article/?q=YToxOntzOjEyOiJrZXl3b3JkX3R5cGUiO3M6MzoiYWxsIjt9&bmode=view&idx=14540075&t=board

[yinhwa]

좋은 논의 & 자료 공유주셔서 감사드립니다 🙏🙏 저도 많은 공부되었습니다 ㅎㅎ

[ienground]

Material, Texture 단어가 반복적으로 나오고 있어 하나의 단어로 번역 통일이 필요할 것 같아 커멘트 남깁니다!
재질, 질감 정도로 통일하는 게 좋을 것 같은데, 어떻게 생각하시는지 궁금합니다. 텍스처도 가능할 것 같구요..

[yinhwa]

저는 말로는 매테리얼, 텍스처라고 하긴하는데, 재질(material), 질감(texture)도 가능할 것 같습니다 :) 좋은 의견감사드립니다아

[designerSejinOH]

저도 재질(material), 질감(texture)이 좋을 것 같습니다!

[yunyoungJang]

tightness -> 타이트니스,
tight -> 타이트
곡선에서의 점의 좌표 이야기를 할 때 음차 번역이 적절할까요?
curveTightness(1) 라고 되어있어서 그대로 변역을 하는 것이 좋을 것다는 생각이 드는데,

description: |

amount of tightness.

를

타이트니스의 정도.

라고 표현하니 어색하기도 해서 의견 여쭤봅니다.

[wooknick]

밀도 같은 표현도 가능할 것 같아요.

[yinhwa]

수학+그래픽 맥락에서 봐야되는 표현같은데, 우선 기계번역 직역은 "곡선 견고성"이 나오고,
문맥(예1: 곡선과 면/점 등 다른 조형 요소와 얼마나 붙어있는지, 예2: 곡선 1개의 팽팽함 정도? 등)에 따라서는 "곡선 긴축 정도/긴축도" 도 가능한 것 같습니다 :) 좋은 논의 감사드려요!

[Orwiss]

저는 '팽팽함' 정도로 생각하고 평소에 그렇게 말하긴 합니다 ㅎㅎ..

[YewonCALLI]

혹시 예제 코드의 주석도 번역하고 계신가요? 주석이 코드에 대한 간략한 설명이라 번역하고 있기는 한데 다들 어떻게 하고 계신지 궁금해서 올려봅니당!!😆

[yunyoungJang]

예제코드는 번역 안하고 있습니다. 🫢 ㅠㅠ

[yinhwa]

주석은 <code> 태그 사이의 내용이라 아쉽게도/다행히도(?) 번역 범위가 아닙니다! 2차 과제랑 번역범위 동일하니 참고 부탁드려요 :)

[yinhwa]

"up" vector - "업"벡터 vs "상향"벡터

어떤 표현이 더 적합할지요? 현우님 @ienground 은 전자로, 성훈 @Orwiss 님은 후자로 번역중입니다. 두 분께서 통일된 표현을 쓰는게 좋을것 같은데요, 다른 분들의 의견도 구해봅니다 ㅎㅎ

[ienground]

번역에 의의가 있는 만큼 제가 상향 벡터로 수정하는 방향으로 하겠습니다~

[yinhwa]

"world" space & "local" space

저는 3D작업할 때 주로 "월드"와 "로컬"이라고 많이 써왔는데요, 현우님이 @ienground "세상" "지역"이라고 직역해주신 것에서 영감?을받아 ㅎㅎ 한글화가 필요할지 여러분의 의견을 여쭙습니다. @Orwiss @wooknick @yunyoungJang @YewonCALLI @designerSejinOH

[yinhwa]

헐 넘 멋지네요 ^^ 저희도 세상으로 갈까요.... @Orwiss

[yinhwa]

저같은 라떼들을 위해 세상(world) / 지역(local) 병기도 필요할 것 같습니다 ㅎㅎ

[Orwiss]

간단히 찾아봤는데 '세계'와 '지역'으로 표기한 사례들이 조금 보이는데
'세계'라는 표기는 어떠신지요!

[yinhwa]

@Orwiss 오 저는 세계도좋은것같습니다! 🌏 좋은 의견 감사드립니다.

[ienground]

세계로 모두 수정했습니다!

[yinhwa]

orthographic projection - 직교 투영, 정사영, 정투상도...

@ienground @Orwiss 님들께 해당하는 부분인데요! 성훈님은 직교 투영, 현우님은 정사영이라고 번역주셨습니다!
두분께서 단일 표현으로 통일하심 좋을 것 같습니다 :)

[ienground]

일단 정사영이 조금 더 많이 쓰이는 단어가 아닌가 싶긴 합니다 (고등학교 교육 과정을 포함하여...)

[Orwiss]

정사영이 좀더 잘 어울리는 것 같습니다
저도 '정사영'으로 표기하겠습니다!

[yinhwa]

vertex - 꼭짓점 vs. 정점

번역자님들 사이에서 꼭짓점 vs. 정점이 나뉘는 것 같은데 통일하는게 좋을것같아 의견을 여쭤봅니다! @yunyoungJang @ienground @wooknick @Orwiss @YewonCALLI @designerSejinOH

[wooknick]

개인적으로 p5.js와 같은 3D 작업을 할 때에는 정점이라고 썼던 것 같습니다. 꼭짓점은 주로 기하학적인 관점에서 도형을 언급할 때만 썼던 것 같아요.

[yunyoungJang]

저는 한국어색인을 보고 모두 꼭지점(꼭짓점)으로 표기했는데, 고민이네요🥲

[ienground]

저도 3D 작업에서는 정점으로 많이 봤던 것 같습니다.

[yinhwa]

오 그렇다면 3D에서는 정점, 2D에서는 꼭짓점 이렇게 가도 무방할까요??

[YewonCALLI]

저도 3D에서는 정점이라는 말을 자주 썼던 것 같아요!! 2D/3D 분류하여 표기하는 것도 좋은 방법인 것 같습니다!

[YewonCALLI]

fragment shader 표기법이 고민됩니다.
3D 부분에 vertex shader과 fragment shader이 자주 나오는데 vertex shader은 정점 셰이더로 많이 쓰는 것 같고
fragment shader은 찾아보니 그냥 프레그멘트 셰이더로 쓰는 것 같더라고요,,, (단편 셰이더라고 쓰시는 분도 있는 것 같습니다)
혹시 fragment shader의 한글 표기법에 대해 아시는 분 있다면 코멘트 부탁드립니다🙏

[yinhwa]

단편 셰이더(fragment shader)도 가능할 것 같고,

우선 저희팀 다른 번역자님의 경우 프레그먼트 셰이더(fragment shader)로 진행한 점 참고차 말씀드립니다 :) 좋은 논의 감사드려요!!