The Point-Free Way 사용기

한 줄 요약

처음엔 유료 Skills가 납득되지 않았다.
그런데 직접 써보니, 코드 생산성보다 품질 기준을 빠르게 팀에 주입하는 속도에서 값어치를 체감했다.

---

처음엔 솔직히 반감이 있었다

Skills가 유료라는 점이 꽤 의아했다.

• AI로 소프트웨어 생산량이 폭발적으로 늘어나는 시기고
• Vercel처럼 스킬을 오픈소스로 공개하는 흐름도 이미 보이고
• 좋은 프롬프트는 공유될수록 생태계가 커진다고 생각했기 때문이다

그래서 초반 감정은 단순했다.
“이걸 굳이 돈 내고 사야 하나?”

---

그런데 왜 결국 pfw를 써봤나

계기는 간단했다.

• 나는 원래 TCA를 좋아하고
• Point-Free가 이런 영역을 얼마나 잘 구조화했는지 궁금했고
• 특히 실무에서 AGENTS와 Skills를 꽤 오래 다듬어 본 상태였기 때문이다

몇 달 동안 회사 프로덕트에 규칙을 붙여가며 시행착오를 겪었는데,
지금 돌아보면 “pfw를 먼저 알았으면 시간을 훨씬 줄였겠다”는 생각이 들었다.

---

isowords 기반으로 일하던 내가 느낀 낯익음

개인적으로 TCA의 best-practice 템플릿에 가까운 레퍼런스로
pointfreeco/isowords를 자주 참고해왔다.

그러다 보니 pfw가 제공하는 스킬셋이 낯설기보다,
이미 내가 회사에서 추구하던 구조와 놀랄 만큼 유사하게 느껴졌다.

• 도메인 분리 방식
• 테스트를 기준으로 동작을 검증하는 습관
• 구현보다 의도와 규칙을 먼저 고정하는 접근

결국 “새로운 철학”이라기보다
이미 하고 있던 방식을 더 빠르고 덜 흔들리게 만드는 패키지에 가까웠다.

---

회사에 바로 넣기 전에 개인 프로덕트로 검증했다

회사 프로덕트에 바로 강하게 적용하기엔 부담이 있어서,
먼저 개인 프로덕트에 작게 붙여봤다.

결과는 예상보다 훨씬 좋았다.

• “왜 이건 아직 스킬이 없지?” 싶었던 영역도 직접 커버할 수 있었고
• 그 과정에서 나만의 운영 기준이 더 선명해졌고
• 작성한 스킬 자체가 다시 재사용 가능한 자산으로 남았다

특히 좋았던 건, 단순 자동화가 아니라 판단 기준이 코드 밖으로 명시된다는 점이었다.

---

pfw + TDD 스킬 조합이 만든 차이

개인 프로젝트에서 pfw 스킬과 TDD 스킬을 함께 써보니 체감이 확 왔다.

• 구현 속도보다 품질 편차가 줄어들고
• 기능 추가 후 회귀 불안이 줄어들고
• “다음 수정에서 어디가 깨질지”를 예측하는 감이 훨씬 좋아졌다

이 조합은 결국 “더 많이 만든다”가 아니라
같은 시간을 써도 더 믿을 수 있는 결과를 만든다에 가까웠다.

---

유료로 써보니 관점이 달라졌다

막상 구매해서 써보니 만족도가 높았다.

• 이미 잘 정제된 시행착오를 바로 가져다 쓸 수 있고
• 내가 같은 수준의 규칙을 만들기 위해 들일 시간을 절약할 수 있고
• 무엇보다 결과물의 일관성이 높아진다

그래서 좋은 스킬셋이 또 나온다면 다시 구매할 의향이 있다.

---

TCA 2.0 전환 앞에서 드는 기대

이제 TCA 2.0 전환을 앞두고 있는데,
pfw에서 마이그레이션 스킬까지 제공해주면 정말 강력할 것 같다.

• 기존 아키텍처 의도를 보존하면서
• 변경 포인트를 단계적으로 정리하고
• 테스트 기반으로 안전하게 옮겨가는 흐름

이런 작업은 문서만으로는 늘 비싼데, 스킬로 제공되면 팀 전체의 전환 속도가 달라질 수 있다.

---

앞으로는 유료 Skills가 더 늘어날지도 모르겠다

예전에는 좋은 소스 코드를 읽고 얻는 인사이트가 가장 컸다.
요즘은 좋은 프롬프트/스킬을 보고 얻는 인사이트 비중이 점점 커지고 있다.

물론 여전히 “보는 눈”은 중요하다.
아무 프롬프트나 붙인다고 좋은 결과가 나오진 않는다.

그럼에도 방향은 분명해 보인다.

• 좋은 프롬프트가 좋은 프로덕트를 만들고
• 좋은 스킬은 팀의 품질 기준을 압축해서 전달하고
• 그 기준 자체가 이제는 경쟁력 있는 자산이 된다

코드가 자산이던 시대에서,
코드와 프롬프트를 함께 설계하는 시대로 넘어가는 중이라는 생각이 든다.