기존 버전 표 잔재 (구성 업데이트 필요)

웹 브라우저

웹 브라우저

바로가기 오류

기본 정보 서식 적용 필요

이 목차는 내용이 날아갔네요 -_-;;; 개편할 때 날려먹은 듯... 인가 코드 받기에 channel_public_id 쿼리 파라미터가 추가로 있는데, 별도 건으로 처리하는 게 좋겠어요.

영어

영어

영어

영어

영어

영어

영어

영어

영어

영어

영어

영어

영어

영어

영어

영어

영어

영어 남았어요

이후에 부연 설명 박스로 분리해야 할 내용이 있는지 검토합니다.

한 가지 유형의 박스가 언제나 같은 역할을 수행하도록 일관되게 사용해야 합니다.

묘하게 두 번 읽게 되어서 언제나 넣어봤어요.

앞 문장을 받아줄 수 있어야 할 것 같아요.

꼭 필요한 경우에만 이미지 사용을 고려합니다.

이후에가 본문으로 다 설명한 후에..? 인가 싶어서요.

독자가 정보에 집중하는 것을 돕고, 설명 대상이 아닌 다른 부분의 변경으로 인한 불필요한 유지 보수 비용을 줄일 수 있습니다.

하이라이트

표시하고

설명할 때

표기합니다.

을 설명할 때만

수동태 문장은 주어가 생략되어 주체가 분명하지 않거나, 불필요한 단어가 추가되어 복잡해질 수 있습니다.

능동태 문장으로 주어를 강조해, 정보를 명확하고 간결하게 전달할 수 있도록 작성합니다.

대상 한정 표현이 어떤 것인지 알 수 없어요. 아래와 같이 풀어 써 봤는데 의미 맞나요?

웹 페이지(Web Page) 문서는 누구든지 언제나 접근할 수 있으므로 현재 시점으로 작성합니다.

본문 첫 문장에서 그 의미를 설명하면

이 문장은 이해하지 못했어요.

다른 문서에는 바로가기 제공

배포 전에는 이미지로 대체되어야 해서 하이라이트 처리

문서의 모든 내용을 담는 것 자체보다는, 문서의 내용을 쉽고 빠르게 찾을 수 있도록하는 목적이 더 중요할 것 같아요.

구체적 VS 간결함 서로 대치되는 가치가 있어서, "명확하게"라는 표현으로 대체해보면 어떨까요.

가독성과 학습성을 높일 수 있습니다.

여기도 사용했습니다가 더 나을 것 같네요.

용어 하위 항목으로 분리하는 게 좋겠어요. 둘이 다른 성격의 내용이라서요.

없는 게 더 좋을 것 같아요.

표현합니다. 표기합니다. 표시합니다.

볼드 처리

요거 어미 규칙 위반이네용 (기존 문서에 있는 것... ㅠㅠ) 예시로는 다른 걸 써야겠어요.

표기합니다.

시간대

하시기

로

문장 초반에 거의 같은 표현이 있어서. RFC8417로 표기해주는게 좋겠어요.

를

사용합니다.

병기합니다. 함께 작성합니다.

첫 글자

1. 우리 문서는 이런 규칙으로 작성했으니 참고하세요!
2. 우리 문서는 이런 규칙으로 작성해야 해요!

둘 중 어느 목적으로 제공하는 문서인지 좀 더 명확히 할 필요가 있어 보여요.

1번이라면, 카카오디벨로퍼스는 문서에 일관된 스타일을 적용해 가독성과 학습성을 높이고자 노력하고 있습니다.

2번이라면, 문서를 독자가 더 쉽게 이해하고 읽을 수 있도록 일관된 스타일을 적용합니다.

사용합니다.

웹 페이지? 문서? 페이지?

없어도 될 것 같아요.

문서 창으로 띄어 써야 할 것 같네요... (맞춤법 검사기로는 둘 다 문제 없음이지만 앞쪽에서 별도 창으로 띄어 써서 뒤에도 띄어 쓰는게 좀 더 자연스러운 느낌?)

의미를 정확하게 이해하지 못했어요.

이미지(Image) 속 문구

버튼, 박스 등 UI 요소명을...

글자 서식 - 굵은 글꼴 - 레이블

이렇게 하위 항목으로 나누는 게 좋겠어요.

고정폭 글꼴이라는 표현이 특정 서식을 가리키는 건 아니다보니, 곧바로 이해되지 않아서 대체 표현 찾아봐야 할 것 같아요.

?테크니컬라이팅 FM에서는 대상을 정확하게 지칭하는 걸 중복 문제보다 우선시하기 때문에, 의견이 분분할 수 있어요.

두 가지를 명확하게 구분해서 이해하기 어려울 것 같아요.

숫자, 날짜, 시간, 예시와 같이 하위 항목으로 분리해주는 게 좋겠어요.

일반적인 한글 맞춤범(한국어 어문 규범)을 따르는 걸로 갈음할 수 있을 것 같아요

첫 번째, 두 번째와 같이 특정 요소를 평문과 구분해서 보여주는 표기 규칙이라 여기에 묶이면 안 될 것 같아요.

작문

용어

목차명은 "왜" 굵은 글꼴을 사용해야 하는지여야 합니다. 굵은 글꼴 사용하기는 "특정 요소를 구분해 표기하기 위한 방법" 중에 하나일 뿐이기 때문입니다.

1. 목차 기술기획팀 스타일 가이드, 기존 스타일 가이드와 마찬가지로 요소별 규칙을 빠르게 찾고 확인할 수 있도록 구성했으면 합니다.

2. 목적 카카오디벨로퍼스 스타일 가이드는, 카카오 문서 스타일 가이드의 확장판입니다. 카카오 문서 스타일 가이드에는 없지만, 카카오디벨로퍼스에 적용하는 규칙을 정의하고 공유하는 용도의 문서여야 하므로, 이 목적에 부합하는 내용으로 구성되기를 바랍니다.

3. 예시 각 규칙에 대한 실제 작성 예시를 명시적으로 같이 보여줬으면 합니다.

한 폴더에 저장 가능한 최대 파일 개수를 초과한 경우

확장자가 없는 경우

한 폴더에 저장 가능한 최대 파일 개수를 초과한 경우

개수가 맞대요

한 폴더에 저장 가능한 최대 파일 개수를 초과한 경우

파일 경로! (curl에서 테스트해보시면, 현재 내가 있는 위치 아닌 곳의 파일을 지정할 때는 경로를 입력해야 해요)

External (이하 동일)

External

이거는 External URL이에요! Internal URL은 /internal/ 포함 아래 예제도 보시면 https!

최초 언급 시점이니 영문 병기해주심 더 좋을 듯요! 바디도요!

업로드할 바이너리 파일 경로

기본 정보 표와 마찬가지로 레이블 처리해주면 더 좋을 거 같아요! https 맞죠? (우리 KAPI의 internal 요청 시에는 http라서 확인차 질문)

좀 더 짧게 쓴다면

톡서랍 플러스 REST API의 페이즈별 호스트는 아래와 같습니다.

구독 중인 (이하 동일)

위에 제목이 제한 사항이라 잘 보면 이해될텐데, 제대로 안 읽으면 이해 못할 수도 있을 것 같아서 좀 더 부연해주는 게 좋겠어요. 5단계 이내까지만 허용 불가능에서 6번째 뎁스부터 안되는 예제 있고 해서, 더 간략히 기재할 수도 있을 것 같아요.

에가 조금 더 자연스러울 것 같네요.

업로드 시 서비스 폴더 하위의 특정 경로를 지정해 백업할 수 있다?

사용자 동선?

조금 더 풀어 쓰는게 이해하기 쉬울 거 같아요. 톡서랍 플러스 상품을 구독 중인 사용자 대상으로만 요청 가능 또는 사용자가 톡서랍 플러스 상품을 구독 중인 경우 라든가...

반복되는 것 같아서, API 사용 권한 필요?

사용처는 하나의 서비스일거라, 다양한 서비스 데이터로 읽히면 어색할 수 있으니...

사용자의 다양한 서비스 데이터?

레이블 처리

레이블 처리

레이블 처리

레이블 처리

비즈 앱 비즈니스 채널 기존에 요렇게 띄어쓰기 하고 있었어요.

아래 세 가지 용도로 활용됩니다.

필드 이름이라 레이블 처리 필요해보여요.

필드 이름이라 레이블 처리 필요해보여요.

바로 위에 참고 링크가 있어서 반복하지 않아도 괜찮을 것 같네요.

바로가기 이름이 REST API여야 하는데 일단은 넘어가는 것으로... (바로가기 대상 문서 이름)

앞 문장과 사실상 같은 내용을 반복하고 있어요.

아래 사항을 준비해야 합니다.

용어 불일치

용어 불일치 카드로 줄여 부르고 싶다면 일관되게 싹 줄여야 해요.

용어 불일치

문장이 매끄럽지 않은 것 같아요. 목적어(~를)이 두 번 반복되어서 그런 것 같습니다. 쉼표 사용해서 두 개로 나눠보거나... 총 3종류의 행동을 안내하고 있고, 행위가 발생하는 장소는 모두 카카오톡 지갑인 것 같네요! 카카오톡 지갑이 먼저 언급되는 게 문장 구조상 깔끔해 보입니다.

사용자는 카카오톡 지갑에서 발급받은 디지털카드를 확인하거나 삭제할 수 있고, 카카오톡 친구에게 보낼 수도 있습니다. 등등... 방법은 여러 가지

이런 경우, 아래 이미지는 이해를 돕기 위한 사용자 본인인증 포함 발급 과정입니다. 조사를 일정 부분 삭제하는 게 문장이 더 깔끔하고 이해하기 쉬울 수 있어요.

바로 앞에 나온 용어와 일치하지 않음 & 하단 이미지에도 다른 용어를 사용함

검증하기 위해, 쉼표 쓰면 읽기 쉽겠어요

용어 불일치

카카오계정 정보를 조회합니다.

카카오계정 ID 정보를 조회한다면 account_id 자체의 유효성이나 존재 여부 같은 더 작은 개념이 되는 것 같습니다.

만14세 미만 사용자는 보호자동의가 필요해요. (카카오 로그인 등)

https://wiki.daumkakao.com/pages/viewpage.action?pageId=560471387

계정에서 사용하는 용어는 "보호자 동의"이고, 토큰 이름은 "보호자 동의 토큰"이 되겠네요.

추가: 동의 항목 추가에만 필요한 게 아니어서, 보호자 동의 토큰이라고만 기재해주는 게 나아보여요.

보호자 동의 용어 교체가 안 된 곳이 있어요!

의미가 구체적으로 명확하지 않은 것 같아요. 고쳐본다면... 주어진 ID 목록에 해당하는 카카오계정 정보를 조회합니다.

이 값은 임의의 문자열로 바꿔서 실제 값처럼 보여주는 게 좋을 것 같아요. 앱 키 등 크리티컬한 정보는 변수 처리해야 하지만, 이런 값들은 응답의 실제 값 포맷을 궁금해할 수 있어서요.

3rd에는 제공 안하는 ID라 제휴 API 가이드에 없어야 할 거 같아요. 릴리 확인 필요.

3rd에는 다른 서비스의 앱에 대한 요청은 안 열어주실 것 같네요. 확인 필요. (channel_app_id 파라미터와 관련 권한 제공 여부 확인 필요)

이거 저의 안 좋은 뇌절 습성이 남아 있는 부분인 거 같은데, 이 문장 따로 안 빼고 아래 앱에 설정된 카카오톡 채널에다가 바로 링크 거는 게 더 좋을 거 같아요. 참고하라그러면 안 볼듯.

공개 프로필 ID

오픈 가이드에도 별도 문서 만들고, 그거 링크해줘야 할 것 같아요. 외부 제공 용도네요.

(../getting-started/app#app-key)

(../getting-started/app#app-key)

링크 상대 경로로 (../~~)

(../getting-started/app#team)

링크 상대 경로로

(../kakaologin/prerequisite#redirect-uri)

링크 상대 경로로

(../kakaologin/prerequisite#redirect-uri)

링크 동작은 잘 되는데 혹시 몰라서 . 1개 추가

Activate Kakao Login

발급받은

발급받은

에러 페이지

동의 과정

앱

앱

• 앞서서 쭉 앱이라고만 기재했어요~

카카오톡 채널

카카오톡 채널

Description의 에러 메시지들 레이블 처리 해야할 거 같아요. 갑자기 이게 뭔가 했어요;;;

Required PLUS_FRIENDS_ON_AGREEMENT_SUPPORTED permission

이번에 업데이트하는 김에 같이 해주시면 매우 감사하겠읍니다...

${response_type}

등록된 Redirect URI를 인가 코드 요청의 redirect_uri 값으로 사용합니다.

등록된 Logout Redirect URI를 로그아웃 요청의 logout_redirect_uri 값으로 사용합니다.