nested prefix 기능 개발

[minkikim89]

nested prefix 기능을 개발하도록 한다.

ARCUS는 현재 기본 delimiter로 콜론(:)을 사용하므로
parent_prefix:child_prefix:subkey
위와 같이 key가 들어올 때, parent_prefix의 child 는 child_prefix가 된다.

이 이슈에서는 아래와 같은 내용들을 처리하도록 한다.

• prefix 별 flush 기능 개발. parent prefix를 flush하면 child prefix들도 함께 flush.
• 전체 prefix의 개요 stats 조회
  • prefix 별 통계는 inclusive prefix stats를 사용하도록 개발. 즉, child prefix들의 통계를
    parent prefix 통계에 모두 포함하여 출력한다.
  • stats prefixes와 stats detail dump에서
    모두 최상위 prefix들에 대한 inclusive 통계만을 출력하도록 한다.
• 개별 prefix에 대한 상세 stats 조회 기능은 생략한다.
• default prefix max depth는 2로 한다.
  • 내부 동작은 prefix max depth가 큰 값이어도 정상 동작하도록 한다.
• null prefix 처리
  • null prefix는 다른 prefix들의 parent prefix가 아니게 수정

추후 아래와 같은 작업을 별개 이슈로 진행한다.

• prefix 단위로 exptime 설정
• prefix에 속한 item 통계 조회
  • exclusive items 조회 기능 추가(stats prefixes, stats detail dump)

[matteblack9]

제가 맡도록 하겠습니다

[matteblack9]

stats detail dump로 prefix들의 연산 통계 정보를 구했을 때에,
"item들의 개수 = collections들의 개수 합 + kv아이템 개수 합"으로 나타내는데, child prefix도 아이템 개수들의 합으로 나타내는 것이 맞을까요?

예를 들어,
prefix를 pfx, prefix size를 psz로 나타낸다고 가정했을 때에

PREFIX a itm 7 pfx 2 kitm 5 litm 0 sitm 0 mitm 0 bitm 0 tsz 504 psz 128 ktsz 376 ltsz 0 stsz 0 mtsz 0 btsz 0 time 20121105152422

이렇게 나타내는 것이 맞는건지

아니면, 아이템과 prefix는 별개로

PREFIX a pfx 2 itm 5 kitm 5 litm 0 sitm 0 mitm 0 bitm 0 psz 128 tsz 376 ktsz 376 ltsz 0 stsz 0 mtsz 0 btsz 0 time 20121105152422

이렇게 나타내는 것이 맞는건지 모르겠습니다.
.
child prefix를 하나의 item으로 봐야할지, 아니면 별개의 데이터로 봐야할지 말씀해주셨으면 합니다.

[matteblack9]

parent prefix를 flush 하는 경우, prefix_t내에 *parent_prefix 뿐 아니라, **child_prefix와 같은 것들을 추가해서 child prefix들도 모두 flush 하게 하는 것이 맞을까요?

[minkikim89]

@HarryKim93
질문하신 내용에 대해 토의하기 전에 현재 설계한 nested prefix 기능의 설계에 대해
검토를 진행해야할 것 같습니다. 이미 prefix.c에 구현되어 있는 코드를 기반으로 해서
개발을 진행하셨을 텐데요. 이에 대해서 점검하기 위해서 기 구현되어있던 부분과,
현재 개발하신 부분을 총합해서 어떤 식으로 설계/구현 하셨는지를 정리해서 공유해주시면 감사하겠습니다.

[jhpark816]

@HarryKim93 @minkikim89
몇 가지 질문 및 문의의 답변입니다.

• 2 단계 prefix로 제한하고 있나요 ?
• prefix는 item과는 다르게 봐야 합니다.
  • child prefix 개수 정보가 있으면 될 것 같습니다.
  • child prefix가 차지하는 공간의 크기 정보는 필요 없을 것 같습니다.
  • item 정보에서 child prefix에 속한 items들도 포함할 지를 판단해야 합니다.
  • stats prefixes 명령의 수행 결과에 최상위 prefix만을 결과로 할지를 판단해야 합니다.
• flush에서
  • 특정 child prefix를 지정하면, 해당 child prefix만 flush하면 됩니다.
  • 상위의 prefix를 지정하면, 그 prefix와 하위에 있는 모든 prefixes를 flush하면 됩니다.
• 위의 사항들을 정확히 판단하는 데 있어, 현재 구현하려는 nested prefix 개념을 공유해주면 좋을 것 같습니다.

[matteblack9]

develop branch에서 주석처리된 nested prefix 구현부로 test파일을 돌려보니 2단계이상의 nested prefix도 잘 작동합니다. 현재는 3단계로 제한하고 있습니다.

현재 구현하려는 nested prefix 개념은 mongoDB의 Embedded Documents(depth를 100으로 제한)와 거의 흡사하게 생각하고 있습니다. nested prefix를 통해서 root prefix와 prefix관계 뿐만아니라 prefix와 prefix 사이의 일대다 관계를 만듦으로서, prefix에 속해있는 데이터들 사이의 관계를 명확히 하게하고, 연산을 최소화하기 위함입니다.

예를 들어 A라는 prefix와 A의 세부정보를 포함하는 child prefix가 있을 때, flush와 같은 연산 한번으로 A와 관련된 세부정보들을 한번의 query만으로 다룰 수 있게 됩니다.

그래서 결론적으로는 query를 최소화하기 위해서 nested prefix 개념이 사용된다 생각하고 있습니다.

[jhpark816]

@minkikim89

Nested prefix는 예전 아래 문제로 보류해 두었던 기능입니다.

• 구체적인 활용 예 부족
• 기능 spec 명세화 부진

이번에 nested prefix 기능을 추가한다면, "기능 spec 명세화"가 필요합니다.
1개 prefix인 경우는 기능 명세가 직관적이지만,
nested prefix인 경우는 이를 어떻게 제공할 지를 결정해 두어야 합니다.
예를 들어, nested prefix인 경우 아래 기능들이 정의되어 공유되어야 하고,
그 정의에 맞게 PR이 구현된 것인지를 확인하는 것이 필요합니다.

1. prefix 단위로 item 제거 기능
   • 상위 prefix 제거하면, 하위 prefix도 함께 제거
2. prefix 단위로 stats 정보 제공
   • 전체 prefix 정보 조회
     • 이 경우는 최상위 prefix 목록만 제공
     • 각 최상위 prefix의 prefix name, inclusive item count/bytes, child prefix count 제공이 적합하다고 보임.
       참고로, 현재는 exclusive item count/bytes 제공하는 형태임.
     • 근거는 nested prefixes를 사용한다는 것은
       items들을 세분화하여 caching하겠다는 의미가 있으므로,
       최상위 prefix의 exclusive item count는 0일 가능성이 높음
   • 개별 prefix 정보 조회 (상세 정보)
     • exclusive item count/bytes
     • inclusive item count/bytes
     • child prefix list : prefix name, inclusive item count/bytes, child prefix count 제공
   • prefixes에 대한 operation stats은 어떤 형태로 제공할 지 ?
3. 향후 prefix 기능들
   • prefix 단위로 exptime 설정
     • 해당 prefix만 설정 vs. child prefixes에도 설정
   • prefix에 속한 item 조회
     • exclusive items 조회 vs inclusive items 조회 중의 결정 (또는 옵션 지정, default 동작 결정)
   • 그 외의 기능들 검토.

그리고, nested prefixes 기능이 응용의 어떤 경우에 활용하면 유용한 지도 정리하면 좋을 것입니다.
현재 당장 떠오르지 않습니다.

위의 기능 spec을 잘 구현하기 위하여, 구현 방식이 달라질 수도 있을 것 같습니다.
예를 들어, child prefixes들을 tree 구조처럼 관리하는 것이 나을 수도 있습니다.

따라서, 이번 PR을 어느 선의 spec까지 구현할 것인지가 관련자들 모두에게 잘 공유되어야
PR 받아서 처리는 데 문제가 없을 것입니다.

이번에는 어떤 spec으로 정리하는 것이 좋을까요 ?

[minkikim89]

• 상위 prefix를 제거하면 하위 prefix의 item들을
  제거되는 기능은 이미 구현된 상태입니다.
• 이 이슈에서는 현재 기구현되어있는 prefix 기능을 기반으로 개발을 하고
  , stats를 어떻게 표현할지까를 정하는 선에서 마무리를 짓는게 좋아보입니다.
• 향후 추가해야할 prefix 기능들은 이 이슈 PR이 끝난 후 새로운 이슈를 생성해서
  진행하면 될 것으로 보입니다.

stats의 경우 stats prefixes로 전체 prefix들을 조회할 경우는
inclusive item count를, 특정 prefix를 조회하는 경우는
exclusive item count를 사용하면 될 것 같다고 생각합니다.
즉, 아래와 같이 출력되는 것을 생각하고 있습니다.(pcnt=prefix count)

stats prefixes
PREFIX <null> pcnt 0 itm 1 kitm 1 litm 0 sitm 0 mitm 0 bitm 0 tsz 88 ktsz 88 ltsz 0 stsz 0 mtsz 0 btsz 0 time 20200909204708
PREFIX pfx1 pcnt 2 itm 10 kitm 10 litm 0 sitm 0 mitm 0 bitm 0 tsz 88 ktsz 88 ltsz 0 stsz 0 mtsz 0 btsz 0 time 20200909204708
END

stats prefixes pfx1
PREFIX pfx1 pcnt 2 itm 2 kitm 2 litm 0 sitm 0 mitm 0 bitm 0 tsz 88 ktsz 88 ltsz 0 stsz 0 mtsz 0 btsz 0 time 20200909204708
PREFIX pfx1:sub1 pcnt 0 itm 5 kitm 5 litm 0 sitm 0 mitm 0 bitm 0 tsz 88 ktsz 88 ltsz 0 stsz 0 mtsz 0 btsz 0 time 20200909204708
PREFIX pfx1:sub2 pcnt 0 itm 3 kitm 3 litm 0 sitm 0 mitm 0 bitm 0 tsz 88 ktsz 88 ltsz 0 stsz 0 mtsz 0 btsz 0 time 20200909204708
END

@HarryKim93
stats 출력에 대해서 다른 좋은 의견이 있으시면 말씀해주시면 감사하겠습니다.

[jhpark816]

@minkikim89 @HarryKim93

• child prefix count 정보는
  • time 정보 바로 앞에 두는 것이 나은 것 같습니다. (의견입니다.)
    • item stats 정보가 가장 관심 있는 정보이므로, item 정보 다음에 그리고 time 정보 앞에 두면 적합하다고 생각합니다.
  • 표현 방식은 "pfx %llu" or "chd %llu"가 나은 것 같습니다.
    • prefix count 의미가 나을 지, child count 의미가 나을 지 ? (후자가 더 명확할 듯 합니다)
    • item count는 "itm %llu"로 나타내고, item bytes는 "tsz %llu"로 나타냅니다.
• prefix operation stats 정보는 어떻게 달라지나요 ? (@minkikim89)
  • spec 구체화 명시 필요
• backward compatibility 이슈
  • inclusive item count/bytes vs. exclusive item count/bytes
  • 기존 single prefix 방식에서
    • "aaa:key1", "aaa:chidl1"key2", "aaa:child2:key3" 3개의 key로 data를 caching하면,
      aaa prefix의 item count는 3이 됩니다.
  • nested prefix에서
    • exclusive item count 방식이면, aaa prefix의 item count는 1이 됩니다.
    • inclusive item count 방식이면, aaa prefix의 item count는 3이 됩니다.
  • 따라서, backward compatibility를 위해 inclusive item count/bytes 방식이 필요합니다.
• inclusive item count/bytes 구현 방식
  • 2가지 구현 방식
    • parent prefix를 따라가면서 count/bytes 값을 증감할 수 있고,
    • parent prefix에서 child prefix list를 유지하고 child prefix 따라가면서 sum 값을 구할 수 있습니다.
  • 현재는 전자의 방식이 나을 것 같고,
  • prefix max depth를 2로 한정하면 좋겠습니다.
    • 단, 구현 자체는 N 값이 크더라도 동작하게 구현하였으면 하고,
    • prefix max depth를 크게 하는 것은 나중에 고려하는 걸로 하시죠.
• 개별 prefix stats 정보
  • 이번 PR에서는 제외하도록 하죠.
• root prefix 와 null prefix 개념.
  • 현재 root prefix와 null prefix 개념이 혼돈되어 있습니다.
    • null prefix가 root prefix 이며, null prefix가 다른 prefix들의 parent prefix 입니다.
    • 따라서, nested prefix 구현에서 null prefix의 inclusive item count/bytes 값을 증가시키고 있습니다.
  • 아래와 같이 구분하는 것이 좋겠습니다.
    • root prefix 개념은 현재로는 제거 (total prefix count, total item count 등의 정보는 다른 stats에 있기 때문)
    • null prefix는 단지 null prefix의 stats 정보만 가지도록 합시다.

[jhpark816]

@minkikim89 @HarryKim93
위 코멘트를 다시 수정하였으므로, 확인 바랍니다.

[minkikim89]

@jhpark816
prefix operation stats 정보란게 어떤걸 말씀하시는 건가요?
그리고, 참고로 inclusive item count/bytes 구현 방식은 말씀하신 방법 중 이미 전자로 구현되어있습니다.

[jhpark816]

@minkikim89
stats detail dump하면 나오는 내용을 말합니다.

PREFIX <null> get 2 hit 2 set 2 del 0
       lcs 0 lis 0 lih 0 lds 0 ldh 0 lgs 0 lgh 0
       scs 0 sis 0 sih 0 sds 0 sdh 0 sgs 0 sgh 0 ses 0 seh 0
       mcs 0 mis 0 mih 0 mus 0 muh 0 mds 0 mdh 0 mgs 0 mgh 0
       bcs 0 bis 0 bih 0 bus 0 buh 0 bds 0 bdh 0 bps 0 bph 0 bms 0 bmh 0 bgs 0 bgh 0 bns 0 bnh 0
       pfs 0 pfh 0 pgs 0 pgh 0
       gas 0 sas 0
PREFIX a get 5 hit 5 set 5 del 0 
       lcs 0 lis 0 lih 0 lds 0 ldh 0 lgs 0 lgh 0
       scs 0 sis 0 sih 0 sds 0 sdh 0 sgs 0 sgh 0 ses 0 seh 0
       mcs 0 mis 0 mih 0 mus 0 muh 0 mds 0 mdh 0 mgs 0 mgh 0
       bcs 0 bis 0 bih 0 bus 0 buh 0 bds 0 bdh 0 bps 0 bph 0 bms 0 bmh 0 bgs 0 bgh 0 bns 0 bnh 0
       pfs 0 pfh 0 pgs 0 pgh 0
       gas 0 sas 0
PREFIX b get 2 hit 2 set 2 del 0 
       lcs 0 lis 0 lih 0 lds 0 ldh 0 lgs 0 lgh 0
       scs 0 sis 0 sih 0 sds 0 sdh 0 sgs 0 sgh 0 ses 0 seh 0
       mcs 0 mis 0 mih 0 mus 0 muh 0 mds 0 mdh 0 mgs 0 mgh 0
       bcs 0 bis 0 bih 0 bus 0 buh 0 bds 0 bdh 0 bps 0 bph 0 bms 0 bmh 0 bgs 0 bgh 0 bns 0 bnh 0
       pfs 0 pfh 0 pgs 0 pgh 0
       gas 0 sas 0
END

아래 문서에서 "Prefix 통계 정보" 부분을 확인하세요
http://www.jam2in.com/arcus-docs/#/arcus-server/ARCUS-Server-Ascii-Protocol/1.11/ch11-command-administration

[minkikim89]

@jhpark816
stats detail dump 를 나타내는 게 쉽지 않네요..
지금 생각나는 것은 parent prefix에 대해서 맨 첫번째로는 inclusive 통계를 보여주고,
그 밑에 해당 prefix 의 exclusive 연산 통계, 그리고 밑에 차례대로 child를 보여주는 게 어떤가 싶습니다.
이때 exclusive 통계를 보여줄 때 어떻게 표현할지가 문제인데, 특수문자를 넣어서 표기하는 게 어떤가 싶습니다.
현재 '*' 문자가 prefix에서 사용될 수 없는 문자이기 때문에
아래에 이 문자를 통해서 exclusive 통계를 표현해보았습니다.
즉, prefix a 통계는 inclusive 통계, prefix a* 통계는 exclusive 통계입니다.
반대로 만약 backward compatibility를 고려하지 않는다면 inclusive 통계를 a:* 형태로 써도 괜찮을 것 같습니다.

PREFIX <null> get 2 hit 2 set 2 del 0
       lcs 0 lis 0 lih 0 lds 0 ldh 0 lgs 0 lgh 0
       scs 0 sis 0 sih 0 sds 0 sdh 0 sgs 0 sgh 0 ses 0 seh 0
       mcs 0 mis 0 mih 0 mus 0 muh 0 mds 0 mdh 0 mgs 0 mgh 0
       bcs 0 bis 0 bih 0 bus 0 buh 0 bds 0 bdh 0 bps 0 bph 0 bms 0 bmh 0 bgs 0 bgh 0 bns 0 bnh 0
       pfs 0 pfh 0 pgs 0 pgh 0
       gas 0 sas 0
PREFIX a get 30 hit 30 set 5 del 0 
       lcs 0 lis 0 lih 0 lds 0 ldh 0 lgs 0 lgh 0
       scs 0 sis 0 sih 0 sds 0 sdh 0 sgs 0 sgh 0 ses 0 seh 0
       mcs 0 mis 0 mih 0 mus 0 muh 0 mds 0 mdh 0 mgs 0 mgh 0
       bcs 0 bis 0 bih 0 bus 0 buh 0 bds 0 bdh 0 bps 0 bph 0 bms 0 bmh 0 bgs 0 bgh 0 bns 0 bnh 0
       pfs 0 pfh 0 pgs 0 pgh 0
       gas 0 sas 0
PREFIX a* get 5 hit 5 set 5 del 0 
       lcs 0 lis 0 lih 0 lds 0 ldh 0 lgs 0 lgh 0
       scs 0 sis 0 sih 0 sds 0 sdh 0 sgs 0 sgh 0 ses 0 seh 0
       mcs 0 mis 0 mih 0 mus 0 muh 0 mds 0 mdh 0 mgs 0 mgh 0
       bcs 0 bis 0 bih 0 bus 0 buh 0 bds 0 bdh 0 bps 0 bph 0 bms 0 bmh 0 bgs 0 bgh 0 bns 0 bnh 0
       pfs 0 pfh 0 pgs 0 pgh 0
       gas 0 sas 0
PREFIX a:subpfx1 get 10 hit 10 set 5 del 0 
       lcs 0 lis 0 lih 0 lds 0 ldh 0 lgs 0 lgh 0
       scs 0 sis 0 sih 0 sds 0 sdh 0 sgs 0 sgh 0 ses 0 seh 0
       mcs 0 mis 0 mih 0 mus 0 muh 0 mds 0 mdh 0 mgs 0 mgh 0
       bcs 0 bis 0 bih 0 bus 0 buh 0 bds 0 bdh 0 bps 0 bph 0 bms 0 bmh 0 bgs 0 bgh 0 bns 0 bnh 0
       pfs 0 pfh 0 pgs 0 pgh 0
       gas 0 sas 0
PREFIX a:subpfx2 get 15 hit 15 set 5 del 0 
       lcs 0 lis 0 lih 0 lds 0 ldh 0 lgs 0 lgh 0
       scs 0 sis 0 sih 0 sds 0 sdh 0 sgs 0 sgh 0 ses 0 seh 0
       mcs 0 mis 0 mih 0 mus 0 muh 0 mds 0 mdh 0 mgs 0 mgh 0
       bcs 0 bis 0 bih 0 bus 0 buh 0 bds 0 bdh 0 bps 0 bph 0 bms 0 bmh 0 bgs 0 bgh 0 bns 0 bnh 0
       pfs 0 pfh 0 pgs 0 pgh 0
       gas 0 sas 0
PREFIX b get 2 hit 2 set 2 del 0 
       lcs 0 lis 0 lih 0 lds 0 ldh 0 lgs 0 lgh 0
       scs 0 sis 0 sih 0 sds 0 sdh 0 sgs 0 sgh 0 ses 0 seh 0
       mcs 0 mis 0 mih 0 mus 0 muh 0 mds 0 mdh 0 mgs 0 mgh 0
       bcs 0 bis 0 bih 0 bus 0 buh 0 bds 0 bdh 0 bps 0 bph 0 bms 0 bmh 0 bgs 0 bgh 0 bns 0 bnh 0
       pfs 0 pfh 0 pgs 0 pgh 0
       gas 0 sas 0
END

[jhpark816]

@minkikim89

• 여기서도 일단 최상위 prefixes에 대한 inclusive stats 만 보여주면 backward compatibility가 만족됩니다.
  • child prefix와 exclusive stats을 보여주려면, 너무 많은 정보가 출력됩니다.
  • exclusive stats 이나 child prefixes의 stats 정보는 개별 prefix stats 정보로 정리하는 것이 나을 것입니다.
  • 즉, 개별 prefix에 대한 operation detail 정보를 보기 위한 별도의 명령으로 제공하는 것이 낫습니다.
• 최상위 prefixes에 대한 inclusive operation stats를 보여주는 것이 현재 구현에서 쉬운지 모르겠어요.
  • 구현 방식이 간단한 지를 검토해 주면 좋겠습니다.
  • 여기서도 마찬가지로 parent_prefix 포인터를 유지하고, 상위 prefix에 반영해야 하는 건지
    아니면, 상위 prefix에서 child_prefix 포인터를 유지하고, 요청 시에 summarize하여 보여 줘야 하는 건지 ?
    아니면, operation stats에 대해서는 기존대로 single level prefix 처럼 취급하여 처리할 지 ?

[minkikim89]

@jhpark816

• inclusive operation stat 를 구현하는 것은 어렵지는 않아보입니다. 현재 해당 부분 코드(stats.c)가
  prefix.c 코드와 대략 유사하기 때문입니다.
• inclusive operation stats 구현방식은 prefix.c 와 마찬가지로 parent_prefix 방식을 사용하면 될것 같습니다.
• single level prefix만 취급하는 것보다는, 위에서 말씀하신대로 기본적으로는 dump 명령 시 single level prefix만
  노출 시키고, 개별 prefix 조회 시 해당 prefix의 child prefix들을 조회할 수 있도록 하는 것이 좋아보입니다.

[jhpark816]

@minkikim89
stats prefixes 결과에서 child prefix count 정보도 뺄까요 ?
크게 의미가 없는 것 같고, 개별 prefix의 detail 정보를 요청할 때 제공해도 되지 않나 생각됩니다.

그리고, 기능 spec에 관련하여 이번 PR에 구현되어야 할 내용을
본 이슈의 첫번째 comment에 잘 정리해 두면, 관련자 분들이 보고 common sense를 가질 수 있을 것 같습니다.

[minkikim89]

@jhpark816
child prefix count는 개인적으로는 필요하다고 생각합니다.
stats prefixes를 했을 때 이제부터 default로 inclusive 통계가 나올텐데
child prefix count에 대한 내용이 없을 시, 캐시아이템들이 실제로는
child prefix에 속한 아이템 일 수 있다는 사실이 혼동스러울 것 같습니다.

@jhpark816 @HarryKim93
이슈 내용에 이번 PR에 구현해야할 내용 정리해두었습니다.
prefix 별 통계(stats prefixes, stats detail dump)에서 exclusive stats를 출력하는 것은
다른 이슈에서 진행하고 이번 이슈에서는 단순히 최상위 prefix들에 대해서 inclusive stats만을
출력하도록 하면 될 것 같습니다.

[jhpark816]

@minkikim89 @HarryKim93
이슈 내용 부분을 보완하였으므로, 참고 바랍니다.

[jhpark816]

@HarryKim93
ARCUS에서 prefix는 캐시 아이템들의 논리적인 그룹으로 RDBMS에서 table에 해당하는 개념입니다.
현재 prefix 사용 목적은 아래 2가지 입니다.

• prefix 단위로 아이템 통계 (with stats prefixes)와 연산 통계 (with stats detail dump) 제공
• prefix 단위로 캐시 아이템 일괄 삭제 (with flush_prefix) 제공

Nested prefix에서 향후 작업은 2 작업으로 나누고 아래 순서로 진행하면 좋을 것 같습니다.

• child prefix 관리 구조 변경
  • parent prefix 아래에 skip list로 관리
  • 이슈 등록 완료: child prefixes 관리 구조 개선 - skip list 사용 #562
• 특정 child prefix에 대한 통계 정보 제공
  • 특정 child prefix에 대한 아이템 통계와 연산 통계를 모두 제공할 수 있어야 함.
  • 아이템 통계는 예전 아래 명령으로 제공하려고 하였습니다.
    • stats prefix {prefix_name}\r\n
  • 제공할 통계를 고려하여 명령과 응답 문자열을 정의하여야 합니다.
    • 이에 대해 제안 주시면 더욱 좋을 것 같습니다.
  • 이 작업에서 prefix max depth를 2로 증가시키면 될 것 같습니다.

검토해 보시고, 다른 의견이 있다면 코멘트 바랍니다.