[습과어플]#7 (커밋해둘걸..)

개발/유니티

[습과어플]#7 (커밋해둘걸..)

kimchangmin02 2025. 9. 4. 21:26

인스펙터를 보면서 메이플 글씨체 아닌곳 찾아보자

버튼이나, 그냥 text mesh pro랑 다르네

왜 전부 다 삭제해도 괜찮을까요?

Library 폴더 안에 있는 PackageCache, ScriptAssemblies, ShaderCache 등 수많은 폴더들은 모두 **'임시 작업 결과물'**입니다.

이것을 '요리'에 비유하면 쉽게 이해할 수 있습니다.

Assets 폴더: 요리의 **'원본 레시피'**와 '원본 재료'(밀가루, 계란, 설탕 등)입니다. 이것만 있으면 언제든지 다시 요리를 만들 수 있습니다.
Library 폴더: **'요리하는 과정에서 생긴 모든 것'**입니다.
- ScriptAssemblies: 레시피(스크립트)를 보고 셰프(컴파일러)가 이해할 수 있도록 번역해 놓은 메모.
- ShaderCache: 재료(이미지)를 오븐에 어떻게 구울지(렌더링) 미리 계산해 놓은 결과.
- PackageCache: 마트에서 사 온 기성품 소스(패키지)들을 잠시 보관해 두는 곳.
- 기타 모든 캐시(Cache) 폴더들: 요리하는 동안 잠시 사용했다가 버려도 되는 임시 그릇이나 도구들.

만약 주방이 너무 더러워져서 요리를 할 수 없게 되면, 가장 좋은 방법은 주방 전체를 깨끗이 대청소하는 것입니다. 설거지통에 있는 모든 그릇, 조리대에 널브러진 모든 도구들, 오븐에 남아있는 찌꺼기들을 전부 치워버리는 거죠.

**Library 폴더를 삭제하는 것이 바로 이 '주방 대청소'**입니다.

청소가 끝나고 다시 요리를 시작하면(유니티를 다시 켜면), 셰프는 '원본 레시피'와 '원본 재료'(Assets 폴더)를 보고 필요한 모든 도구와 중간 결과물(Library 폴더 내용물)을 처음부터 다시 깨끗하게 만들어냅니다.

주의사항

Library 폴더 자체를 삭제하세요: 안의 내용물만 하나씩 지우는 것보다, stopBadHabitApp 폴더로 돌아가서 Library 폴더 자체를 선택하고 Shift + Delete로 삭제하는 것이 가장 확실합니다.
시간이 걸립니다: 대청소 후 처음 요리를 시작하면 평소보다 준비 시간이 오래 걸리듯, 유니티를 다시 켜면 모든 것을 재구성하느라 시간이 오래 걸립니다. 인내심을 갖고 기다리는 것이 매우 중요합니다.

요약: Library 폴더는 유니티가 '알아서' 관리하는 임시 공간이므로, 그 안의 모든 내용물은 사용자가 직접 건드리거나 보존할 필요가 전혀 없습니다. 문제가 생겼을 때 통째로 삭제하는 것이 가장 안전하고 확실한 해결책입니다.

현재 UI가 깨지는 원인과 해결책 (가로 스크롤바)

"너무 긴 거는 잘려서, 저렇게 된 거 같은데 가로 스크롤바 추가해야겠는데"

네, 정확합니다. 현재 UI가 깨지는 직접적인 원인은 TextMeshPro 텍스트의 Overflow (넘침) 설정 때문입니다.

현재 상태: Overflow 옵션이 기본값인 **Overflow**로 되어 있을 가능성이 높습니다. 이 옵션은 텍스트가 자신에게 주어진 사각형 영역(Rect Transform)을 벗어나면, 그냥 무시하고 계속 그려서 다른 UI를 침범하게 만듭니다.
해결책: 말씀하신 대로, 긴 텍스트를 담기 위해서는 Scroll View를 사용하는 것이 가장 좋은 방법입니다. 하지만 RecordItemPrefab 하나하나에 Scroll View를 넣는 것은 너무 복잡하고 비효율적입니다.

더 좋은 해결책: Text의 Wrapping & Overflow 설정 변경

RecordItemPrefab을 수정하여 텍스트가 길어지면 자동으로 줄바꿈이 되도록 만드는 것이 훨씬 더 좋은 사용자 경험을 제공합니다.

프로젝트 창에서 **RecordItemPrefab**을 엽니다.
프리팹 안의 DetailText, TagsText, SolutionText 를 각각 선택합니다.
Inspector 창의 TextMeshPro - Text (UI) 컴포넌트에서 아래 설정을 변경합니다.
- Wrapping: Disabled를 **Enabled**로 변경합니다. (자동 줄바꿈 켜기)
- Overflow: Overflow를 Ellipsis(긴 글은 "..."으로 표시) 또는 Truncate(그냥 자름)로 변경하여 다른 UI를 침범하지 않도록 합니다. 지금 상황에서는 **Ellipsis**가 가장 적합합니다.

이렇게 하면, 텍스트가 길어져도 정해진 영역 안에서 줄바꿈이 되거나 "..."으로 표시되어 전체적인 레이아웃이 깨지지 않습니다.

에러 메시지 분석: 범인은 누구인가?

SendMessage cannot be called during Awake, CheckConsistency, or OnValidate...
...OnDidAddComponent)

이 메시지를 쉽게 번역하면 이렇습니다.

"지금 유니티가 막 깨어나거나(Awake), 자기 상태를 점검하는(CheckConsistency, OnValidate) 아주 민감한 작업을 하는 중인데, 이때 SendMessage라는 확성기(다른 오브젝트를 부르는 기능)를 사용하려고 시도했습니다. 이 타이밍에는 확성기 사용이 금지되어 있습니다."

그리고 호출 스택(에러가 발생하기까지의 과정)을 보면 범인을 찾을 수 있습니다.

TMPro.EditorUtilities.TMP_InputFieldEditor:OnInspectorGUI(): 유니티 에디터의 Inspector 창에서 InputField를 건드렸을 때 시작됩니다.

TMPro.TMP_InputField:OnValidate(): Inspector 창에서 값이 변경될 때 호출되는 함수입니다.

TMPro.TextMeshProUGUI:SetArraySizes(): 텍스트를 분석하고 표시할 준비를 합니다.

TMPro.TMP_SubMeshUI:AddSubTextObject(): 바로 이 부분이 핵심 범인입니다!

UnityEngine.GameObject:AddComponent<T_REF>(): 새로운 컴포넌트를 추가하려고 합니다.

GameObject::SendMessageAny: 그리고 그 과정에서 '확성기'를 사용하다가 에러가 발생했습니다.

그래서 무슨 일이 일어나고 있는 건가요?

TMP_SubMeshUI는 TextMeshPro의 매우 특별한 기능입니다. 바로 '폴백 폰트(Fallback Font)' 시스템과 관련이 있습니다.

사용자가 InputField에 글자를 입력하거나, Inspector 창에서 값을 변경했습니다.
TextMeshPro는 Maplestory Bold SDF 폰트 에셋을 사용해 글자를 표시하려고 합니다.
그런데, Maplestory Bold SDF 폰트 에셋에 없는 글자(예: 특수문자, 이모지, 또는 다른 언어)를 발견합니다.
이때 TextMeshPro는 포기하지 않고, 미리 설정된 **'대체 폰트(Fallback Font)'**를 찾아봅니다. (스크린샷에 보이는 **LiberationSans SDF**가 바로 TextMeshPro의 기본 대체 폰트입니다.)
"아! 이 글자는 'LiberationSans' 폰트에는 있구나!" 라고 판단하고, 글자 렌더링을 위해 TMP_SubMeshUI라는 보조 오브젝트를 동적으로 생성하려고 합니다.
문제는 이 모든 과정이 Inspector 창이 업데이트되는 OnValidate라는 매우 민감한 타이밍에 일어나고 있다는 것입니다. 이 타이밍에 동적으로 오브젝트를 만들고 컴포넌트를 추가하며 SendMessage를 호출하는 복잡한 작업이 꼬이면서 유니티가 "지금은 안돼!"라고 에러를 발생시키는 것입니다.

"왜 폰트 두 개가 뜨는 거죠?"

스크린샷에 보이는 Maplestory Bold SDF Material과 LiberationSans SDF Atlas 두 개가 뜨는 이유는, TextMeshPro가 현재 텍스트를 표시하기 위해 **주 폰트(Maplestory)**와 **대체 폰트(LiberationSans)**를 모두 사용하려고 시도하고 있기 때문입니다.

LiberationSans는 TextMeshPro 패키지에 기본으로 포함된 폰트로, 영문/숫자 등을 표시하기 위한 기본 폴백으로 설정되어 있는 경우가 많습니다.

해결 방법

이 에러는 게임 실행 자체를 막는 심각한 오류(빨간색 에러)가 아니라, 에디터 상에서 발생하는 경고(노란색 느낌표)에 가깝습니다. 하지만 찝찝하니 해결하는 것이 좋습니다.

해결책 1: Fallback Font 설정 명확히 하기 (가장 추천)

프로젝트 창에서 Maplestory Bold SDF 폰트 에셋을 선택합니다.
Inspector 창을 아래로 스크롤하여 Fallback Font Assets 리스트를 찾습니다.
여기에 LiberationSans SDF가 연결되어 있다면, 연결을 해제하고 리스트를 비워보세요. (Element 0을 선택하고 '-' 버튼 클릭)
만약 우리가 만든 새로운 한글 폰트 에셋 외에 다른 언어나 특수문자를 표시할 필요가 없다면, Fallback 기능을 꺼두는 것이 이런 예기치 않은 충돌을 막을 수 있습니다.

해결책 2: TextMeshPro 패키지 재설치 또는 업데이트

가끔 TextMeshPro 패키지 자체의 버그일 수 있습니다. Package Manager를 통해 TextMeshPro를 최신 버전으로 업데이트하거나, 완전히 제거했다가 다시 설치하면 문제가 해결되기도 합니다.

해결책 3: 임시 해결 (무시)

이 에러가 게임 플레이에 직접적인 영향을 주지 않고, 에디터에서 UI를 조작할 때만 간헐적으로 나타난다면, 일단 무시하고 다른 기능 개발을 먼저 진행하는 것도 방법입니다. 하지만 폰트 에셋 설정이 꼬여있다는 신호일 수 있으므로, 해결책 1을 시도해보는 것을 가장 권장합니다.

"INPUTFIELD를 클릭해도 입력하도록 깜빡거리지가않네"

이것은 정말 중요한 문제를 정확히 찾아내신 겁니다! 말씀하신 **Raycast Target**이 바로 그 원인이 맞습니다.

문제의 원인: "투명 유리벽"

Panel을 만들고 배경색의 알파(A) 값을 0으로 만들어 우리 눈에 투명하게 보이도록 설정했습니다.

하지만 유니티의 UI 이벤트 시스템에게는, 이 Panel이 여전히 **"투명하지만 존재하는 거대한 유리벽"**처럼 인식됩니다.

사용자가 화면의 InputField 부분을 터치(클릭)합니다.
유니티는 화면 맨 앞에서부터 마우스 포인터 아래에 무엇이 있는지 검사합니다(Raycast).
UsedTagsPanel이나 SelectedTagsPanel이 InputField보다 앞에 있거나, 혹은 더 큰 영역을 차지하고 있다면, 유니티는 "아! 여기엔 투명한 Panel이 있군!"이라고 판단합니다.
그리고 이 Panel의 Raycast Target 옵션이 켜져 있으므로, 마우스 클릭 이벤트를 이 Panel이 가로채서 먹어버립니다.
결과적으로, Panel 뒤에 있는 InputField에게는 클릭 신호가 전달되지 못하고, 그래서 입력 커서가 활성화되지 않는 것입니다.

해결 방법: "유리벽 통과시키기"

해결책은 아주 간단합니다. 우리가 상호작용할 필요가 없는 모든 '배경'이나 '정리용 틀' 역할을 하는 UI 요소들의 Raycast Target 옵션을 꺼주는 것입니다.

아래 UI 요소들을 Hierarchy에서 하나씩 선택하고, Inspector 창에서 Image 컴포넌트를 찾은 뒤, Raycast Target 체크박스의 체크를 해제해 주세요.

UsedTagsPanel: 이 Panel 자체는 클릭할 필요가 없습니다. 자식으로 생길 '태그 버튼'만 클릭되면 됩니다. (Raycast Target 끄기)
SelectedTagsPanel: 이 Panel도 마찬가지입니다. (Raycast Target 끄기)
HistoricalRecordsScrollRect의 배경 Image: 스크롤 뷰의 배경 이미지 역시 클릭 이벤트가 필요 없습니다. (Raycast Target 끄기)
모든 제목 Text 오브젝트들: "지금까지의 기록 사항" 같은 제목 텍스트들도 클릭할 필요가 없습니다. TextMeshPro - Text (UI) 컴포넌트를 보면 여기에도 Raycast Target 옵션이 있습니다. (모두 끄기)

반대로, Raycast Target이 반드시 켜져 있어야 하는 것들:

모든 Button들 (SubmitButton, AddNewTagButton 등)
모든 InputField들 (ImpulseInputField, SolutionInputField 등)
HistoricalRecordsScrollRect의 Scrollbar (스크롤바를 직접 클릭하고 드래그해야 하므로)

이 설정을 마치면, 이제 투명한 Panel들이 더 이상 클릭 이벤트를 가로채지 않고 마우스 신호를 그대로 통과시켜서, 뒤에 있는 InputField가 정상적으로 클릭되고 입력 커서가 활성화될 것입니다.

왜 위치 조정이 안될까요? - "자동 정렬의 대가"

Horizontal Layout Group(이하 '레이아웃 그룹')은 마치 엄격한 조교와 같습니다. 이 조교의 유일한 임무는 자신의 자식들을 무조건 정해진 규칙(왼쪽부터 차례대로, 정해진 간격으로)에 따라 줄 세우는 것입니다.

우리가 한 일: UsedTagsPanel에 레이아웃 그룹이라는 '조교'를 배치했습니다.
조교의 행동: 조교는 Panel 안에 있는 모든 자식들(나중에 추가될 태그 버튼들과 지금 넣은 제목 Text)을 발견하고, "전부 이리 와! 내가 왼쪽부터 순서대로 세울 테니 꼼짝 마!" 라고 명령합니다.
결과: 우리가 Scene 뷰에서 제목 Text의 위치를 마우스로 아무리 옮기려고 해도, 조교(Layout Group)가 다음 프레임에 즉시 "어허! 제자리로 돌아가!" 라고 외치며 원래 위치로 되돌려 버립니다. Rect Transform의 위치 값이 회색으로 비활성화되는 것도 바로 이 때문입니다. **"네 위치는 이제부터 내가 관리한다"**는 뜻입니다.

해결책: 구조 분리 (조교의 관리 영역을 명확히 하기)

이 문제를 해결하는 가장 깔끔하고 올바른 방법은, **'자동 정렬이 필요한 요소'**와 **'자유로운 배치가 필요한 요소'**를 서로 다른 부모 아래에 두어 구조적으로 분리하는 것입니다.

올바른 Hierarchy 구조

**제목(Text)**은 자동 정렬이 필요 없습니다.
태그 버튼들은 자동 정렬이 필요합니다.

이 두 가지를 분리하기 위해 아래와 같이 구조를 만듭니다.

잘못된 구조 (현재 상태):

Code

UsedTagsPanel (with Horizontal Layout Group)
 ├── "이전에 사용한 태그" (제목 Text)  <-- 조교의 통제를 받음
 └── TagButton1 (나중에 추가될 버튼)  <-- 조교의 통제를 받음

올바른 구조 (추천):

Code

UsedTagsSection (빈 오브젝트 또는 Panel)  <-- 전체 구역을 묶어주는 역할
 ├── "이전에 사용한 태그" (제목 Text)    <-- 자유롭게 위치 조정 가능!
 └── UsedTagsScrollView (Scroll View)   <-- 스크롤 기능
      └── Viewport
           └── UsedTagsPanel (Content, with Horizontal Layout Group)
                └── TagButton1 (나중에 추가될 버튼) <-- 조교의 통제를 받음

단계별 수정 가이드

그룹용 부모 생성: Hierarchy 창에서 Canvas 아래에 Create Empty로 빈 게임 오브젝트를 만듭니다. 이름을 UsedTagsSection 같이 알아보기 쉽게 짓습니다. 이 오브젝트는 단순히 제목과 스크롤 뷰를 함께 묶어 이동시키기 위한 그룹 역할을 합니다.
제목을 밖으로 빼기: 현재 UsedTagsPanel의 자식으로 있는 제목 Text 오브젝트를 드래그해서 방금 만든 UsedTagsSection의 자식으로 옮깁니다. UsedTagsScrollView와 같은 레벨에 있도록 합니다.
위치 조정: 이제 제목 Text는 더 이상 '조교'(Layout Group)의 통제를 받지 않으므로, Scene 뷰에서 원하는 위치로 자유롭게 이동시킬 수 있습니다. UsedTagsScrollView의 바로 위쪽에 보기 좋게 배치하세요.
SelectedTagsPanel도 동일하게 적용: "선택된 태그" 영역도 마찬가지로, 제목 Text와 스크롤 뷰를 별도의 부모 아래에 두어 구조적으로 분리하면 됩니다.

이 방법을 사용하면, 자동 정렬의 편리함과 자유로운 UI 배치의 유연성을 모두 가질 수 있습니다.

일반적인 객체 풀링 (Object Pooling) = "대기실에 모여있는 단역 배우들"

이것은 사용자님이 이미 알고 계신, 총알이나 몬스터에 사용하는 그 방식입니다.

원리:
1. 연극 시작 전에 단역 배우(오브젝트) 20명을 미리 고용해서 대기실(Pool)에 앉혀 둡니다. (비활성화 상태)
2. "지나가는 행인 1" 역할이 필요하면, 대기실에서 배우 한 명을 무대로 보냅니다. (SetActive(true))
3. 역할이 끝나면 (총알이 벽에 맞으면), 배우를 해고하는 대신 다시 대기실로 돌려보냅니다. (SetActive(false))
4. 다음에 또 "지나가는 행인 2" 역할이 필요하면, 대기실에 있는 배우를 다시 무대로 보냅니다.
핵심: 생성/파괴 비용을 줄이는 것. 배우를 계속 새로 고용하고 해고하는 대신, 기존 배우를 계속 돌려쓰는 것입니다.

리사이클링 스크롤 뷰 = "무대 양쪽 끝을 뛰어다니며 옷을 갈아입는 주연급 배우들"

이것은 스크롤 뷰에 특화된 매우 정교한 방식입니다.

원리:
1. 연극 무대(화면)에 딱 15명의 배우(UI 아이템)만 세웁니다. 대기실은 거의 비어있습니다.
2. 관객(사용자)이 스크롤을 아래로 내리면, 무대 맨 위쪽 배우(화면 밖으로 나간 아이템)가 보이지 않게 됩니다.
3. 이때 배우를 대기실로 보내는 게 아니라, 무대 뒤편으로 엄청나게 빨리 뛰어가게 합니다.
4. 그 배우는 무대 맨 아래쪽(이제 곧 화면에 보이게 될 위치)으로 순간이동합니다.
5. 순간이동하는 찰나의 순간, "행인 1" 옷을 벗고 "우체부" 옷으로 갈아입습니다. (데이터만 바꿔치기)
6. 관객이 보기엔 마치 새로운 우체부 배우가 등장한 것처럼 보입니다. 사실은 방금 사라졌던 그 행인 배우입니다.

그래서 무엇이 더 복잡한가요?

사용자님 말씀처럼 일반 객체 풀링은 그리 어렵지 않습니다. 하지만 '리사이클링 스크롤 뷰'가 훨씬 더 복잡한 이유는 바로 이 "뛰어가서 순간이동하고 옷 갈아입는" 과정 때문입니다.

정확한 위치 계산:
- 화면 위로 사라진 아이템을 화면 아래의 정확히 어느 좌표로 순간이동시켜야 하는지 계산해야 합니다. 이는 현재 스크롤 위치, 각 아이템의 높이, 아이템 간의 간격 등을 모두 고려해야 하는 복잡한 수학입니다.
데이터 매핑(옷 갈아입기):
- 순간이동한 UI 아이템은 겉모습일 뿐입니다. 우리는 전체 데이터 리스트(예: 1000개의 충동 기록)에서 정확히 몇 번째 데이터를 이 아이템에 표시해야 하는지 알아내야 합니다. (예: "화면에 보이는 5번째 아이템아, 너는 이제부터 전체 데이터의 543번째 기록을 보여줘야 해!") 이 데이터 연결(Data Binding) 로직이 필요합니다.
가변 높이 처리:
- 만약 어떤 기록은 한 줄이고, 어떤 기록은 스무 줄이라면 아이템들의 높이가 제각각 달라집니다. 이렇게 되면 1번의 '정확한 위치 계산' 난이도가 기하급수적으로 상승합니다.

결론

객체 풀링: "껐다 켰다" 하는 비교적 단순한 재활용 기술입니다.
리사이클링 스크롤 뷰: 오브젝트 풀링의 개념을 기반으로, **"실시간 위치 재계산 + 데이터 재연결"**이라는 매우 복잡한 로직이 추가된 고급 기술입니다.

사용자님께서 객체 풀링을 이미 알고 계신 것은 엄청난 장점입니다. 그 기본 원리를 이해하고 계시기 때문에, "리사이클링 스크롤 뷰는 왜 복잡한가?"라는 질문의 핵심(위치 계산, 데이터 매핑)을 파악하시면 훨씬 더 깊이 있게 이해하고 나중에 직접 구현하거나 관련 에셋을 잘 활용하실 수 있을 겁니다.

고민 1: "과거의 비슷한 충동을 어떻게 연결할 것인가?"

사용자님이 말씀하신 대로, 자유로운 텍스트 입력(string)만으로는 "비슷함"을 찾아내기가 거의 불가능합니다. "점심 먹고 나서"와 "밥 먹고 나니"는 컴퓨터에게 완전히 다른 글자이기 때문입니다.

이 문제를 해결하기 위한 가장 좋은 방법은, 사용자에게 자유를 주는 대신 '선택지'를 주는 것입니다.

해결책: 태그(Tag) 또는 카테고리(Category) 시스템 도입

데이터 구조 변경: ImpulseRecord에 List<string> tags를 추가합니다.

// DataManager.cs
[System.Serializable]
public class ImpulseRecord
{
    public DateTime recordDate;
    public string impulseDetail; // 자유로운 메모 (원래 있던 것)
    public List<string> tags;   // ★★★ 새로 추가! 이 충동의 종류를 나타내는 태그들 ★★★
    public string solutionDetail; // ★★★ 새로 추가! 이 충동에 대한 해결책 메모 ★★★
}

UI 변경: 충동 기록 씬에 '태그 선택' UI를 추가합니다.
- 사용자가 텍스트를 입력하는 곳 아래에, [#스트레스], [#식후], [#지루함], [#회의중] 같은 미리 정의된 태그 버튼들을 여러 개 만들어 둡니다.
- 사용자는 자신의 현재 충동에 해당하는 태그를 여러 개 선택할 수 있습니다.
- '+ 태그 추가' 버튼을 만들어 사용자가 자신만의 새로운 태그를 만들 수 있게 하면 더욱 좋습니다.
- "그럴 때 어떻게 해결했는지"를 기록할 '해결 방법' 입력창도 추가합니다.
핵심 기능 구현: "연관 기록 보여주기"
- 사용자가 특정 태그(예: #식후)를 포함하여 기록을 저장하면,
- 그 기록의 상세 페이지나, 또는 기록 목록 자체에서 **"같은 태그를 가진 과거 기록들"**을 자동으로 리스트업해서 보여줍니다.
- 코드로 구현: DataManager에서 모든 ImpulseRecord를 순회하면서, tags 리스트 안에 "#식후"라는 문자열이 Contains() 되어 있는지 확인하고, 있다면 그 기록들을 모아서 화면에 뿌려줍니다.

이점:

"비슷함"의 기준이 명확해집니다. 사용자가 직접 "이건 스트레스 상황이야"라고 정의했기 때문에, 컴퓨터는 같은 #스트레스 태그를 가진 기록들을 쉽게 찾아낼 수 있습니다.
검색이 필요 없어집니다. 기록을 보는 순간, 연관된 기록들이 자동으로 링크처럼 따라오기 때문에 훨씬 직관적입니다.
사용자는 "아, 지난번 스트레스 상황에서는 산책을 하니까 괜찮아졌었구나!" 라는 실질적인 해결책을 바로 얻을 수 있습니다.

고민 2: "검색 기능은 너무 복잡할 것 같다."

네, 맞습니다. 전통적인 검색창을 만드는 것은 UI도 복잡하고 구현 난이도도 높습니다. 위에서 제안한 '태그 기반의 자동 연관 기록 표시' 기능은 검색 기능을 훨씬 더 세련되고 사용자 친화적으로 대체할 수 있는 훌륭한 방법입니다.

만약 검색 기능을 추가한다면, **'태그 검색'**으로 한정하는 것이 좋습니다.

UI: 검색창에 #을 입력하면, 사용자가 지금까지 만들었던 태그 목록이 자동으로 뜨고, 그중 하나를 선택하여 검색하게 합니다.
구현: string.StartsWith() 나 Contains()를 impulseDetail 전체에 대해 실행하는 것보다, tags 리스트 안에서 정확히 일치하는 태그를 찾는 것이 훨씬 빠르고 정확합니다.

1. 왜 Save와 Load를 해야 하나요? (앱이 꺼지면 모든 게 사라지기 때문인가요?)

네, 정확히 그 이유 때문입니다.

DataManager의 변수들 (Dictionary, List 등) = "마법의 화이트보드"
- 이 화이트보드는 **RAM(메모리)**에 그려져 있습니다.
- 장점: 글씨를 쓰고 지우는 속도가 엄청나게 빠릅니다. 그래서 게임이 실행되는 동안 데이터를 읽고, 추가하고, 삭제하는 모든 작업은 이 화이트보드 위에서 이루어집니다. 아주 효율적이죠.
- 치명적인 단점: 전원이 꺼지면(앱이 종료되면) 모든 내용이 깨끗하게 지워집니다. 마치 마법처럼 모든 것이 사라져 버립니다.
PlayerPrefs (JSON 파일) = "돌로 만든 석판 노트"
- 이 노트는 휴대폰의 **내부 저장소(Storage)**에 저장됩니다.
- 장점: 한 번 새겨진 내용은 전원이 꺼져도(앱이 종료되어도) 절대 지워지지 않습니다. 영구적으로 보존됩니다.
- 단점: 석판에 글씨를 새기는 데는 시간이 좀 걸립니다. 화이트보드에 쓰는 것보다 훨씬 느리죠.

그래서 우리는 이런 작업을 하는 것입니다:

LoadData() (로드): 앱이 켜질 때, 석판 노트(PlayerPrefs)에 적힌 내용을 마법의 화이트보드(DataManager의 변수들)에 그대로 베껴 적습니다. 그래야 게임이 실행되는 동안 빠르게 데이터를 쓸 수 있습니다.
SaveData() (저장): 앱이 꺼지기 전에, 또는 중요한 변경이 있을 때, 마법의 화이트보드에 있는 최신 내용을 석판 노트(PlayerPrefs)에 꼼꼼하게 다시 새겨 넣습니다. 그래야 다음에 앱을 켰을 때 사라지지 않은 데이터를 다시 불러올 수 있습니다.

2. Save는 변경사항이 생길 때마다 하는 건가요?

네, 현재 우리가 짠 코드는 정확히 그 방식입니다. 그리고 지금 만들고 있는 앱에서는 이 방식이 가장 좋은 선택입니다.

이 방식의 장단점을 알려드릴게요.

방식 1: 변경이 있을 때마다 즉시 저장 (우리의 현재 방식)

AddHabit(), DeleteHabit(), AddImpulseDetailRecord() 등 데이터에 변화가 생기는 함수가 호출될 때마다 맨 마지막에 SaveData()를 호출합니다.
장점:
- 최고의 안정성: 사용자가 데이터를 추가하자마자 저장이 되므로, 그 직후에 갑자기 앱이 강제 종료되거나 휴대폰 배터리가 나가도 데이터가 손실될 걱정이 없습니다. 습관 기록 앱에서는 매우 중요한 장점입니다.
- 구현이 매우 간단하다: 데이터 변경 함수 끝에 SaveData() 한 줄만 넣어주면 되니 코드가 직관적이고 실수가 없습니다.
단점:
- 저장이 잦다: 만약 데이터가 엄청나게 크다면(예: 고화질 동영상 파일), 저장할 때마다 앱이 잠시 멈출 수 있습니다. 하지만 우리의 데이터는 아주 작은 텍스트 파일(JSON)이므로, 이 단점은 전혀 해당되지 않습니다.

방식 2: 앱이 종료될 때 한 번만 저장

OnApplicationQuit()이라는 유니티 특별 함수 안에서 SaveData()를 딱 한 번만 호출하는 방식입니다.
장점:
- 저장 횟수를 최소화하여 시스템 부담을 줄입니다 (데이터가 매우 클 때 의미 있음).
단점:
- 데이터 손실 위험이 크다: 사용자가 1시간 동안 앱을 사용하다가 앱이 갑자기 꺼지면, 그 1시간 동안의 모든 데이터가 전부 날아갑니다.

결론

사용자님께서 완벽하게 이해하신 것이 맞습니다.

저장하는 이유: RAM(화이트보드)은 앱이 꺼지면 초기화되므로, 영구적인 저장소(석판 노트)에 기록을 남기기 위해서입니다.
저장하는 시점: 현재 우리 코드는 데이터가 변경될 때마다 즉시 저장하고 있으며, 이는 우리의 앱에 가장 안전하고 적합한 방식입니다.

문제 상황: 왜 SceneLoader를 또 추가하면 안 되나?

1. 씬은 독립된 공간입니다: HabitList 씬을 떠나 RecordDetailsAboutImpulse 씬으로 이동하면, HabitList 씬에 있던 모든 오브젝트(첫 번째 스크린샷의 SceneController 포함)는 파괴되고 사라집니다.
2. 두 명의 선장 문제: 만약 두 씬에 각각 SceneLoader를 가진 오브젝트를 배치하면, 게임에는 잠시 SceneLoader가 두 개 존재하는 순간이 생길 수 있습니다. 이것은 마치 배에 선장이 두 명 있는 것과 같아서, 어떤 명령을 따라야 할지 혼란이 생기고 얘기치 않은 오류를 유발할 수 있습니다.

해결책: SceneLoader를 DataManager처럼 '총괄 매ని저'로 만들기

DataManager가 게임 전체의 데이터를 관리하는 유일한 총괄 매니저인 것처럼, SceneLoader도 게임 전체의 씬 이동을 책임지는 유일한 총괄 매니저로 만들어야 합니다.

이 방법의 장점은 다음과 같습니다.

SceneLoader가 딱 하나만 존재하게 됩니다.
어떤 스크립트에서든 public SceneLoader sceneLoader; 같은 변수를 만들고 드래그 앤 드롭할 필요가 전혀 없어집니다.
코드가 훨씬 깔끔해지고, 모든 씬에서 SceneLoader.Instance라는 공통된 주소로 씬 이동을 요청할 수 있습니다.

**JSON의 {}는 '식당 메뉴판'**이고,
**C#의 Dictionary는 '실제 식당 주방'**입니다.

이 둘의 다른 점을 하나씩 비교해 보겠습니다.

1. 본질 (Essence)

메뉴판 (JSON {}): 그냥 글자와 그림이 인쇄된 종이입니다.
주방 (C# Dictionary): 요리사, 재료, 조리도구가 모두 갖춰져 실제로 요리를 하는 공간입니다.

2. 기능 (What it can DO)

메뉴판 (JSON {}): 아무 기능도 없습니다.
- 손님이 메뉴판에 대고 "김치찌개에 돼지고기 좀 더 넣어주세요!" 라고 외쳐도, 메뉴판은 아무것도 할 수 없습니다. 그냥 종이일 뿐입니다.
- 할 수 있는 건 읽는 것(Reading) 뿐입니다. "아, 김치찌개가 8000원이구나" 라는 정보를 얻을 수 있습니다.
주방 (C# Dictionary): 수많은 기능을 가지고 있습니다.
- Add(): 주방에 "된장찌개"라는 새로운 메뉴를 추가할 수 있습니다.
- Remove(): 주방에서 "공기밥" 메뉴를 없앨 수 있습니다.
- ContainsKey(): 주방장에게 "혹시 김치 재료가 남아있나요?" 라고 물어볼 수 있습니다. (검색)

3. 존재 방식 (Where it exists)

메뉴판 (JSON {}): 식당 테이블 위, 또는 텍스트 파일 안에 글자 형태로 존재합니다.
주방 (C# Dictionary): 식당 건물 안에 실제로 존재하듯, 프로그램의 메모리 안에서 살아 움직이는 시스템으로 존재합니다.

결론: 그래서 둘의 진짜 다른 점은?

가장 큰 차이점은 '일을 할 수 있느냐, 없느냐' 입니다.

Dictionary는 데이터를 **'관리'**하고 **'처리'**하는 **일꾼(Worker)**입니다.
JSON의 {}는 그냥 그 일꾼이 관리하는 데이터의 **'목록'**을 적어놓은 **종이(List)**일 뿐입니다.

JsonUtility가 Dictionary를 모른다고 한 이유:

JsonUtility는 '사진사'입니다.

사진사는 '주방'이라는 복잡한 시스템 전체를 사진 한 장에 담을 수 없습니다. (요리사의 움직임, 불의 세기, 재료의 신선도 등등...)

하지만 사진사는 '메뉴판'은 아주 쉽게 사진으로 찍을 수 있습니다. 그냥 종이니까요.

그래서 우리가 하는 작업은, '주방'(Dictionary)을 보고, 그 내용을 '메뉴판'(List<Class>)에 그대로 베껴 적은 다음, 그 메뉴판을 사진사(JsonUtility)에게 건네주어 사진(JSON)을 찍게 하는 것과 같습니다.

이제 차이점이 명확하게 느껴지시나요? 형태는 비슷해 보이지만, 하나는 **살아있는 시스템(주방)**이고, 다른 하나는 **단순한 정보가 적힌 종이(메뉴판)**입니다

1. Multi Line Newline (여러 줄, 줄바꿈)

이것이 우리가 흔히 생각하는 일반적인 '여러 줄 텍스트 편집기'의 동작 방식입니다. (메모장이나 워드 프로세서처럼요.)

Enter 키를 누르면: **줄바꿈(Newline)**이 됩니다. 커서가 다음 줄로 내려가서 계속 텍스트를 입력할 수 있습니다.
입력 완료(Submit)는 어떻게 하나요?: 사용자가 입력창 외부의 다른 곳을 클릭하거나(OnEndEdit 이벤트 발생), 별도로 만들어 둔 '전송', '저장', '확인' 같은 버튼을 눌러야만 입력이 완료되었다고 프로그램이 인지합니다.
주요 사용처:
- 사용자가 자유롭게 여러 문단을 작성해야 하는 게시판 글쓰기 창
- 게임 내 노트나 메모 기능
- 상세한 피드백을 받는 입력창

➡️ 요약: Enter = 줄바꿈

2. Multi Line Submit (여러 줄, 제출)

이 방식은 채팅 프로그램에서 흔히 볼 수 있는 동작 방식입니다. 여러 줄 입력이 가능은 하지만, Enter 키는 '전송'의 의미를 가집니다.

Enter 키를 누르면: 입력이 **제출(Submit)**됩니다. 즉, 입력이 완료된 것으로 간주하고 OnEndEdit 또는 OnSubmit 이벤트를 발생시킵니다. (Single Line 모드에서 Enter를 누른 것과 동일)
줄바꿈은 어떻게 하나요?: 줄바꿈을 하기 위해서는 Shift + Enter 또는 Ctrl + Enter 키를 조합해서 눌러야 합니다.
주요 사용처:
- 게임 내 채팅창: 대부분의 메시지는 한 줄로 끝나므로 Enter로 바로 전송하는 것이 편하지만, 가끔 긴 메시지를 보낼 때 Shift + Enter로 줄바꿈을 할 수 있도록 지원합니다. (예: Discord, Slack 등)
- 빠른 검색창이나 명령어 입력창이지만 가끔 여러 줄 입력이 필요할 때

➡️ 요약: Enter = 제출 / Shift + Enter = 줄바꿈

유니티 UI의 Rect Transform에서 'Stretch'는 UI 요소의 크기를 부모(Parent) 요소의 크기에 비례하여 조절되도록 만드는 기능입니다. 이 기능의 핵심은 **앵커(Anchors)**에 있습니다.

앵커(Anchors)의 기본 원리

Rect Transform에는 4개의 앵커(삼각형 모양 아이콘 4개)가 있습니다. 이 앵커들은 자식 UI 요소가 부모의 어느 지점을 기준으로 자신의 위치와 크기를 잡을지 결정하는 기준점입니다.

앵커는 두 가지 상태로 존재합니다.

앵커가 한 점에 모여 있을 때 (Positioning 모드)
- UI 요소는 앵커가 위치한 지점으로부터 **고정된 거리(PosX, PosY)에 고정된 크기(Width, Height)**를 가집니다.
- 부모의 크기가 변해도 자식의 크기는 변하지 않습니다. 단지 앵커를 기준으로 한 상대적인 위치만 유지됩니다.
- (예: 앵커가 왼쪽 상단에 모여 있으면, 부모가 커지든 작아지든 항상 왼쪽 상단으로부터 정해진 거리만큼 떨어져 있습니다.)
앵커가 서로 떨어져 있을 때 (Stretching 모드)
- 이것이 바로 'Stretch' 상태입니다. 앵커들이 부모의 사방으로 흩어집니다.
- UI 요소의 각 경계선은 가장 가까운 앵커로부터 **고정된 간격(Margin)**을 유지하려고 합니다.
- Inspector를 보면 Width, Height 대신 Left, Right, Top, Bottom 값이 표시됩니다. 이 값들이 바로 앵커로부터의 간격입니다.
- 부모의 크기가 변하면, 앵커의 위치도 부모 크기에 맞춰 비례하게 이동하고, 자식은 앵커와의 간격을 유지하기 위해 함께 늘어나거나 줄어듭니다.

질문하신 상황에 대한 답변

1. 가로세로 모두 Stretch 할 경우

이때 stretch하면 부모를 꽉채우게 되는건가

네, 맞습니다.

앵커 상태: 4개의 앵커가 각각 부모의 왼쪽-위, 오른쪽-위, 왼쪽-아래, 오른쪽-아래 모서리로 이동합니다.
동작 방식:
- 자식의 왼쪽 경계선은 부모의 왼쪽 경계선으로부터 Left 값만큼 떨어집니다.
- 자식의 오른쪽 경계선은 부모의 오른쪽 경계선으로부터 Right 값만큼 떨어집니다.
- Top과 Bottom도 마찬가지입니다.
결과: Alt + Shift를 눌러 이 옵션을 선택하면 Left, Right, Top, Bottom 값이 모두 0으로 설정되면서, 자식이 부모의 모든 경계선에 딱 달라붙어 부모를 완전히 꽉 채우게 됩니다.

2. 가로나 세로 중 하나만 Stretch 할 경우

아, 하나만 stretch하면 가로나 세로만 부모만큼 채우게되는거고?

네, 이 역시 정확합니다.

가로만 Stretch 할 경우:
- 앵커 상태: 좌우 앵커는 부모의 좌우 양 끝으로 벌어지고, 상하 앵커는 중앙의 한 점에 모여 있습니다.
- 동작 방식:
  - 가로: Width 대신 Left, Right 값이 활성화됩니다. 부모의 너비가 변하면 자식의 너비도 함께 변합니다.
  - 세로: Top, Bottom 대신 PosY, Height 값이 활성화됩니다. 부모의 높이가 변해도 자식의 높이(Height)는 고정된 값을 유지합니다.
- 결과: 자식 UI의 너비는 부모를 따라가지만, 높이는 고정됩니다.
세로만 Stretch 할 경우:
- 위와 반대로, 상하 앵커는 부모의 위아래 양 끝으로 벌어지고, 좌우 앵커는 중앙의 한 점에 모입니다.
- 결과: 자식 UI의 높이는 부모를 따라가지만, 너비는 고정됩니다.

핵심 요약

앵커 프리셋에서 Stretch 옵션을 선택하는 것은 "내 크기를 부모의 크기에 연동시키겠다"는 선언과 같습니다.

양방향 Stretch: 너비와 높이 모두 부모를 따라간다.
단방향 Stretch: 지정된 방향(가로 또는 세로)의 크기만 부모를 따라가고, 다른 방향의 크기는 고정된다.

이 원리를 이해하면 화면 해상도가 다른 다양한 기기에서도 UI가 깨지지 않고 유연하게 대응하는 반응형 UI를 만들 수 있습니다.

1. "이런 과정은 왜 필요한거지? 어차피 자식인데" & "우리가 임의적으로 바꿨기 때문인가"

네, 정확히 후자 때문입니다! 사용자가 직접 기본 구조를 바꿨기 때문에, Scroll Rect에게 "이제부터 스크롤할 대상은 이 새로운 녀석이야"라고 명시적으로 알려주는 과정이 반드시 필요합니다.

컴퓨터는 '알아서' 생각하지 못합니다: Scroll View를 처음 생성하면, 유니티는 Scroll Rect 컴포넌트의 Content 슬롯에 기본으로 생성된 Content 오브젝트를 자동으로 연결해 줍니다. 이 둘은 처음부터 짝지어져 있습니다.
우리가 한 일: 우리는 그 기본 Content 오브젝트를 삭제했습니다. 이제 Scroll Rect의 Content 슬롯은 비어 있거나, 이미 사라진 대상을 가리키고 있는 '유령 참조' 상태가 된 것입니다.
자식이라고 다 아는 것은 아닙니다: Hierarchy에서 자식-부모 관계는 주로 위치, 회전, 크기(Transform)에 대한 종속성과 구조적 정리를 위한 것입니다. Scroll Rect라는 스크립트(컴포넌트) 입장에서는 자신의 수많은 자식 오브젝트 중에 어떤 것이 진짜 '스크롤될 내용물'인지 알 방법이 없습니다. 그래서 개발자가 직접 '이게 바로 내용물이야'라고 지정해 주는 슬롯이 필요한 것입니다.

결론: 부모-자식 관계는 구조적인 관계일 뿐, 스크립트가 특정 자식을 기능적으로 참조하려면 반드시 해당 슬롯에 직접 연결(할당)해 주어야 합니다.

2. "Scroll Rect 컴포넌트의 Content 슬롯>뭐하는곳이지?내용물 넣는곳인가"

네, 말 그대로 스크롤될 내용물(Content)이 누구인지를 지정해주는 곳입니다. 이 슬롯은 Scroll Rect 컴포넌트의 두뇌와도 같은 역할을 합니다.

Scroll Rect는 Content 슬롯에 연결된 Rect Transform을 가지고 다음의 모든 계산을 수행합니다.

스크롤 필요 여부 판단: Content의 크기(높이 또는 너비)가 Viewport(보여지는 영역)의 크기보다 큰지 비교합니다. Content가 더 클 때만 스크롤이 활성화됩니다.
스크롤 위치 계산: 사용자가 마우스로 드래그하면, Scroll Rect는 그 입력에 맞춰 Content의 Rect Transform의 위치(anchoredPosition)를 Viewport 안에서 위아래 또는 좌우로 움직입니다.
스크롤바 업데이트: Content의 전체 크기와 현재 Viewport에 보이는 영역의 비율을 계산해서, Scrollbar의 핸들 크기와 위치를 실시간으로 조절합니다. (예: Content 내용이 2배 길어지면, 스크롤바 핸들의 크기는 절반으로 줄어듭니다.)

만약 이 슬롯이 비어있으면 Scroll Rect는 무엇을 스크롤해야 할지, 크기는 얼마인지, 어디로 움직여야 할지 전혀 알 수 없게 되어 아무 동작도 하지 못합니다.

3. 오류 메시지 분석: MissingReferenceException

보내주신 오류 메시지는 위 설명을 완벽하게 증명해 줍니다.

MissingReferenceException: The variable m_Content of ScrollRect doesn't exist anymore.

이 메시지를 한국어로 쉽게 풀어보면 다음과 같습니다.

"참조가 사라졌습니다 오류: ScrollRect 컴포넌트의 m_Content라는 변수(슬롯)가 가리키던 대상이 더 이상 존재하지 않습니다."

오류 발생 과정:

사용자가 스크롤바를 조작했거나 어떤 이벤트가 발생했습니다.
Scrollbar가 ScrollRect에게 "위치를 업데이트해!"라고 신호를 보냈습니다.
ScrollRect는 자신의 m_Content 변수에 저장된 대상을 움직이려고 했습니다.
하지만 그 대상은 우리가 이전에 삭제해버린 기본 Content 오브젝트였습니다.
대상이 없으니 ScrollRect는 무엇을 해야 할지 몰라 오류를 발생시킨 것입니다.

이 오류는 "Scroll Rect의 Content 슬롯에 유효한 대상을 다시 연결해 주세요"라는 유니티의 외침이라고 할 수 있습니다.

Unity Version Control(Plastic SCM)이나 Git 같은 버전 관리 시스템에서 '변경사항(Changeset)'이라는 '세이브 포인트'가 만들어지는 기준은 빌드나 Ctrl+S (저장)가 아니라, 사용자가 직접 "지금까지의 작업을 하나의 묶음으로 저장해줘!" 라고 명시적으로 명령을 내리는 순간입니다.

이 명령을 '체크인(Checkin)' 또는 **'커밋(Commit)'**이라고 부릅니다.

비유: 게임 세이브 포인트

이 과정을 게임 플레이에 비유하면 완벽하게 이해할 수 있습니다.

Ctrl+S (파일 저장): 이것은 게임에서 몬스터를 잡거나 아이템을 하나 먹는 사소한 행동과 같습니다. 게임은 이 모든 행동을 기억하고 있지만, 이것이 공식적인 '세이브 파일'이 되지는 않습니다. 만약 게임기가 갑자기 꺼지면 이 행동은 사라질 수 있습니다.
빌드 (Build): 이것은 게임의 '체험판' 또는 '데모 버전'을 만드는 것과 같습니다. 현재까지의 상태를 실행 가능한 파일로 만드는 것이지, 개발 과정의 역사를 기록하는 것과는 다른 목적의 작업입니다.
체크인 / 커밋 (Checkin / Commit):
이것이 바로 게임에서 여신상이나 세이브 포인트 크리스탈에 가서 "저장하시겠습니까?" 라는 물음에 "예"를 선택하는 행위입니다.
1. 사용자는 의미 있는 작업 단위가 끝났을 때(예: "UI 레이아웃 완성", "데이터 저장 기능 구현 완료") 이 명령을 내립니다.
2. 이때 **"UI 레이아-아웃 완성"**과 같은 **메모(커밋 메시지)**를 함께 남깁니다.
3. 버전 관리 시스템은 이 시점까지 변경된 모든 파일(스크립트, 씬, 프리팹 등)의 스냅샷을 찍어 하나의 공식적인 '세이브 파일'(Changeset)로 만들고, 남겨둔 메모와 함께 역사에 기록합니다.

실제 작업 흐름

DataManager.cs 스크립트를 열심히 수정합니다. (Ctrl+S를 여러 번 누릅니다.)
RecordDetailManager.cs 스크립트도 수정합니다. (Ctrl+S를 누릅니다.)
유니티 에디터로 돌아와서 RecordDetailsAboutImpulse 씬의 UI를 배치하고 저장합니다. (Ctrl+S를 누릅니다.)
기능이 어느 정도 완성되었다고 판단되면, Plastic SCM의 Pending Changes (보류 중인 변경사항) 탭을 엽니다.
여기에는 지금까지 내가 수정한 모든 파일 목록(DataManager.cs, RecordDetailManager.cs, RecordDetailsAboutImpulse.unity)이 표시됩니다.
"충동 기록 UI 및 데이터 저장 기능 추가" 라고 커밋 메시지를 작성합니다.
Checkin 버튼을 클릭합니다.
바로 이 순간! Changeset #5 (예시) 라는 이름의 새로운 '세이브 포인트'가 생성됩니다.

나중에 우리가 "오류 나기 전으로 돌아가자"고 할 때 선택하는 것이 바로 이 Changeset #5 입니다.

결론: '마지막 변경사항'이란, Ctrl+S나 빌드 시점이 아니라, 개발자인 당신이 "여기까지 작업은 중요하니 공식적인 역사로 남겨줘!" 라고 '체크인(Checkin)' 명령을 내렸던 마지막 시점을 의미합니다.

'개발 > 유니티' 카테고리의 다른 글

[프리다이빙 게임] #01 (1)	2025.09.06
[프리다이빙 어플] 출시 (onestore에 게시되면 글 수정) (1)	2025.09.06
25.09.03(유니티) (0)	2025.09.03
[습관어플] #6 (충동들때 클릭버튼 추가) (3)	2025.09.02
[Unity] 변수 값은 바뀌는데 왜 UI 텍스트는 그대로일까? (4)	2025.09.02

현재글[습과어플]#7 (커밋해둘걸..)

kimchangmin02 님의 블로그

kimchangmin02 님의 블로그 입니다.

게임 개발, 모딩 강좌, 주민 ai, Forge, 마인크래프트 모딩, Java, 마인크래프트, 개발일지, Ai, 포지 모딩, 1.18.2, 마인크래프트모딩, 자바, 커스텀 몹, 몹 만들기, 모드 개발, 몹 ai, 게임개발, 마인크래프트 모드, 포지,

Today :
Yesterday :

일	월	화	수	목	금	토
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28