우리는 파운데이션 엔지니어(Foundational Engineer)를 채용합니다. 회사는 가짜지만, 업무는 진짜입니다.
요약
미래의 소프트웨어 엔지니어링 역할을 정의하는 사고 실험으로서, AI-Native 시스템을 구축할 '파운데이션 엔지니어'의 직무를 소개합니다. 인간의 의도를 실행 가능한 워크플로로 전환하고 에이전트와 소프트웨어를 오케스트레이션하는 역할을 다룹니다.
핵심 포인트
- 단순 프롬프트 엔지니어링을 넘어선 시스템 아키텍처 설계 역량 강조
- 인간과 AI 에이전트 간의 업무 분배 및 실행 경로 확보
- AI 도구를 활용하여 프로덕션 수준의 소프트웨어 구축
- 기계 생성 코드와 인간 작성 코드의 통합 검증 및 운영
가상의 채용 공고: Aster Loop는 만들어진 회사이며, 이 채용 공고는 존재하지 않습니다. 우리는 지원서를 받고 있지 않습니다. 아래의 회사, 보상, 제품 및 채용 프로세스는 예시를 위한 것입니다. 이 게시물은 소프트웨어 엔지니어링 업무가 어디로 이동하고 있는지에 대한 현실적인 사고 실험으로서 2026년 7월 18일에 작성되었습니다.
역할: 파운데이션 엔지니어 (Foundational Engineer), AI-Native 시스템
회사: Aster Loop, 가상의 시드 단계 스타트업
위치: 원격 근무, UTC-5와 UTC+2 사이의 4시간 업무 중첩 필요
고용 형태: 풀타임 (Full time)
예시 보상: 기본급 미화 $175,000 ~ $225,000, 지분 0.35% ~ 0.80% 포함
Aster Loop 소개
Aster Loop는 가장 중요한 업무가 여전히 이메일 수신함, 스프레드시트, 내부 도구 및 인간의 기억 속에 머물러 있는 팀들을 위해 AI-Native 운영 플랫폼을 구축하고 있습니다.
이 제품은 파편화된 업무를 관리되는 워크플로 (Workflows)로 전환합니다. 사람들은 결과를 정의하고 중요한 결정에 대한 권한을 유지합니다. 에이전트 (Agents)는 제한된 실행 (Bounded execution)을 처리합니다. 모든 작업은 검사 가능해야 하며, 가능한 경우 되돌릴 수 있어야 하고, 인간 소유자에게 책임이 귀속되어야 합니다.
우리는 비공개 베타 단계에 있는 11명의 가상 팀입니다. 당신은 우리의 네 번째 엔지니어로 합류하여 창업자, 제품 리드 (Product lead), 그리고 초기 디자인 파트너들과 직접 협력하게 됩니다.
역할
우리는 의도 (Intent)와 프로덕션 (Production) 사이의 계층을 책임질 수 있는 엔지니어가 필요합니다.
당신은 여전히 코드를 작성할 것입니다. 또한 무엇을 구축해야 할지 결정하고, 모호한 요청을 실행 가능한 사양 (Specifications)으로 변환하며, 인간과 에이전트 간의 업무를 분배하고, 결과물을 검증하며, 실행 경로 (Execution path)를 확보하고, 결과물이 실제 운영 환경과 접촉했을 때 생존할 수 있도록 도울 것입니다.
이것은 프롬프트 엔지니어링 (Prompt-engineering) 역할이 아닙니다. 엔지니어링으로 포장된 프로젝트 관리 (Project-management) 역할도 아닙니다. 이는 사용자 워크플로에서 아키텍처 (Architecture)로, 아키텍처에서 작동하는 변경 사항으로, 그리고 작동하는 변경 사항에서 신뢰할 수 있는 운영 체제 (Operating system)로 이동할 수 있는 사람을 위한 실무 중심의 시스템 (Systems) 역할입니다.
당신이 하게 될 일
- 복잡한 제품 및 운영 문제를 명시적인 결과물 (Outcomes), 제약 조건 (Constraints), 인터페이스 (Interfaces), 수락 기준 (Acceptance criteria)으로 전환합니다.
- 어떤 작업이 사람, 코딩 에이전트 (Coding agents), 모델 호출 (Model calls), 결정론적 서비스 (Deterministic services), 또는 소프트웨어가 전혀 필요 없는 영역에 속할지 결정합니다.
- AI 도구가 실질적인 레버리지 (Leverage)를 창출하는 곳에서 이를 활용하며, 스택 전반에 걸쳐 프로덕션 소프트웨어를 구축합니다.
- 에이전트 (Agents), 브랜치 (Branches), 도구 (Tools), 브라우저 (Browsers), 테스트 환경 (Test environments), 그리고 배포 워크플로 (Deployment workflows) 전반에 걸친 변화를 오케스트레이션 (Orchestrate)합니다.
- 사람이 작성한 코드와 기계가 생성한 코드를 모두 리뷰하고, 디프 (Diff)를 넘어 전체 동작을 검증합니다.
- 품질, 신뢰성, 지연 시간 (Latency), 비용, 유지보수성 및 반복되는 동작을 위한 평가 시스템 (Evaluation systems)을 구축합니다.
- 명확한 아키텍처 (Architecture), 컨벤션 (Conventions), 경계 (Boundaries), 그리고 운영 지침을 통해 저장소 (Repositories)를 사람과 에이전트 모두가 읽기 쉽게 만듭니다.
- 자동화된 동작을 위한 권한 범위 (Permission scopes), 승인 게이트 (Approval gates), 감사 추적 (Audit trails), 그리고 안전한 실패 경로 (Safe failure paths)를 설계합니다.
- 고립된 기능을 출시하는 대신, 사용자와 협력하여 새로운 역량을 기존 워크플로 (Workflows)에 맞게 통합합니다.
- 아키텍처 드리프트 (Architectural drift)를 줄이고, 불필요한 복잡성을 제거하며, 소유권 (Ownership)을 가시화함으로써 시간이 지나도 일관성을 유지합니다.
성공적인 모습 (What success looks like)
첫 30일 동안, 당신은 의도 (Intent)부터 실행 (Execution)에 이르는 하나의 고객 워크플로 (Customer workflow)를 매핑하고, 좁은 범위의 프로덕션 개선 사항을 출시하며, 다른 엔지니어나 경계가 지정된 코딩 에이전트 (Bounded coding agent)가 안전하게 후속 변경을 수행할 수 있을 정도로 시스템을 잘 문서화하게 될 것입니다.
60일 차까지, 당신은 하나의 엔드 투 엔드 (End-to-end) 워크플로를 책임지게 됩니다. 여기에는 사양 (Specification), 구현 (Implementation), 평가 (Evaluations), 권한 (Permissions), 배포 경로 (Deployment path), 관측 가능성 (Observability), 그리고 사람의 승인 지점 (Human approval points)이 포함됩니다.
90일 차까지, 해당 워크플로는 알려진 신뢰성 및 비용 경계 내에서 실제 고객 운영 환경에서 실행되어야 합니다. 팀은 그것이 어떻게 작동하는지, 어떻게 실패하는지, 그리고 실패 시 누가 개입해야 하는지를 이해해야 합니다.
6개월이 지났을 때, 성공이란 단순히 빠르게 출시하는 것 이상을 의미합니다. 당신이 작업했기 때문에 제품을 더 쉽게 추론 (Reason)할 수 있어야 합니다.
다음과 같은 경우 적합할 수 있습니다 (You may be a fit if)
- 엔드 투 엔드 (end to end)로 프로덕션 시스템을 구축하고 운영한 경험이 있습니다. 우리는 특정 경력 연수보다 증거를 더 중요하게 생각합니다.
- 주변의 제품, 워크플로 (workflow), 그리고 비즈니스 제약 사항을 놓치지 않으면서 코드에 깊게 몰입할 수 있습니다.
- 불확실성이 사라진 척하지 않으면서도, 모호함을 줄이는 사양 (specifications)을 작성합니다.
- AI 코딩 도구를 사용하지만, 그럴듯한 결과물과 검증된 작업을 혼동하지 않습니다.
- 동작의 일부가 확률적 (probabilistic)인 시스템을 위한 테스트와 평가 (evaluations)를 설계할 수 있습니다.
- 최소 권한 (least privilege), 비밀 경계 (secret boundaries), 승인 경로 (approval paths), 그리고 소프트웨어가 직접 행동할 때 발생하는 리스크를 이해합니다.
- 컨텍스트 (context) 또한 시스템의 일부이기에, 글로 명확하게 소통합니다.
- 정답이 단순화, 통합, 혹은 구축하지 않는 것임을 우리에게 말해줄 수 있습니다.
우대 사항 (Helpful, not required)
- 에이전트 오케스트레이션 (agent orchestration), 평가 하네스 (evaluation harnesses), 도구 호출 (tool-calling) 시스템, 또는 인간 승인 워크플로 (human approval workflows)에 대한 경험.
- 이벤트 기반 시스템 (event-driven systems), 큐 (queues), 내구성이 있는 작업 (durable jobs), 또는 분산 워크플로 (distributed workflows) 설계 경험.
- 엔터프라이즈 통합 (enterprise integrations) 및 복잡한 운영 데이터 (messy operational data)를 다룬 경험.
- 아키텍처, 제품 판단, 고객 작업, 그리고 구현이 중첩되는 초기 단계 스타트업에서의 경험.
우리는 한 사람이 모든 항목을 갖추고 오기를 기대하지 않습니다. 다만 자신의 판단력이 어디에서 강한지, 어디에서 아직 발전 중인지, 그리고 그 격차를 어떻게 메울 것인지를 알고 있기를 기대합니다.
우리가 일하는 방식 (How we work)
- 인간은 방향성과 중대한 결정을 책임집니다.
- 자동화는 제한된 범위, 증거, 그리고 신뢰할 수 있는 운영을 통해 권한을 얻습니다.
- 통과된 테스트는 증거일 뿐, 워크플로가 옳다는 증명은 아닙니다.
- 속도는 중요하지만, 보이지 않는 복잡성을 만들어내는 속도는 빌려온 시간일 뿐입니다.
- 명확한 컨텍스트 (context)는 인프라입니다.
- 시스템을 출시하는 사람은 출시 후 시스템이 어떻게 동작하는지에 대한 책임을 공유합니다.
가상의 면접 과정 (The fictional interview process)
- 당신이 구축한 시스템과 그 과정에서 내린 트레이드오프 (trade-offs)에 대해 30분간 대화합니다.
- 엉망인 고객 워크플로우 (customer workflow)를 바탕으로 한 60분간의 아키텍처 (architecture) 세션을 진행합니다.
- 선택 사항인 코딩 에이전트 (coding agent)를 활용하여, 작은 리포지토리 (repository)에서 3시간 동안 유급으로 진행되는 실무 연습을 합니다.
- 오너십 (ownership), 판단력 (judgment), 그리고 우리가 어떻게 함께 일할 것인지에 대해 마지막 대화를 나눕니다.
퍼즐 인터뷰 (puzzle interviews)는 없습니다. 무급 과제 (unpaid take-home project)도 없습니다. AI 도구 사용은 허용되지만, 도구가 생성한 결과물을 설명하고 검증할 수 있어야 합니다.
원문 에세이 읽기: The Foundational Engineer Is Moving Upward
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기