A 서비스 라이브러리 문서 (live-code 지도)

목적(jegwon): A가 실제 호출하며 사용하는 살아있는 코드(live)를 진입점부터 추적해, 이 문서만 봐도 A 서비스를 파악할 수 있게 한다. 그래야 실사용 코드 / 죽은 코드 / 기술부채를 정확히 구분한다. (앞선 Explore-요약 기반 오류 — 'A온체인=Mina' 등 — 재발 방지.)

방법 (엄격 — 재발방지 규율)

1. 진입점부터 호출그래프 실추적: 데몬 main·라우트·페이지 진입점 → 실제 import/call 따라가 도달 가능=live / 미도달=dead 판정. 변수명·주석 대충 보기 금지.
2. file:line 직접 대조: Explore 에이전트 요약을 결론으로 쓰지 않는다. 실제 파일을 열어 확인. 불확실=‘미확인’ 표기 후 소스로 확정.
3. live 함수 카탈로그: 각 live 함수 = [역할 · 입력 · 출력 · 호출처(누가 부르나) · A→B 매핑].
4. 정량: 전체 LOC · live LOC · dead LOC 비율 · 리팩토링 방식 · 예상 감소율.

도메인별 문서 (오너·상태)

도메인	대상 모듈	오너	문서	상태
온체인	txSender · punkpollAvaxBlockChainApi · (FungibleToken=레거시Mina 제외판정)	reviewer	(작성중)	🔧
플랫폼 백엔드	punkpoll_api (Spring Boot)	backend1	(대기)	⏳
챗봇	kakaoChatBot(PHP) · telegramBot(Node)	backend1	(대기)	⏳
플랫폼 프론트	punkpoll_web (Next14)	dev·dev2	(대기)	⏳
인증/저장/운영	auth-gateway · ipfs · punkpollUtil	(배정)	(대기)	⏳

각 도메인 문서 템플릿


# A [도메인] 라이브러리
## 진입점 (호출그래프 루트)
- 데몬/라우트/페이지 목록 + 각 진입점이 트리거하는 흐름
## live 함수 카탈로그
| 함수/모듈 | file:line | 역할 | 입력 | 출력 | 호출처 | A→B 매핑 |
## dead code (미도달)
| 파일/함수 | file:line | 근거(어느 진입점서도 미도달) |
## 기술부채 (live지만 문제)
| 항목 | file:line | 문제 | B 개선 |
## 정량
- 전체 LOC / live LOC / dead LOC(%) / 리팩토링 방식 / 예상 감소율

프론트 도메인 live-code 완료(dev+dev2, 서버 b6dea9d): dev=헤더/explore/설문상세/빌더 · dev2=채널(8,414)/마이페이지(1,335·dead TokenCirculation 197)/지갑(9,427)/토큰(1,131·Token.jsx 498 모놀리식). B클린: Token.jsx 4분해·크로스임포트 해소·중복헬퍼·fetch훅 통일.

프론트 로컬=서버 동일(dev2 서버검증): ~/data/punkpoll_web HEAD=b6dea9d = 로컬 refactor-v2-analysis/punkpoll_web HEAD 동일(바이트 일치). 프론트 A정합·클릭맵(/doc/parity-map) 분석은 서버 authority와 일치=유효. (백엔드 로컬만 stale이었음.)

종합 지표 (도메인 문서 완료 시 채움 — manager 취합)

도메인	전체 LOC	live LOC	dead %	예상 B 감소율
온체인(txSender 26k·blockchainApi 59k·Ver2 39k·FungibleToken 42k·ipfs 1.3k)	168,050(서버 배포본 실집계)	미산출(도달성 트레이스 필요)	확정 dead: txConfirmer 525·sbtMinter 165·redisNonceManager 305 + 대량후보(Mina·TX확인 이원 98k·.bak·tests)	대폭(5모듈→B 2프로세스)
플랫폼 프론트(punkpoll_web·dev+dev2 완료·docs/features/lib-fe·lib-fe-dev2)	96,368 (574파일·서버 release b6dea9d)	90,789 (511)	5.8% (63파일)	즉시 6.7%(dead+고아)+admin 26% 분리+중복통합. (로컬 dev브랜치 +107커밋 과대계상 dev 정정)
플랫폼 백엔드(punkpoll_api)	집계중(backend1)
챗봇(kakao/telegram)	집계중(backend1)
A 전체	집계중			(도메인 완료 후 종합)

A현재 온체인 = Avalanche C-Chain(Fuji 43113/mainnet 43114), PUNK=Avalanche ERC20. Mina(o1js)=레거시·미사용. (정정 2026-07-07)

이 라이브러리 문서가 '정확한 A 이해'의 기준 → DB 마이그레이션·리팩토링·감소율 산정이 그 위에 얹힘.

온체인 도메인 live-code (reviewer 호출그래프 실추적 2026-07-07) ◐

txSender (~22k) — pm2 진입: txSender(main)·txMonitor·txConfirmer·txRecovery·sbtMinter·healthServer

live: contractService·signerService·callback·participationSigner·circuitBreaker·rpcManager·robustProvider·statsService·tokenRegistryService·receiptSbtService·복구서비스5·database·config·logger·pinataClient·encryptor·asyncMutex.
dead: redisNonceManager(305줄·import 0·nonce는 signerService 인라인)·미사용 export·scripts 일회성.

blockchainApi (~15-20k) — 진입: server.js(HTTP)+tx-confirmation-worker

live: server.js·contractService(4969)·multiFeePayerService(2363)·signerService·callbackImproved.js.
dead/legacy: callback.js(legacy·CLAUDE.md 명시·callbackImproved로 대체)·.bak 다수·txConfirmationWorker.v2 병존.

PunkpollFungibleTokenAvax — ⚠️ 이름과 달리 실역할 = Mina 토큰 아님

live: PunkpollLightApi.js(pm2 port 9400) = IPFS 업로드+설문 참여큐+콜백 관리 레이어.
dead/legacy: FungibleToken.ts·zkPunkManager.ts(Mina o1js 토큰)=레거시. PunkpollLightApi2 병존.

🎯 온체인 핵심 통폐합 발견 (reviewer)

콜백 로직 3중: txSender callback + blockchainApi callbackImproved + FungibleToken(LightApi) 콜백 → B 콜백 단일화.
IPFS 2중: FungibleToken(LightApi) + punkpoll-ipfs 양쪽 → B IPFS 단일화.
TX 제출 이원: txSender + blockchainApi → B chain-worker 단일화.
Mina 토큰 코드(FungibleToken.ts·zkPunkManager) = 전부 레거시 데드 → 제거.

플랫폼 백엔드/챗봇 DB (backend1 정본 DDL 대조 2026-07-07)

상세: punkpoll-v2-backend1/docs/20260707_224946_A_DB_스키마_전수파악_및_문제점.md

🔴 설문 데이터 이원화 = 통합 최대 난제: 같은 '설문'이 플랫폼(survey_basic_info/survey_questions·웹빌더)과 챗봇(sm_program_scenario_*·외부 SM 레거시)에 다른 스키마로 중복 존재. B 통합 시 스키마 정합 핵심.
스키마 부채: txSuccess 타입 불일치(varbinary(16) vs varchar(16))·네이밍 2세대 혼재(snake vs camel)·bclogs 3종 PK 부재·survey_ai_request 방치.
A 자체 진단: Participants 1.62초·N+1·voteCount(DB) vs 보기별합(Redis) 소스 이원화·콜백로그 무한증가.