넥토리얼 지원자를 위한! 시니어 개발자(대략 30년)의 바이브 코딩 엿보기

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

넥토리얼 지원자가 약 30년 경력 시니어 개발자의 바이브 코딩에서 배울 핵심은, AI에 코드를 맡기기 전에 요구사항과 구조를 구체화하고 예외 상황의 판단 기준을 정하는 능력이다.

📌 핵심 요점

1. 채용 준비의 중심은 문제 해결 과정이다. 영상은 넥토리얼이 코딩 테스트를 폐지하고 AI 활용 역량을 평가한다고 설명한다. 지원자는 결과물뿐 아니라 문제를 어떻게 정의하고 설계 결정을 내렸는지 설명할 수 있어야 한다. [02:07]
2. 설계에서 구현의 모호함을 줄인다. 기능뿐 아니라 성능·보안 요구사항을 문서화하고, 모듈별 테스트 단위와 구현 순서를 정한다. AI가 역질문하고 사람이 결정하는 대화도 요구사항을 구체화하는 방법이다. [06:05] [07:15] [52:24]
3. 기술 선택은 실제 운영 작업에서 출발한다. 시다바리는 로그 확인·오류 수정·파일 전송·배포의 반복을 줄이려는 도구다. Tauri의 웹 UI와 Rust 네이티브 코어를 IPC로 연결해 SSH·SFTP·로컬 파일·프로세스 기능을 통합하는 구조를 검토한다. [20:08] [25:14] [26:09]
4. 개인용 도구의 범위를 명확히 제한한다. AI가 제안한 범용 규칙 엔진까지 만들기보다 정해진 작업 로직을 하드코딩하기로 한다. 자동화 도중 어느 단계에서든 문제가 발생하면 중단하고 사람이 확인하도록 실패 조건도 정한다. [43:17] [55:41]
5. 초기 실행과 기능 완성을 구분한다. 윈먹스는 설계 문서와 초기 설정만 있는 저장소에서 클로드 코드로 구현을 시작했고, 빌드 후 메인 창 실행까지 확인했다. 그러나 트레이 아이콘 로직은 없었으며, 전체 기능이 검증된 상태로 볼 수는 없다. [12:14] [30:35]

🧩 배경과 문제 정의

• 넥토리얼의 코딩 테스트 폐지와 AI 활용 역량 평가는 채용 준비의 중심을 바꾼다. 최종 결과물뿐 아니라 문제 접근 방식과 구조적 사고력이 중요해진다.
• 개발 경험과 기술 어휘는 AI에 요구사항을 구체적으로 전달하는 데 유리하게 작용한다. 바이브 코딩에서도 문제 정의와 설계의 품질이 구현 결과를 좌우한다.
• 실습의 핵심 과제는 서버 운영에서 반복되는 로그 복사, 오류 수정, 파일 전송과 배포를 통합하는 것이다. 시다바리 운영 도구와 윈먹스 터미널 프로젝트가 구체적인 사례다.

🕒 시간순 섹션별 상세정리

1. AI 활용 역량과 문제 해결 과정으로 이동하는 채용 평가

• 약 30년간 쌓인 개발 경험과 기술적 배경지식은 프롬프트에 넣을 어휘와 요구 내용을 구체화하는 데 유리하다. 신입 지원자에게는 이러한 차이를 실제 작업 과정으로 접할 기회가 필요하다. [00:36]
• 넥토리얼은 코딩 테스트를 폐지하고 AI 활용 역량을 강하게 평가한다. 최종 결과물과 함께 문제 접근 방식과 구조적 사고력을 평가하므로, 문제를 인지하고 대응 방법을 찾는 능력이 중요해진다. [02:07]

2. 지원자 학습 지원과 요구사항 설계의 비중

• 넥토리얼 지원자는 별도 증빙 없이 메일로 원하는 강의의 할인 쿠폰을 요청할 수 있으며, 할인율은 최소 50%에서 최대 70% 수준이다. [03:16]
• 자산 관리 웹서비스 사례에서는 기획과 설계에 두 시간 이상을 쓴다. 기능적 요구사항뿐 아니라 성능과 보안 같은 비기능적 요구사항을 프롬프트에 구체적으로 반영하는 과정이 중요하다. [04:25]

3. 설계를 먼저 확정하고 모듈과 구현 순서를 결정하는 방식

• 작업은 크게 설계와 구현의 두 단계로 나뉜다. 설계의 부족하거나 모호한 부분을 해소하고 성능·보안의 요구 수준까지 문서에 담으면 이후 구현이 단순해진다. [06:05]
• 설계 단계에서 구현할 모듈을 구분해야 테스트 단위와 구현 순서를 정할 수 있다. UI가 있는 경우에는 별도 화면 설계 과정을 대신해 UI부터 구현한다. [07:15]

4. 대화 이력과 설계 변경을 줄이는 작업 기준

• 과거 대화 이력을 계속 투입하는 방식은 경험상 효용이 낮고, 컨텍스트를 낭비해 AI의 응답 성능을 떨어뜨릴 수 있다. 대화 기록의 양 자체가 작업 품질을 보장하지는 않는다. [08:11]
• 구현 중 수정은 늘 발생하지만, 설계에 충분한 시간을 쓴 사례에서는 설계 수준의 변경이 적고 UI 수정이 많았다. 다만 규모가 큰 웹서비스에서는 양상이 달라질 수 있다. [10:08]

5. 설계 문서만 있는 저장소에서 윈먹스 구현 시작

• tmux를 보고 윈먹스 프로젝트가 구체화됐으며, 수업에서 직접 구현하는 방향으로 커리큘럼이 바뀌었다. 구현에 들어가는 시점에는 설계가 상당 부분 끝난 상태다. [11:01]
• 저장소의 첫 커밋에는 초기 설정과 설계 문서만 있고 구현 코드는 없다. 미리 준비한 영문 프롬프트를 클로드 코드에 입력해 개발을 시작하며, 별도 스킬은 설치하지 않는다. [12:14]

6. 여러 터미널 작업을 묶고 연결 종료에 대비하는 구조

• 서버에 여러 터미널을 연결하면 작업을 병렬로 실행할 수 있지만, 일반적인 연결 상태에서는 터미널 종료로 진행 중인 작업이 끊길 수 있다. 작업 완료까지 창을 유지해야 하는 부담이 생긴다. [14:10]
• tmux는 여러 터미널을 페인으로 나눠 한 화면에 배치하고, 각 영역에서 빌드나 모니터링을 수행한다. 백그라운드에서 세션을 유지하므로 SSH 연결이 끊겨도 작업을 계속할 수 있다. [14:49]

7. 장시간 작업 보호와 이틀짜리 프로토타입 구상

• 빌드·다운로드·학습처럼 오래 걸리는 작업은 연결 종료로 누적 작업을 잃을 위험이 있다. 세션을 유지하면 SSH 끊김을 걱정하지 않고 코드 편집, 로그 확인, 서버 실행을 한 화면에서 병행할 수 있다. [16:30]
• 시다바리를 이틀 동안 개발한 경험을 바탕으로, 유사한 화면 구성을 가진 윈먹스도 이틀이면 프로토타입이 가능하다는 추정이 나온다. 예상 일정은 설계 하루와 구현 하루다. [17:14]

8. 시다바리의 출발점인 초기 서비스 운영과 오류 추적

• 시다바리는 AWS에서 운영하는 강의 서비스의 관리 작업을 편하게 만들기 위한 프로젝트다. 소규모 초기 서비스에서는 오류가 많을 수 있고, 그중 상당수가 버그일 가능성에 대비해야 한다. [18:24]
• 핵심 기능이 돌아가는 EC2 서버는 지속적인 모니터링 대상이다. 서비스 구조에 대한 이해를 바탕으로 백엔드 로그와 사용자 제보를 분석하고, 문제의 원인을 추적해 수정한다. [19:17]

9. 로그 복사부터 배포까지 반복되는 수동 작업

• 윈도우 PC에서 PuTTY로 서버 로그를 확인하고, 별도 터미널의 클로드 코드에 오류 로그를 복사해 붙여 넣는다. 오류가 생길 때마다 두 창을 오가는 반복 작업이 발생한다. [20:08]
• 버그 수정 후 로컬 빌드와 기본 테스트·사용성 테스트를 거치고, GitHub에 푸시한 뒤 빌드 산출물인 JAR 파일을 업로드한다. 파일 배포와 서비스 재시작도 수동으로 수행하며, 셸 스크립트가 명령 입력을 일부 간소화한다. [20:46]

10. 웹 UI와 네이티브 코드의 실행 계층

• Tauri의 UI는 React 같은 웹 기술로 구성할 수 있다. 자바스크립트 UI가 실행되려면 브라우저에 내장된 실행 엔진이 필요하며, 엔진 자체는 네이티브 코드에 해당한다. [21:28]
• 네이티브 코드는 CPU와 운영체제에 대한 의존성을 가진다. C·C++·Rust 같은 언어로 만드는 이 계층과 달리, 브라우저 안의 자바스크립트는 실행 엔진이 허용하는 범위에서 동작한다. [22:44]

11. Tauri의 웹 화면과 Rust 코어 연결

• 브라우저 안의 자바스크립트는 브라우저가 허용하지 않는 다른 프로세스 연결이나 시스템 정보 접근을 직접 수행할 수 없다. Tauri는 웹 기술을 UI에 사용하고, 실질적인 시스템 기능을 Rust 네이티브 코드로 분리하는 구조다. [24:02]
• 웹 UI와 네이티브 코어는 IPC로 데이터를 주고받으며 파일 접근, 네트워크 입출력, 운영체제 API 호출 등을 연결한다. 윈도우에서는 Edge를 사용하는 WebView2가 웹 화면을 담당한다. [25:14]

12. 서버 운영 도구에 필요한 기능과 Tauri 선택 배경

• 시다바리에는 SSH 접속, 원격 명령 실행과 결과 표시, SFTP 파일 전송이 필요하다. EC2 접속에는 키 설정도 필요하므로 단순한 웹 화면을 넘어 인증과 네트워크 기능을 함께 다뤄야 한다. [26:09]
• 별도 터미널의 빌드 실행과 로컬 파일 접근까지 통합하려면 운영체제 기능을 활용해야 한다. 이러한 요구와 Electron 사용 경험에서 느낀 속도 불만이 Tauri 선택의 배경이다. [26:45]

13. 윈먹스 초기 구현 완료와 첫 빌드 진행

• 클로드 코드가 초기 구현 작업을 마쳤고, 별도 명령 프롬프트에서 Tauri 빌드를 시작한다. 첫 빌드는 시간이 걸리므로 실행해 둔 상태로 다음 작업을 이어간다. [27:21]
• 수업이 진행되는 동안 프로토타입의 초기 구현이 끝나 빌드 단계에 들어갔다. 이 시점에는 빌드 후 실행 결과까지 확인한 상태는 아니다. [28:02]

14. 별도 스킬 없는 설계 대화와 빌드 종료

• 설계는 별도 스킬이나 하네스 엔지니어링 없이 일반 대화로 진행한 사례다. 작업 방식의 중심은 추가 도구 구성보다 설계 단계의 대화에 있다. [29:02]
• 윈먹스의 초기 빌드가 끝났다. 현재 구간에서는 빌드 종료까지만 확인되며, 프로그램 실행 화면과 기능 검증 결과는 아직 확인되지 않았다. [29:51]

15. 초기 실행 검증과 작업 지침의 지속성

• 빌드 후 메인 창은 실행됐지만 트레이 아이콘 로직은 아직 없다. 초기 골격의 실행 성공과 기능 완성은 구분해야 한다. [30:35]
• 한국어 응답 지침을 CLAUDE.md에 남기고 다음 작업을 절차대로 진행하도록 요청한다. 설계에 사용한 대화는 질문 65개와 응답 65개다. [31:01]

16. 터미널 통합을 위한 운영체제 접근

• 콘솔 입출력을 파일로 추상화하면 UI와 연결해 출력을 화면에 표시할 수 있다. 여러 터미널의 처리는 하나의 프로세스가 여러 입출력 대상을 다루는 구조로 접근할 수 있다. [33:07]
• 문제는 운영체제에 의존하는 특수한 입출력 대상에 브라우저가 직접 접근하기 어렵다는 점이다. UI 기술 선택과 별개로 네이티브 접근 경로가 필요하다. [34:06]

17. 웹 UI 구현 가능성과 기술 대안 탐색

• 터미널 통합의 구현 후보로 렌더링 라이브러리, Node.js의 셸 프로세스 실행, 웹소켓 연결이 나온다. VS Code와 커서의 내장 터미널이 참고 사례다. [34:34]
• 첫 제안만으로 기술을 확정하지 않고 다른 대안도 확인해야 한다. 데스크톱 앱을 위한 선택지는 일렉트론 외에 Rust 백엔드를 사용하는 방식까지 넓어진다. [35:18]

18. Rust 백엔드와 웹뷰의 역할 구분

• 여기서 Rust 백엔드는 웹 서버가 아니라 파일 시스템 접근, 운영체제 API 호출, 터미널 생성 등을 담당하는 네이티브 코드다. 웹뷰는 프런트엔드 렌더링을 맡는다. [36:24]
• 자바스크립트에서 Rust 코드를 호출하는 경로는 HTTP가 아닌 IPC다. invoke 호출이 네이티브 기능 실행으로 이어지므로, 구조와 작동 원리를 함께 확인해야 한다. [37:11]

19. 웹뷰 내부 구조와 기존 지식의 연결

• 일렉트론과 달리 Chromium을 번들하지 않고 시스템 웹뷰를 활용하는 구조이며, 윈도우에서는 Edge 기반 엔진을 사용한다. 이 차이가 내부 구조를 이해하는 단서가 된다. [37:59]
• 윈도우 웹뷰의 COM 기반 인터페이스를 기존 지식과 연결하면 네이티브 연동 방식을 가늠할 수 있다. MFC로도 구현할 수 있는지 확인하는 질문은 구조에 대한 가설을 점검하는 과정이다. [38:39]

20. 관심사에 맞춘 AI 추천과 실제 요구의 분리

• MFC 구현 가능성을 묻자 기존 MFC 자산과 개발 경험을 근거로 추천까지 계속된다. 단순한 관심 표명이 기술 선호로 해석될 수 있으므로 추천이 유일한 선택인지 확인해야 한다. [40:11]
• 실제 요구는 MFC 활용이 아니라 여러 경로의 터미널을 동시에 운영하면서 반복하는 수작업의 자동화다. 현재 불편과 작업 맥락을 구체적으로 전달해야 설계 방향이 목적에 맞춰진다. [41:14]

21. 개인용 도구에 과도한 범용화를 막는 범위 설정

• 작업 절차를 규칙으로 표현하고 문법과 구문 분석을 붙이는 범용 워크플로 도구가 설계 후보로 나온다. 단순 반복 작업의 자동화가 규칙 언어 개발로 커질 수 있다. [42:40]
• 사용 범위를 혼자 쓰는 도구로 한정하고 작업 로직을 하드코딩하기로 한다. 필요한 것은 범용 규칙 엔진보다 정해진 지시를 정확하게 수행하는 동작이다. [43:17]

22. 기획 문서의 정확성과 범용화 비용

• 기술 이해가 부족하면 AI의 제안을 의심하기 어려워진다. 기획 대화에서 충분히 정보를 교환하고 문서를 정교하게 만들수록 이후 구현에서 추가로 판단할 일을 줄일 수 있다. [44:00]
• 규칙 엔진은 작은 프로그래밍 언어와 런타임을 만드는 작업으로 커질 수 있다. 언어·런타임·IDE를 함께 만들었던 과거 사례에는 약 6개월이 걸렸으며, 개인용 도구에는 이런 범용화 비용이 부담이다. [45:28]

23. 배포 자동화의 기능 분해와 라이브러리 재사용

• 배포 절차는 코드 생성, 빌드, EC2 접속, JAR 파일의 SFTP 업로드, 재시작으로 계속된다. 각 단계의 성공 여부와 SSH·파일 전송 기능의 구현 가능성을 확인해야 한다. [46:00]
• Rust 생태계의 기존 크레이트가 SSH·SFTP 내장 구현의 후보가 된다. 필요한 기능을 직접 만드는 대신 라이브러리로 충족할 수 있는지 검토하면 구현 부담을 줄일 수 있다. [47:45]

24. 사람의 판단을 포함한 자동화와 응답 검토

• 빌드·업로드·재시작 후 실행 로그를 확인하고, 오류 로그를 클로드 코드에 전달해 수정과 재실행으로 연결하는 흐름을 구상한다. 다음 자동화 절차를 진행할지는 사람이 판단한다. [48:33]
• 설계에는 긴 AI 응답을 대부분 읽고, 이해되지 않는 내용을 찾아 다시 질문하는 시간이 들어간다. 응답과 자신의 의도를 대조하는 과정이 요구사항의 오해를 찾는 데 필요하다. [49:46]

25. 설계 회의와 코드 작성의 역할 분리

• 설계 중에도 AI가 구현을 시작하려 할 수 있으므로, 코드 작성은 클로드 코드에 맡기고 현재 대화에서는 작업 내용과 절차를 결정한다는 역할을 명확히 한다. [50:49]
• 필요한 기능을 요소별로 나누고 구현 순서와 미결정 사항을 확정해야 한다. 우선순위가 있는 안건 목록은 긴 설계 대화를 구체적인 결정으로 연결한다. [51:25]

26. AI의 역질문으로 모호한 요구 해소

• 질문은 사람이 하고 AI가 답하는 방향으로만 흐를 필요가 없다. 설계 안건에 대해 AI가 질문하고 사람이 결정하는 방식도 요구사항을 구체화하는 데 유용하다. [52:24]
• 모호한 부분은 반드시 확인 질문을 하도록 요구한다. 준비 단계의 필요 여부처럼 작은 조건까지 결정하면서 불확실성을 줄여야 상세한 실행 요구가 만들어진다. [52:58]

27. 예외 처리의 결정권과 실패 시 중단 원칙

• 문제 발생 시 행동을 정하지 않으면 AI가 임의로 빈칸을 채우게 된다. 이런 결정이 쌓일수록 결과물이 의도에서 멀어지므로 기능과 절차의 모호함에 직접 방향을 정해 줘야 한다. [54:55]
• 어느 단계에서든 문제가 하나라도 발생하면 멈추고 사람이 과정을 확인한다는 원칙을 둔다. 이 개인용 도구에서는 자동 복구 로직의 필요가 줄고, 실패 시 행동 조건도 명확해진다. [55:41]

🧾 결론

• 이 사례에서 개발 경험은 기술 어휘로 요구사항을 표현하고 AI의 제안이 목적에 맞는지 판단하는 데 쓰인다.
• 설계 대화의 가치는 질문 수 자체보다 기능·구현 순서·예외 처리에 관한 결정을 구체적으로 남기는 데 있다.
• 사람은 목적과 범위, 실패 시 행동을 결정하고 AI는 정해진 설계를 구현하는 역할 분담이 작업의 중심이다.
• 별도 스킬 없이 진행한 사례이지만, 이를 모든 프로젝트에서 추가 도구가 불필요하다는 결론으로 확대할 근거는 없다.

📈 투자·시사 포인트

• 채용 준비에서는 AI로 만든 결과물과 함께 요구사항 문서, 기술 선택 이유, 검증 과정을 제시하는 역량의 중요성을 읽을 수 있다.
• 개발 생산성은 코드 생성 속도뿐 아니라 로그 복사·빌드·업로드·재시작처럼 반복되는 운영 작업을 얼마나 줄이는지로도 살펴볼 필요가 있다.
• 도구 선택에서는 웹 화면 구현 능력과 운영체제 접근 요구를 함께 평가해야 한다. 이 사례의 Tauri 선택은 필요한 시스템 기능과 기존 Electron 사용 경험에 근거한다.
• 자료에는 기업 실적, 시장 규모, 비용 절감의 정량 자료가 없으므로 특정 기업의 투자 매력이나 수익성 개선을 판단할 근거로 쓰기에는 부족하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 넥토리얼의 코딩 테스트 폐지와 AI 활용 평가에 관한 설명은 영상에 제시된 내용이다. 실제 지원 시 적용되는 전형과 평가 기준은 해당 모집 공고에서 확인해야 한다.
• 윈먹스를 이틀 안에 프로토타입으로 만들 수 있다는 말은 시다바리 개발 경험에 따른 추정이다. 자료에서 확인되는 결과는 초기 빌드와 메인 창 실행이며, 기능 완성이나 전체 일정 달성은 확인되지 않는다.
• 대화 이력을 계속 넣는 방식의 효용이 낮다는 평가와 설계 후 변경이 적었다는 설명은 개인 경험이다. 대규모 웹서비스에서도 같은 결과가 나는지는 검증되지 않았다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 지원하려는 넥토리얼 모집 공고에서 AI 활용 허용 범위와 평가 항목을 확인한다.
• 반복되는 운영 작업 하나를 골라 입력·출력·작업 순서와 현재의 불편을 문서로 정리한다.
• 기능 요구사항에 성능·보안 조건을 추가하고, 모듈별 구현 순서와 테스트 단위를 정한다.
• AI에 모호한 조건을 역질문하도록 요청하고, 제안한 기술이 실제 요구를 충족하는지 대안과 함께 검토한다.

❓ 열린 질문

• 넥토리얼의 실제 평가에서는 결과물의 완성도와 문제 접근 방식·구조적 사고력을 어떤 기준으로 구분해 판단하는가?
• 윈먹스의 터미널 통합과 연결 종료 대응은 이후 구현에서 어떤 방식으로 검증되는가?
• 개인용 도구가 팀의 운영 도구로 확장되면 하드코딩과 실패 시 중단 원칙을 어디까지 유지할 수 있는가?