이 글은 42서울에서 들었던 강의를 토대로 AI로 재구성한 글이에요! 시큐어코딩: 안전한 소프트웨어 개발을 위한 핵심 실천 요약 개인정보와 민감정보 보호는 필수 개인을 특정할 수 있는 정보로 민감정보(예: 건강, 금융, 신분 등)는 유출 시 심각한 피해와 법적 책임이 발생해요. 데이터는 반드시 암호화하고, 접근통제(사무실, API, DB 등)로 내부자와 외부자 모두의 무단 접근을 차단해야 해요. 디지털 포렌식과 사회적 포렌식의 중요성 디지털 포렌식: 디지털 증거물을 분석하여 수사에 활용하고, 디지털 증거물의 증거 능력을 향상시키기 위해 사용되는 특수한 과학 수사 기법을 총칭하는 용어 데이터 유출, 변조, 삭제 등 사건 발생 시 디지털 포렌식 기법으로 증거를 확보하고, 법적 분쟁이나 내부 감사를 지원해요. 직원이 DB를 내려받아 다크웹에 판매하는 등 내부자 위협도 실질적이므로, 접근로그 기록과 정기적 점검이 필요해요. 익명화와 데이터 비즈니스 개인정보를 익명 정보로 전환하면 법적 리스크는 줄어들지만, 데이터 활용도가 낮아질 수 있어요. 데이터의 가치를 높이면서도 법적 고민을 줄이려면, 최소한의 식별정보만 남기고, 암호화·익명화·가명화 등 다양한 기법을 병행해야 해요. AI 결정 대응권과 자동화된 보안 AI가 보안 위협을 자동 탐지·대응하는 시대. AI는 이상행동 탐지, 자동 패치, 실시간 위협 차단 등에서 뛰어난 효과를 보여요. 사용자는 AI가 내린 결정에 대해 설명을 요구할 권리(설명가능성, AI 결정 대응권)를 가져야 하므로, 로그와 근거 데이터의 투명한 관리 필요해요. 코딩과 암호화, 관제의 실천 민감정보와 세션 정보는 반드시 암호화해야 해요. 입력값 검증(화이트리스트, allowlist)으로 악의적 데이터 차단이 필요해요. 세션 쿠키는 단순 삭제가 아니라, 레디스나 DB 등 서버 측 세션도 만료 처리해야 하며, 세션 만료 기간은 법적 기준에 맞춰야 해요. 접근통제는 사무실, API, DB 등 모든 경로에 적용되어야 해요. OWASP 등 표준 준수: OWASP의 시큐어코딩 체크리스트(입력값 검증, 인증·권한관리, 세션관리, 암호화, 로깅 등)를 참고해 개발 프로세스에 반영 회귀 테스트와 보안 테스트 병행: 신규 기능 추가 시 기존 기능이 정상 동작하는지(회귀 테스트)와 함께, 보안 취약점이 새로 생기지 않았는지 점검 필요 화이트리스트 입력값 검증: 사용자가 입력하는 값의 허용 범위만 명확히 지정(화이트리스트)하고, 나머지는 모두 차단 비밀번호 등 민감정보는 입력 규칙을 너무 자세히 노출하지 않도록 주의 시큐어코딩은 개인정보·민감정보 보호, 내부자 위협 차단, AI·자동화 보안, 암호화·접근통제, 표준 준수, 테스트 체계화 등 전방위적 실천이 필요. 법적 리스크와 데이터 비즈니스의 균형, 그리고 AI 시대의 새로운 보안 요구까지 모두 고려해야 함. 실무와 최근 트렌드를 반영한 시큐어코딩에 대해서도 정리할게요. 취약점 관리와 자동화 도구 활용 정적/동적 분석 도구: 개발 단계에서 SAST(정적 분석), DAST(동적 분석) 등 자동화된 보안 진단 도구를 활용해 코드 내 취약점을 조기에 발견해야 해요 의존성 관리: 오픈소스 라이브러리·패키지의 취약점도 빈번하므로, SCA(Software Composition Analysis) 도구로 주기적 점검 필요해요 DevSecOps의 도입 개발-운영-보안의 통합: 보안을 개발과정에 자연스럽게 녹여내는 DevSecOps 문화가 확산되고 있어요. 코드 작성, 빌드, 배포, 운영 전 과정에 보안 자동화와 점검을 내재화해야 해요 로그 관리와 모니터링 감사 로그와 실시간 모니터링: 모든 중요 행위(로그인, 데이터 접근, 설정 변경 등)는 로그로 남기고, 실시간으로 모니터링해 이상 징후를 즉시 탐지해야 해요 로그의 보존과 위·변조 방지: 로그는 일정 기간 안전하게 보관하고, 위·변조를 막기 위해 암호화·무결성 검증 필요해요 취약점 대응과 보안 패치 신속한 패치 적용: 신규 취약점(CVE 등) 발견 시, 신속하게 패치 적용 및 배포 절차를 마련해야 해요 사용자 교육과 보안 인식 사회공학적 공격 대응: 기술적 보안만큼이나, 피싱·스피어피싱 등 사회공학적 공격에 대한 임직원 교육도 중요해요 보안 인식 제고: 개발자와 운영자가 보안의 중요성을 일상적으로 인식하도록 지속적 교육 필요해요 권한 최소화 원칙 최소 권한 부여: 모든 시스템과 데이터 접근은 최소 권한 원칙(Least Privilege)에 따라 설계해야 하며, 불필요한 권한은 즉시 회수해야 해요 API 보안 API Rate Limiting 및 인증: API는 인증, 권한검사, 요청 횟수 제한(Rate Limiting), 입력값 검증 등으로 보호해야 해요 API Gateway 활용: 중앙 집중식 API Gateway로 트래픽 제어와 위협 탐지가 가능해야 해요 클라우드 및 SaaS 환경 보안 클라우드 환경 특화 보안: 클라우드 서비스 사용 시, 접근통제·키 관리·네트워크 분리 등 추가적인 보안 조치 필요해요 보안 테스트의 다양화 침투 테스트(Penetration Test): 정기적으로 외부 전문가에 의한 침투 테스트를 시행해 실제 공격 시나리오에 대응이 필요해요 법적·규제 준수 국내외 개인정보보호법, GDPR 등 준수: 서비스 대상 국가의 법률(예: GDPR, 개인정보보호법 등)에 맞는 보안 정책과 데이터 처리 방침을 마련해야 해요 Watch the little things; a small leak will sink a great ship.— Benjamin Franklin

이 글은 예전에 들었던 강의 내용을 정리한 내용이에요. 개발을 어떻게 할 것인가: 깊이와 폭의 균형 개발자라면 누구나 더 나은 코드를 작성하고, 더 효율적으로 문제를 해결하며, 더 창의적인 기술을 탐구하고 싶어 해요. 하지만 어떻게 더 나은 개발자로 성장할 수 있을까요? 철학자 칸트는 이렇게 이야기했어요. "철학이 아닌 철학함을 배워야 한다" 그의 말을 빌려 "개발이 아닌 개발함"을 생각하고, 깊이와 폭을 키우는 것이 중요해요. 개발의 깊이 개발의 깊이는 기술의 구조와 원리를 이해하고, 내가 사용하는 기술이 어떻게 동작하는지 알아가는 과정이에요. 내 코드가 왜 돌아가는지 정확히 아는 것은 단순한 기능 구현을 넘어서는 중요한 단계예요. 왜 깊이를 키워야 하는가? 기능을 더 빠르게 구현할 수 있어요 버그가 적은 코드를 작성할 수 있어요 디버깅이 효율적으로 이루어져요 이렇게 함으로써 재미를 느껴요 깊이를 키우는 방법 왜 되는지/안 되는지 알아내기: 단순히 작동 여부를 확인하는 데 그치지 않고, 이유를 탐구하기 블랙박스를 줄이기: Spring, Django, React 등에서 사용하는 명령어와 함수가 어떻게 작동하는지 파고들어 보기 당연한 것에 의문을 품기: 익숙한 코드라도 의도를 추측하고 극단적인 상황을 상상해 보기 예를 들어, Spring에서 사용하는 어노테이션이나 React의 함수들이 내부적으로 어떻게 작동하는지 모른다면 그것은 나에게 블랙박스예요. 이를 이해해야 진정한 깊이를 키울 수 있어요. 개발의 폭 개발의 폭은 다양한 기술에 대한 관심과 내가 하는 업무와 관련된 다른 기술에 대한 이해를 의미해요. 국내외 개발 커뮤니티에서 트렌드를 파악하고, 새로운 기술에 도전해 보는 것도 폭을 넓히는 좋은 방법이에요. 왜 폭을 키워야 하는가? 새로운 기술을 빠르게 배울 수 있어요 좋은 설계에 대한 안목이 높아져요 내가 더 잘할 수 있는 일을 발견할지도 몰라요 이렇게도 재미를 느낄 수 있어요 폭을 넓히는 방법 다음 토이 프로젝트에는 GraphQL을 사용해 보기 웹과 상관없는 프로그램 만들어 보기 (예: 메일 클라이언트) Django로 만든 블로그를 Spring MVC로 다시 만들어 보기 React-hook-form으로 구현한 form을 Recoil로 재구현하기 추천 활동 및 도서 폭을 넓히기 위해 아래와 같은 책들을 읽어보는 것도 좋아요: 프레드 브룩스, 맨먼스 미신 쳇 하스, 안드로이드 뜻밖의 역사 펠리너 헤르만스, 프로그래머의 뇌 앨런 튜링, 지능에 관하여 박정일, 튜링 &x26; 괴델: 추상적 사유의 위대한 힘 사람과 기술에 대한 존중 기술 뒤에는 사람도 있다는 사실을 꼭 기억하세요. 모든 기술적 선택은 양자택일이며, 어떤 기술이 엉망처럼 보일지라도 대신 얻는 무언가가 있을 가능성이 있어요. 비난하기 전에 더 나은 방법을 고민하고, 다양성을 존중해야 해요. I Love My Job 개발자는 단순히 코드를 작성하는 사람이 아니에요. 철학적 사고와 실용적 접근법을 통해 깊이와 폭을 균형 있게 키워 나갈 때 진정한 즐거움을 느낄 수 있어요. 여러분도 자신만의 방식으로 개발함을 실천해 보세요! Anybody can make history. Only a great man can write it.— Oscar Wilde

팔란티어가 25년도 2~3월에 말도 안 되게 비싸졌어요. 그런데 왜 이렇게 인기가 많아졌을까요? 알려지지 않는 SW를 만드는 회사인데도 뭐가 효과적이길래 이럴까요? 이 회사가 만든 제품을 사용하는 데 드는 금액은 얼마일까요? 저는 기업에 대해 잘 모르고 있어요. 만약 팔란티어가 자신들이 원하는 방향으로 모든 산업을 디지털 전환을 시키면 어떻게 될까요? 그렇게 되면 제 생각엔 모든 걸 가상(시뮬레이션)으로 돌려볼 수 있으니 가상 지구도 만들고 모든 걸 통제하에 둘 수 있을 것 같아요. 팔란티어든 스노우플레이크든 이들이 만들고자 하는 제품은 빅데이터 기반 의사 결정 도구로 볼 수 있어요. 그런데 저는 이 의사 결정 또한 자동화하고 싶다는 생각도 들어요. 매일 직원들의 업무를 실시간으로 반영할 수 있게 직원들에게 업무 현황 요청을 자동으로 보내고, 얼마큼의 내용으로 뭘 어떻게 했는지 중간보고를 받아보는 거예요. 모든 게 다 Git 커밋처럼 남는다면 단순히 일을 위한 일로써 글자수 채우기인지 아닌지를 파악할 수 있을 거예요. 팔란티어의 경쟁사: 스노우플레이크, 데이터브릭스, C3.AI (각 전문 분야가 달라요) 외국에선 스노우플레이크를 더 쳐주는 것 같아요. 아래 내용은 팔란티어 학습 강좌를 보면서 정리한 내용이에요. 글 가장 밑에 링크들이 있으니 필요하시다면 직접 방문해서 더 좋은 내용을 살펴보시길 바랄게요! 파운드리 파운드리는 소프트웨어의 이름: 운영 의사 결정 플랫폼 다양한 산업의 개발자가 아닌 모든 직업군이 데이터와 모델을 통해 영향력을 창출할 수 있도록 지원하는 도구예요. 국가적 위기 상황 같은 긴급한 요구 사항에 대응할 수 있도록 설계되었어요. 재무 데이터, 개인 식별 정보, 건강 정보, 미분류 정보, 기밀 정부 데이터 등 보안에 민감한 고객도 사용할 수 있도록 만들어졌어요. HIPA, GDPR, ITAR을 포함해 전반의 규제 요구 사항을 충족하고 있어요. 디지털 전환이 필요한 산업이 우선순위인 것 같고 팔란티어의 제품이 더 필요해 보여요. 이러한 산업이 인류에게 IT 기업보다 더욱더 필요하다고 이전에 피터 틸이 말한 적이 있는데 연관이 있을 거로 생각해요. 팔란티어의 SW가 사용자가 볼 수 있도록 유연하게 표현되어야 하고, 시간에 따라 변화하는 조건에 적응해야 조직이 사용할 수 있어요. 데이터 전문가만 사용할 수 있는 환경이어선 안되고 진정한 디지털 전환은 모든 팀과 사용자를 하나로 모아야만 가능하다고 해요. 빅데이터 활용을 위해 기업들은 데이터 파이프라인 구축과 데이터를 통한 분석에 어려움을 겪고 있어요. 보통 분석은 대시보드를 제공함으로써 역할을 다하죠. 그리고 더 큰 문제는 이러한 투자로 인한 비용이 실질적인 변화를 얼마큼 가져오는지 명확하지 않아요. 데이터를 모아 구축을 하고 분석해서 의사결정을 하면 끝나는 게 또 다른 문제로 이어져요. 모든 게 다 이어지지 않아서 결과와 피드백이 다시 데이터로 반영되지 않아요. 그래서 기업들이 빅데이터를 구축해도 개선이 되질 않았을 확률이 높아요. 그래서 파운드리는 지속 가능한 방식으로 제공하고 있어요. 조직 전체를 연결해서 디지털 전환을 가능하게 해요. 팔란티어가 말하는 디지털 전환은 직원들의 행동, 사무 업무도 포함일 듯해요. 온톨로지 온톨로지와 온톨로지를 지원하는 애플리케이션 온톨리지는 파운드리의 핵심으로 여러 계층으로 구성되어 있어요. 1계층은 시맨틱 레이어: 조직 내 모든 유형의 데이터 소스를 공유된 디지털 표현으로 연결해요. 조직을 구성하는 여러 명사의 집합체예요. 제조 또는 소매업이라면 이들은 매장 위치, 고객, 거래, 물류 센터 등 다양한 자산과 기업, 이벤트가 일을 위한 환경으로 구성되어 있어요. 이런 물체와 이벤트 사이에 연관성이 있고 상호작용을 하는 방식도 있어요. 시맨틱 레이어 모델에 의해 작동하는 동적 속성도 있어요. 시맨틱 레이어는 살아 숨 쉬는 표현이자 모형이에요. 2계층은 키네틱 레이어: 움직이는 조직. 조직의 모든 행동, 기능 및 과정, 동사. 온톨로지를 실제로 활성화해요. 고객이 거래를 완료 -> 제품이 물류 센터 도착 -> 매장으로 배송됨 같은 작업을 수행해요. 모든 물체, 이벤트 및 작업을 공유되는 방식으로 모델링돼요. 조직의 공통 언어에 기반해 발전된 의사 결정, 협업 및 애플리케이션 구축의 초석이 돼요. 3계층은 동적 레이어: 시뮬레이션, 최적화 및 프로세스 자동화. 하나의 조직을 프로그래밍 코드와 비슷하게 접근해요. 다양한 시나리오 탐색, 분기 후 시나리오가 다운스트림 운영에 미치는 영향 등을 확인할 수 있어요. 결정을 내리는 시점에 이러한 시나리오를 업데이트해 전략과 운영 간의 원활한 연결성을 강화할 수 있어요. 사용법은 하나의 워크플로우로 시작해 온톨로지를 확장해요. 온톨로지는 데이터 통합부터 시작해요. 파운드리의 여러 파이프라인 애플리케이션을 사용하면 테이블 형식 데이터(DB), 센서 데이터, 트랜잭션 데이터, 지리 공간 소스, 타사 데이터 등(태블로 같은 것들) 다양한 데이터 소스들을 온톨로지와 통합할 수 있어요. 이런 데이터 소스들이 온토롤지에 도달하면 고객, 제품, 가격, 창고 등 실제 개념과 관련된 직관적인 개념으로 변환돼요. 온톨로지를 구성하려면 정형 및 비정형 데이터에 대해 생각할 필요가 있어요. 조직 기준으로 구성된 추상적인 세상(팔란티어 파운드리로 통합된 세상)에 이런 데이터들을 연결할 방법도 고민해야 해요. 데이터만 넣으면 끝나는 게 아니고 특정 데이터를 가지고 작동하는 모델을 기반으로 운영되고 있어요. 모델을 구축하려면 모델 빌딩 도구, 저장된 프로시저, 서드파티 도구들, 오픈소스 등을 활용하면 돼요. 데이터 사이언티스트들이 주로 잘 알고 있어요. 이런 모델들은 과거의 작은 조각을 기반으로 구축되어 있어요. 우리 조직의 맞게 완전히 통합되도록 모델이 만들어지지 않았어요. 모델을 만들더라도 모델에서 영향력 있게 창출하는 건 더 어려운 일이에요. 그리고 부서들은 사일로화 되어있어서 모델을 제대로 활용하지 못해요. 사람이 모델을 잘 활용하지 못하기 때문에 이런 모델들을 온톨로지와 같은 공유 시스템에 통합해야 그나마 가치 있게 활용할 수 있어요. 파운드리는 운영 의사 결정 플랫폼이기 때문에 수많은 유형의 분석 역량을 강화하기 위해서는 각 데이터마다 상세한 표현이 필요해요. 데이터 분석가들이 가격 변동(예를 들어)이 실제로 어떤 영향을 미쳤는지 예측과 비교해서 분석해야 해요. 이걸 파운드리에선 객체의 동적 속성을 활용하면 돼요. 속성은 모델, 제공된 데이터를 기반하고 있어요. 이런 분석에서 앱 개발자는 의사 결정권자에게 주의가 필요한 이상치를 알려주는 운영 앱을 구축함(내부에서만 쓰이는 앱일 듯). 예시에서 자동 가격 변동이 발생하여 제품에 대한 수요가 크게 억제될 수 있어요. 이런 경우 모델이 인식한 내용으로는 설명이 어려운 경우도 발생할 수 있다고 해요. 이럴 때는 해당 주제에 대한 전문가가 의사 결정권자가 되어야 하고 상황을 평가해야 해요. 이러한 평가 이후 앱에서 다시 온톨로지로 흘러가야 해요. 이걸 write back이라고 해요. 그래야 시스템이 점진적으로 지능화되고, 최종 사용자로부터 예측 업데이트, 조치, 전략 업데이트 등 많은 정보를 얻을 수 있어요. 온톨로지를 사용하면 안정적이고 통제된 방식으로 운영하는 기본 시스템 전반에서 모든 작업을 실행할 수 있어요. 정교한 의사 결정을 내릴 수 있고 의사 결정권자에게 다양한 '가정' 시나리오를 실행할 수 있는 기능을 제공해요. 분석과 운영 의사 결정을 연계하여 모든 의사 결정이 최대한 정보에 입각한 결정이 되도록 보장해요. 온톨로지는 기업 전체에서 쓰던 도구 구축 프레임워크, 개발팀, 조직 외부 파트너에도 접근이 가능해요. OPI(=API)를 통해 제공하고 있어요. 그래서 파운드리 프론트엔드 말고도 타사 앱에서도 사용이 가능해요. 온톨로지는 조직의 모든 참여자를 위한 공통 어휘를 생성하는 것으로 서로 다른 데이터 소스, 모델 및 시스템을 통합하고 협업과 종속 워크플로를 가능하게 해요. 빅데이터로 업무 수행 방식까지 바꿔 협업까지 가능하게 하지 않을까요? 데이터 생성과 데이터 품질을 따지면 누가 잘하고 못하고도 확인이 가능할 것 같아요. 자신들이 하는 일의 의무가 부여되면 기업의 전체 목표로 어떻게 연결되고 목표를 위한 것임을 알게 할 수 있을 거라 생각돼요. 예) 급식 아주머니의 마음가짐 A: 직원들에게 점심을 제공한다. B: 고기반찬을 제공하니 기업의 매출이 올랐다 이 중 B 같이 어떤 의미를 알게 되면 의사결정에 임하는 자세가 달라질 것. 어떤 기업이 어떤 문제를 해결하려고 시도할 때, 그 해결 과정에서 업무, 방식, 관리, 운영 등 다양한 포인트에서도 문제가 발생해요. 결국 이를 제대로 해결하지 못하고 엉뚱하게 해결하거나 해결하지 않고 나아가도 보면 해결하려고 한 문제에 도달하지 못하고 무너지는 것 아닐까요? 물론 매출과 이익이 더 중요할 수 있어요. 내가 문제를 해결하기 위한 결정을 내리기 위해 필요로 하는 모든 정보들을 제공받고 있는가?— Ted Mabrey 의사 결정의 개선은 표준화된 작업 덕분에 되는 게 아니라 나의 결정으로부터 나오는 실시간 데이터가 우리의 작업 방식을 변화시키는 데 있어요. 어떤 문제가 발생하면 그 문제의 근본 원인을 찾아야 하는데 이 과정이 쉽지 않아요. 그런데 파운드리를 도입했다면 연결 관계가 있으니 비교적 쉬울 거예요. 그리고 온톨로지로 문제를 해결하기 쉬울 수 있음. 이런 개선을 통해 더 나은 의사 결정이 가능해져요. 온톨로지 시각화 온톨로지 시스템의 첫 번째 버킷은 데이터 파운드리에는 데이터를 연결, 변환, 통합 및 관리할 수 있게 설계된 앱들이 있어요. 정형, 비정형, 테이블, IoT, 지리, 상용 데이터 소스(SAP, Salesforce, Oracle 등)들을 파운드리에 연결할 수 있어요. 이렇게 하는 이유는 빅데이터를 구축한다는 건 첫 번째로 각종 데이터를 한 곳에 모아둬야 해요. 그다음 연결하고 변환하고 통합해서 의사 결정을 해야 해요. 이 과정이 기업마다 다른데 또 어떻게 해야 옳은 것인지 모르는 사람들에겐 난해해요. 활용 방안도 없으면서 일단 빅데이터를 구축하자는 건 "우리도 회식해야겠네" 하고 회식 전까지 뭘 먹을지 정하지도 않고 결정짓는 것. 명확한 목표 중 우선순위가 필요해요. 모델이란 모델은 요리 레시피와 같아요. 모델은 데이터를 통해 학습한 일종의 레시피, 데이터를 이해하는 특별한 함수예요. 예) 스팸 메일 필터 모델 데이터(재료): 수많은 스팸 메일과 정상 메일의 내용, 제목, 보낸 사람 정보 등 모델(레시피): 스팸 메일과 정상 메일을 구별하는 규칙과 패턴 (예: 특정 단어가 많이 포함되면 스팸, 특정 키워드가 제목에 없으면 정상 등) 결과(요리): 새로운 메일이 스팸인지 정상 메일인지 분류 예) 주가 예측 모델 데이터(재료): 과거 주가 데이터, 금리, 경제 지표, 뉴스 기사 등 모델(레시피): 주가 변동에 영향을 주는 요인과 패턴 (예: 금리가 오르면 주가가 하락할 가능성이 높다 등) 결과(요리): 내일의 특정 회사 주가 예측 모델 없이 데이터를 그냥 쓰면 너무 복잡하고 방대하기 때문에 실수가 있을 수 있어요. 매번 이렇게 하는 건 비효율적, 모델이 있으면 자동으로 결과를 예측하고 분류해 줘요. 미묘한 패턴같이 사람이 놓칠 수 있는 중요한 정보를 가진 숨겨진 패턴을 찾을 수 없어요 모델 학습을 해야 모델을 만들 수 있어요. 학습 데이터셋: 예) 요리 재료, 완성된 요리 사진 / 스팸 메일 예시, 정상 메일 예시 검증 데이터셋: 중간 점검하는 시험 문제와 같음. 검증 데이터셋으로 예측하고 결과를 정답과 비교해서 조금씩 수정하고 개선함 테스트 데이터셋: 모델 학습이 끝나고 최종 실력 평가를 위한 진짜 시험 문제와 같음. 테스트 데이터로 최종 예측을 해보고 결과를 실제 정답과 비교해 모델의 성능을 최종적으로 평가함 처음에는 예측이 안 되지만 검증 데이터셋으로 오답 노트를 하고 다시 학습 데이터셋으로 복습하면 점점 더 정확한 예측을 할 수 있어요. 이 과정을 최적화라고 불러요. 최적화의 목표는 최대한 정확하게 예측하도록 레시피를 조정하는 것이에요. = 어쩌면 이 과정을 학생들에게 적용하면 시험을 잘 볼 수 있지 않을까요? 좋은 선생님(데이터), 좋은 교재(데이터셋), 꾸준한 노력(최적화), 훌륭한 모델(명문대생 능력 있는 학생) 이런 학습 과정을 수행하기 위해선 장소가 필요해요. 데이터셋 연결: 흩어진 데이터를 한곳으로 모으는 것. 여러 데이터 소스를 하나로 통합. 데이터를 준비하는 과정 예) 냉장고, 찬장, 시장 등 여러 곳에 있는 요리 재료를 주방으로 가져와서 정리하는 것. AWS SageMaker나 GCP Vertex AI: 클라우드 기반의 AI 모델 개발 전문 주방. 강력한 AI 모델을 쉽게 만들 수 있음 예) 요리 도구 풀세트: 다양한 도구, 알고리즘 제공, 자동화 모델은 데이터를 통해 학습한 '레시피'이고, 데이터를 효율적으로 활용하기 위해 필요해요. 모델 학습은 모델에게 데이터를 '먹여주면서' 레시피를 '가르치는' 과정이에요. 데이터셋 연결은 모델 학습을 위해 여러 데이터를 '주방'으로 가져와 '재료'를 준비하는 과정이에요. GCP Vertex AI, AWS SageMaker는 모델 개발을 위한 '최첨단 클라우드 주방'이에요. 파운드리와 온톨로지의 분석 기능 데이터 분석을 지원하는 앱은 모든 유형의 사용자가 조직의 디지털 트윈을 조사하고 탐색할 수 있는 공통 워크벤치가 될 수 있게 설계되었어요. AWS 앱들처럼 팔란티어도 내부에 다양한 도구가 있어요. 이를 어떻게 사용하고 연결할지는 사용자의 마음이에요. 분석을 위해선 퀴버(Quiver)를 사용해요. 데이터 과학자가 개발한 모델을 사용하여 현재 분석과 비교할 수 있어요. 강력한 통합 데이터 및 모델 기반을 갖추는 것이 매우 중요해요. 사용자가 모델의 예측과 다른 결론에 도달했을 수 있고 사용자는 최신 분석 결과를 더 정확하게 반영하도록 모델을 업데이트할 동료(예: 데이터 과학자)에게 피드백을 제공할 수 있어요. 분석 워크플로우는 다양한 수준의 기술적 복잡성에서 발생할 수 있어요. 심층적인 주제의 전문 지식, 장기간의 조사가 필요 등 운영 워크플로우를 위한 종합적인 의사 결정 지원 역할을 하기도 해요. 운영 사용자는 올바른 결정을 내리기 위해 준비된 분석과 상호작용을 해야 하고, 일부 매개 변수를 변경하며 결과를 평가할 수 있어야 해요. 다수의 분석 기능을 활성화하려면 효과적인 데이터 대중화가 가능해야 해요. 적절한 수준의 기술적 복잡성을 갖춘 다양한 분석 툴이 필요해요. 파운드리가 제공하고 있어요. 중요한 참고 사항은 온톨로지에 대한 접근을 대중화하는 과정에서 제일 중요한 건 보안과 권한이 중앙 제어가 되는지와 잘못된 데이터를 분석하거나 잘못된 모델을 사용하여 우회할 수 없는 경우예요. 온톨로지는 권한 및 접근 제어, 접근 유형 정의, 상태 등을 포함해 중앙적으로 구성 및 관리돼요. 온톨로지를 사용하는 사용자는 매번 탐색을 위해 중요한 경계를 설정하고 재설정하는 대신 분석 및 운영 의사 결정에 집중할 수 있어요. 어쨌거나 이런 데이터들이 유기적으로 연결되어 있고 피드백도 즉각 반영할 수 있는 환경이 구축되었기 때문에 내/외부에서 사용하기 위해 만들어진 앱을 통해 사용자(=실무자)가 값을 CUD 하면 바로 반영이 돼요. 그러한 커스텀 앱을 만들 수 있게 제공하고 있어요. 파운드리는 온톨로지의 오브젝트와 요소를 표시하고 분석하는 것 외에도, 앱 개발자가 운영 담당 사용자의 일상 업무에서 사용할 수 있는 맞춤형 앱을 구축할 수 있게 지원해요. 기술 팔란티어 문서 온톨로지 플랫폼 보안, 프로젝트와 주요 보안 경계선, 보안 인가 목록 상호 호환성 (기술적인) 사용자 역할 매뉴얼 및 지원 관련 리소스 파운드리 매뉴얼 스택 오버플로우 파운드리 개발자 채널 케이스 스터디 국제 상업은행의 디지털화 과정 PG&x26;E + Palantir 에어버스 직원 역량 강화 영국 NHS와 파운드리 연구와 파운드리 더 많은 정보는 팔란티어의 임팩트 스터디 홈페이지에서 찾을 수 있음 Never mistake motion for action.— Ernest Hemingway