업무 담당자가 화면에서 파이프라인을 그리고, IT는 그 위에 코드 한 조각만 얹는다 — 이상적인 그림이지만, 그 이상적인 그림이 어디까지 통하는지는 따로 확인해봐야 한다
이케아 가구와 목공소, 그 사이 어딘가
Foundry에서 데이터 파이프라인을 만드는 방법은 두 가지다. 클릭만으로 조립하는 Pipeline Builder, 그리고 Python·SQL을 직접 짜는 Code Repositories. 비유하자면 이케아 가구와 동네 목공소 정도의 차이다. 이케아는 정해진 부품과 설명서로 누구나 빠르게 조립할 수 있지만, 정해진 부품에 없는 모양은 만들 수가 없다. 반대로 목공소에 가면 원하는 대로 다 깎아주지만, 시간도 오래 걸리고 아무나 할 수 있는 일도 아니다.
팔란티어도 공식 문서에서 이 둘을 “상호 보완적이며, 모든 파이프라인 요구를 함께 해결하도록 만들어졌다”고 설명한다.[1] 맞는 말이다. 그런데 실무에서 진짜 궁금한 건 이거다. “이 파이프라인은 업무 담당자가 계속 직접 만지게 하고 싶다. 그런데 딱 한 부분이 반복 계산을 해야 하고, 외부 API도 불러야 하고, 데이터 모양이 매번 바뀐다 — 이럴 때 가구 전체를 목공소에 새로 맡겨야 하나, 아니면 그 부분만 따로 깎아서 끼워 넣을 수 있나?” 이 글은 이 질문에 대한 답을, 공식 문서와 팔란티어 개발자 커뮤니티 포럼의 실제 사례, 실사용자 리뷰로 정리한 것이다.
Pipeline Builder가 잘하는 것
Pipeline Builder는 “코드 없이 프로덕션급 데이터 파이프라인을 구축”하는 게 목표다.[2] 제일 큰 장점은 협업이다. 공식 문서 표현을 그대로 빌리면 “코드를 쓰는 사람과 쓰지 않는 사람이 하나의 파이프라인 위에서 함께 작업할 수 있다.”[2]
화면은 그래프와 폼으로 되어 있고, 조인 키나 컬럼 타입 같은 걸 알아서 제안해주면서 실시간으로 피드백을 준다. 뒤에서는 Spark와 Flink를 같이 써서 배치든 스트리밍이든 다 처리한다.[2] 컬럼 하나를 다루는 “표현식”과 테이블 전체를 다루는 “변환” 두 단계로 나뉘는데, 필터·조인·피벗·집계 같은 기본기부터 지리공간 조인, K-평균 클러스터링, 정규식 파싱까지 500개가 넘는 부품(함수)이 이미 만들어져 있다.[3] 이케아 카탈로그가 꽤 두껍다는 뜻이다.
그런데 만드는 사람 입장에서는 얘기가 다르다
가구를 쓰는 사람(업무 담당자)한테는 편한데, 조립을 담당하는 사람(개발자)한테는 꼭 그렇지만도 않다. 실사용자 리뷰 사이트 PeerSpot에서 한 프린시펄 컨설턴트는 이렇게 평했다. “로우코드 도구는 빠르게 만들 때는 좋은데, 많이 커스터마이징해야 하는 워크플로우는 결국 우회하거나 더 깊이 파고들어야 한다.”[4] 다른 리뷰어는 “드래그 앤 드롭 방식에 한번 갇히면, 나중에 다른 플랫폼으로 옮기기가 더 힘들어진다”고 지적했다.[4]
팔란티어 자체 개발자 커뮤니티에서도 비슷한 얘기가 나온다. 한 사용자는 이렇게 썼다.
“우리 조직은 (몇 가지 한계에도 불구하고) 코드 빌더보다 파이프라인 빌더를 선호합니다 — 예를 들면 리팩터링용 IDE 도구가 없다는 점, 코드를 복사해서 응용하기가 어렵다는 점, 코드로 하면 더 쉬운 변환도 있다는 점 같은 한계가 있는데도요.”[5]
정확히 이 지점이다. 업무 담당자와의 협업은 쉬워지는데, 정작 그 조립을 실제로 담당하는 개발자의 손은 오히려 더 묶인다.
목공소로 넘어가야 하는 4가지 순간
공식 문서와 커뮤니티 포럼 실사례를 모아 보면, 이케아 부품만으로는 안 되는 지점이 크게 네 가지로 좁혀진다.
| 못 하는 것 | 왜 안 되는가 | 실제 사례 |
|---|---|---|
| 반복·재귀 계산 | Foundry의 빌드 시스템 자체가 순환 구조(loop)를 아예 못 만들게 막아놓았다 — 순환 참조가 감지되면 브랜치 체크에서 바로 걸린다.[6] Pipeline Builder는 처음부터 끝까지 한 방향으로만 흐르는 구조(DAG) 위에서 동작한다 | 조건을 만족할 때까지 계속 다시 계산하는 재귀 알고리즘, 부품 구조를 타고 올라가며 경로를 추적하는 그래프 탐색(예: BOM 부품 추적) 같은 건 못 만든다 |
| 모양이 매번 바뀌는 데이터 | 모든 변환이 “미리 정해둔 컬럼 구조”를 따라야 하는 강타입 구조라, 실행할 때마다 컬럼 개수·이름·타입이 달라지는 파이프라인은 애초에 설계가 안 된다 | 팔란티어 담당자의 공식 답변: “Pipeline Builder는 모든 함수가 강타입이라 컬럼을 미리 정의해야 한다. 스키마를 미리 알아야 어떤 함수·조건을 쓸 수 있는지 자동으로 제한한다”[7] |
| 복잡하게 겹겹이 쌓인 데이터 | 기본적인 JSON·XML 파싱은 되지만, 배열 안에 배열이 여러 겹으로 들어가 있는 것처럼 구조가 불규칙하면 표현 자체가 안 될 때가 있다 | 실제 포럼 사례: 배열 안에 다시 배열을 중첩시켰더니, 결과가 배열이 아니라 그냥 문자열로 나와버렸다는 버그성 한계가 보고됨[8] |
| 외부 API·커스텀 연동 | 안전하게 짜인 부품(노드)만 쓸 수 있는 구조라서, 파이프라인 중간에 임의의 외부 API를 부르거나 커스텀 라이브러리를 붙이는 게 안 된다 | 포럼에 올라온 질문 “Foundry에서 지오코딩을 제일 잘 하는 방법이 뭔가요?”에 대한 답: “지금은 이걸 정식으로 지원하는 방법이 없다” — 결국 코드로 우회해야 했다[9] |
이 네 가지는 공식 문서 하나(“Considerations: Pipeline Builder and Code Repositories”)를 뜯어서 정리한 것과, 별도로 Gemini에게 독립적으로 웹 서베이를 시킨 결과가 거의 똑같이 수렴한 항목들이다. 벤더가 하는 말과, 벤더와 무관하게 따로 조사한 결과가 같은 결론에 도달했다는 뜻이라 더 믿을 만하다.
한 가지는 정확히 짚고 넘어가자. “루프를 못 만든다”는 게 Pipeline Builder만의 약점은 아니다. 코드로 짜는 Code Repositories 쪽도, 파이프라인 사이에 순환 참조가 생기면 빌드 체크에서 똑같이 막힌다.[6] Foundry의 데이터셋 빌드 자체가 전체적으로 한 방향으로만 흐르게 짜여 있기 때문이다. 다만 Python 코드 “안에서” while문이나 재귀 함수로 반복 작업을 하는 건 얼마든지 가능하다 — Pipeline Builder의 그래프에는 애초에 그런 절차적 반복을 표현할 문법 자체가 없다는 게 진짜 차이다.
팔란티어가 직접 정리한 비교표
팔란티어가 공식적으로 내놓은 기능 비교표를 옮기면 이렇다.[1]
| 항목 | Pipeline Builder | Code Repositories |
|---|---|---|
| 권장 용도 | 조직 전체가 함께 쓰는 프로덕션 파이프라인, 여러 팀이 얽힌 협업 | 파이프라인에 붙일 특화된 코드 로직 |
| 만드는 방식 | 그래프·폼 기반 화면 | 웹 기반 IDE |
| 쓰는 언어 | 코드 필요 없음 | Python, SQL, Java, Mesa |
| 재사용 | 파이프라인·부분을 복사해서 붙이기 | 유틸리티 함수·라이브러리 재사용, 파일 간 코드 복사 |
| 타입 안전성 | 강타입 — 오류가 만드는 순간 바로 보인다 | 코드 기반 — 오류가 빌드할 때 드러난다 |
| 파일시스템·API 접근 | 안 됨 | 됨 |
| 디버그 | 각 단계를 즉시 미리보기 | 디버거·REPL 지원 |
팔란티어가 공식적으로 권장하는 방식은 이렇다. “설계는 Pipeline Builder로 하고, 거기 없는 특화된 로직이 필요할 때만 그 부분을 Code Repositories로 만들어서 붙여라.”[1] 그리고 “특화된 로직이 필요한 경우”의 예로 드는 것도 정확히 위 표의 네 가지와 겹친다 — API 호출, 커스텀 라이브러리, 코드로만 표현되는 로직.[1]
여기서 중요한 건 둘이 완전히 호환된다는 점이다. Code Repositories에서 만든 데이터셋을 Pipeline Builder 파이프라인의 입력으로 바로 쓸 수 있고, 반대도 마찬가지다 — 코드로 만든 부품 하나를 파이프라인의 맨 앞이든, 중간이든, 맨 뒤든 원하는 자리에 끼워 넣을 수 있다는 뜻이다.[1] 스케줄이나 헬스체크도 어느 쪽으로 만들었든 Data Lineage에서 파이프라인 전체를 한 덩어리로 관리한다.[1] 이케아 가구에 목공소에서 맞춤 제작한 서랍 하나를 끼워 넣어도, 가구는 여전히 하나의 가구인 것과 같다.
실무에서는 이 순서로 판단하면 된다
- 일단 Pipeline Builder로 시작한다. 필터·조인·집계·타입 변환·정규식 정제 같은 표준 작업이라면 무조건 Pipeline Builder가 기본값이다. 협업 속도와 타입 안전성이라는 이점을 먼저 버릴 이유가 없다.
- 위 네 가지 중 하나에 걸릴 때만 코드로 내려간다. 반복 계산이 필요한가, 스키마가 매번 바뀌는가, 데이터가 복잡하게 중첩되어 있는가, 외부 API가 필요한가 — 이 중 하나도 아니라면 코드로 갈 이유가 없다.
- 전체를 코드로 바꾸지 말고, 그 부분만 떼어서 코드로 만든다. 파이프라인 전체를 갈아엎는 게 아니라, 문제가 되는 부분 하나만 Code Repositories로 만들어 기존 Pipeline Builder 파이프라인에 끼워 넣는 게 공식적으로 권장하는 방식이다.
- 그래프가 너무 커지면(대략 노드 100개 이상) 구조를 한 번 재검토한다. 이건 특정 사례 하나에서 나온 숫자는 아니지만, PeerSpot 리뷰에서 “많이 커스터마이징된 워크플로우는 결국 우회가 필요해진다”고 한 지적과 같은 맥락이다. Pipeline Builder 자체가 못 하는 게 아니라, 너무 복잡해지면 읽기도 디버깅도 힘들어지니 그때는 모듈을 나누거나 일부를 코드로 옮기는 게 낫다.
정리하면
Pipeline Builder와 Code Repositories는 경쟁 관계가 아니라 역할이 다른 관계다. 업무 담당자와 개발자가 같은 화면에서 같이 작업해야 한다면 Pipeline Builder가 기본이고, 그 안에서 개발자가 느끼는 불편(IDE 도구 부재, 코드 재사용 어려움)은 실제로 있는 트레이드오프다. 그렇다고 “루프가 안 되니까” 파이프라인 전체를 코드로 옮길 필요는 없다. 반복·동적 스키마·중첩 데이터·외부 API, 이 네 가지 중 하나에 걸리는 부분만 따로 코드로 떼어내는 게 공식적으로도 권장되고, 실무에서도 제일 마찰이 적다.
자주 묻는 질문
Q. Pipeline Builder에서 반복문 비슷한 걸 흉내 낼 방법은 없나요? “Aggregate over window”나 “Rollup” 같은 윈도우·집계 함수로 누적합이나 순위 매기기 같은 일부 반복 패턴은 대체할 수 있습니다.[3] 하지만 조건에 따라 계속 다시 계산해야 하는 진짜 재귀·루프는 그래프 문법 자체에 없으니, 이건 Code Repositories로 넘어가야 합니다.
Q. Code Repositories 부분을 중간에 하나 끼워 넣으면 스케줄·헬스체크 관리가 복잡해지지 않나요? 아니요. 공식 문서에 따르면 어떤 도구로 만들었든 Data Lineage에서 파이프라인 전체를 하나로 묶어서 스케줄·헬스체크를 관리할 수 있습니다.[1] 도구가 섞여 있다고 관리가 쪼개지는 건 아닙니다.
Q. 우리 데이터가 동적 스키마인지 어떻게 판단하나요? 소스 시스템에 따라 컬럼 구조가 달라지거나, 실행할 때 데이터 내용에 따라 출력 컬럼이 바뀌어야 한다면 동적 스키마입니다. 반대로 소스가 고정되어 있어서 컬럼 목록을 미리 정해둘 수 있다면 Pipeline Builder로 충분합니다.
Q. “노드 100개”라는 기준은 팔란티어 공식 가이드라인인가요? 아니요. 이건 이 글을 준비하며 Gemini 웹 서베이가 제시한 실무적 경험칙이지, 팔란티어 문서에 적힌 숫자는 아닙니다. 정확한 기준은 파이프라인 복잡도와 팀 숙련도에 따라 다르니 참고만 하시면 됩니다.
참고자료
[1] Palantir, Building pipelines • Considerations: Pipeline Builder and Code Repositories, Foundry 공식 문서.
[2] Palantir, Pipeline Builder • Overview, Foundry 공식 문서.
[3] Palantir, Pipeline Builder • Transforms • Overview, Foundry 공식 문서.
[4] PeerSpot, Palantir Foundry Reviews — 실사용자 리뷰(프린시펄 컨설턴트, 데이터 엔지니어 등).
[5] Palantir Developer Community, Creating link types between Pipeline Builder owned object types and object types not owned by Pipeline Builder, community.palantir.com — 실사용자 포럼 게시글.
[6] Palantir, Building pipelines • Best practices • Development best practices, Foundry 공식 문서 — 순환 의존성·루프 차단 관련.
[7] Palantir Developer Community, Dealing with dynamic schema’s in pipeline builder, community.palantir.com — 팔란티어 담당자 답변.
[8] Palantir Developer Community, Nested array problem, community.palantir.com — 실사용자 버그 리포트.
[9] Palantir Developer Community, What’s the best way to do geocoding in Foundry?, community.palantir.com — 실사용자 질문·답변.