Mantis 소프트웨어 회사에서의 인턴십 경험
요약
Mantis 소프트웨어 회사에서의 인턴십을 통해 AI 보조 소프트웨어 개발 프로세스와 LLM 활용법을 학습한 경험을 다룹니다. 특히 AI 기반 RPG 프로젝트를 진행하며 캐릭터 생성, 스토리 연속성 유지, JSON 형식 출력 등을 위해 프롬프트 엔지니어링을 어떻게 적용했는지 상세히 설명합니다.
핵심 포인트
- 프롬프트 엔지니어링은 모델의 어조, 환경, 출력 형식을 정교하게 제어하는 핵심 프로세스임
- 모호한 명령은 모호한 결과를 초래하므로 모델의 역할과 출력 형식을 명확히 정의해야 함
- 일관된 데이터 처리를 위해 JSON과 같은 구조화된 출력 형식을 지정하는 것이 중요함
- 오류 시나리오 고려 및 사용자 경험(UX)을 염두에 둔 프롬프트 설계가 필요함
지난 몇 주간의 인턴십 기간 동안, 저는 단순히 코드를 작성하는 것뿐만 아니라 AI 보조 소프트웨어 개발 프로세스 (AI-assisted software development processes)가 실제로 어떻게 작동하는지 배울 수 있는 기회를 가졌습니다. 대규모 언어 모델 (Large Language Models, LLM)과 함께 작업하고, 프롬프트 엔지니어링 (Prompt Engineering) 뒤에 숨겨진 논리를 이해하며, 아이디어를 작동하는 프로젝트로 변환하는 과정은 저에게 믿을 수 없을 정도로 교육적인 경험이었습니다. 이 글에서는 우리가 개발한 AI 기반 RPG 프로젝트와 그 과정 전반에 걸쳐 배운 기술적 개념들에 대해 이야기하고자 합니다.
프롬프트 엔지니어링 (Prompt Engineering)이란 무엇인가? 프롬프트 엔지니어링은 AI 모델에 전달하는 명령어나 지침을 가장 정확한 결과를 생성할 수 있는 방식으로 설계하는 프로세스입니다. 처음에는 단순히 "질문을 하는 것"처럼 보일 수 있지만, 실제로 이는 모델이 행동하는 방식에 상당한 영향을 미칩니다. 예를 들어, 동일한 모델에게 "이야기를 써줘."라고 말하는 것과 "어두운 분위기와 세 가지 선택 가능한 액션이 포함된 중세 배경의 인터랙티브 RPG 이야기를 만들어줘."라고 말하는 것 사이에는 엄청난 차이가 있습니다. 두 번째 예시에서는 모델의 어조 (Tone), 환경 (Environment), 출력 형식 (Output format), 그리고 사용자 경험 (User experience)이 훨씬 더 정교하게 제어됩니다. 프롬프트 엔지니어링은 우리의 RPG 프로젝트에서 특히 중요했는데, 그 이유는 AI가 다음과 같은 작업을 수행해야 했기 때문입니다: 일관된 캐릭터 생성, 스토리 연속성 유지, JSON 형식으로 출력 생성, 게임 전반에 걸쳐 동일한 분위기 유지.
프롬프트를 작성할 때 무엇에 주의를 기울였는가? 프롬프트를 작성하며 배운 가장 중요한 사실 중 하나는 모호한 명령은 모호한 결과를 낳는다는 것입니다. 모델이 무엇을 수행해야 하는지 명확하게 정의하는 것이 필수적입니다.
우리가 집중했던 주요 사항들은 다음과 같습니다:
- 출력 형식 (output format)을 명확하게 정의하기
- 모델의 역할 (role) 지정하기
- 불필요한 자유도 피하기
- 일관성을 유지하기 위한 규칙 추가하기
- 오류 시나리오 (error scenarios) 고려하기
- 사용자 경험 (user experience) 염두에 두기
예를 들어, 우리는 모델이 일반 텍스트 대신 JSON을 생성하기를 원했기 때문에, 프롬프트 (prompt) 내에 필요한 필드들을 명시적으로 정의했습니다:
{ "karakterAdi" : "Kaptan Armand Devereux" , "karakterArkaplan" : "1692 yılında Karayipler’de ün salmış eski bir Fransız korsanıdır. Genç yaşta donanmadan ayrılmış ve kendi mürettebatını kurarak tehlikeli sularda yaşamaya başlamıştır. Altın ticaret gemilerine yaptığı baskınlarla tanınır ancak son yıllarda kayıp bir hazineyi bulmaya takıntılı hale gelmiştir." , "karakterDt" : "17. yüzyıl, Karayipler" , "olaylar" : "Fırtınalı bir gecede geminizle terk edilmiş bir adaya yaklaşıyorsunuz. Mürettebatınız huzursuz görünüyor çünkü adanın lanetli olduğuna dair söylentiler duyulmuş durumda. Ancak eski bir harita, kayıp hazineye ulaşmanın yalnızca burada mümkün olduğunu gösteriyor." , "muhtemelAksiyonlar" : [ "Mürettebatı toplayıp gece hemen adaya çık." , "Sabaha kadar gemide bekleyip adayı uzaktan gözlemle." , "Haritadaki işaretleri tekrar inceleyerek farklı bir rota belirle." ] }
이러한 구조 덕분에 애플리케이션 측에서 데이터를 훨씬 더 효율적으로 처리할 수 있었습니다.
우리의 프로젝트: Past Life Simulator
인턴십 기간 동안, 우리는 Past Life Simulator라는 AI 기반 RPG 게임을 개발했습니다. 게임에서 사용자는 다음과 같은 캐릭터를 선택합니다:
- 해적 (Pirate)
- 기사 (Knight)
- 탐험가 (Explorer)
- 무슈 (Monsieur)
그리고 완전히 AI에 의해 생성되는 역동적인 이야기에 진입합니다. 매 턴마다 플레이어에게는 세 가지의 서로 다른 행동이 제시됩니다. 선택한 결정에 따라 이야기는 완전히 달라집니다. 전통적인 분기형 시나리오 (branching scenario) 시스템과 달리, 이곳의 콘텐츠는 인공지능 (artificial intelligence)에 의해 즉석에서 생성됩니다.
프로젝트에서 우리는 다음을 사용했습니다:
- Mistral AI API
- Python & Flask
- HTML/CSS
- Vanilla JavaScript
우리는 또한 모바일 호환성 (mobile compatibility)과 사용자 경험 (user experience)에도 세심한 주의를 기울였습니다.
왜 SRS 문서를 작성했나요?
개발을 시작하기 전, 우리는 즉시 코딩을 시작하지 않았습니다. 먼저, SRS (Software Requirements Specification, 소프트웨어 요구사항 명세서) 문서를 준비했습니다. 처음에는 이 단계가 불필요하다고 생각했지만, 프로젝트가 진행됨에 따라 왜 이것이 그토록 중요한지 이해하게 되었습니다. SRS 문서는 다음과 같은 도움을 주었습니다:
- 프로젝트 범위 (project scope) 명확화
- 요구사항 (requirements)의 명확한 정의
- 구현할 기능 결정
- 발생 가능한 문제 예측
- AI 도구에 더 정확한 가이드 제공
우리의 SRS 문서에는 다음 내용이 포함되었습니다:
- 기능적 요구사항 (functional requirements)
- 사용자 시나리오 (user scenarios)
- API 구조
- 인터페이스 요구사항 (interface requirements)
- 성능 기대치 (performance expectations)
- 에러 처리 (error handling)
- 보안 세부 사항 (security details)
예를 들어, 문서는 다음과 같은 사항을 명시적으로 규정했습니다:
- 게임은 단일 Python 파일에서 실행될 것
- 어떠한 JS 프레임워크도 사용하지 않을 것
- Mistral API가 AI 상호작용을 처리할 것
- 게임 진행 상황은 저장되지 않을 것
이러한 계획 프로세스 덕분에, 우리는 다음에 무엇을 할지 끊임없이 고민하는 대신 더 체계적으로 앞으로 나아갈 수 있었습니다.
SRS 문서를 AGENTS.md / CLAUDE.md로 변환하기
가장 흥미로운 경험 중 하나는 SRS 문서를 AI 도구가 이해할 수 있는 기술적 계획 문서로 변환하는 것이었습니다. 이 과정에서 우리는 Claude.ai를 사용했습니다. 표준 SRS 문서는 인간을 위해 작성되지만, AI 코딩 도구는 다음과 같은 문서에서 더 잘 작동합니다:
- 더 짧고
- 더 기술적이며
- 더 작업 지향적인 (task-oriented) 문서
이 때문에 우리는 프로젝트 목표, 기술적 요구사항, 작업 (tasks), 파일 구조, API 동작과 같은 정보들을 단순화하여 AGENTS.md 형식으로 변환했습니다. 이 변환 과정에서 우리는 다음과 같은 작업을 수행했습니다:
- 불필요한 설명 제거
- 기술적 작업을 구조화된 목록으로 정리
- AI 도구가 실행할 수 있는 명확한 명령 생성
어떤 면에서는 여기에도 프롬프트 엔지니어링 (prompt engineering) 논리가 포함되어 있었습니다.
OpenCode Desktop을 활용한 애플리케이션 개발
그 후, 우리는 OpenCode Desktop을 사용하여 프로젝트 개발을 시작했습니다. OpenCode에서 가장 인상 깊었던 점은 자연어 명령 (natural language commands)을 통해 개발을 보조하는 능력이었습니다. 예를 들어, 다음과 같은 명령어를 사용하여 프로젝트를 수정할 수 있었습니다:
"이 오류를 수정해줘 (Fix this error)"
"다음 단계로 넘어가줘 (Move to the next step)"
"모바일 호환성을 개선해줘 (Improve mobile compatibility)"
"버튼들을 재구성해줘 (Reorganize the buttons)"
이 과정에서 저는 중요한 사실을 깨달았습니다. AI 도구는 스스로 기적을 만들어내지 않는다는 점입니다. 올바르게 가이드되지 않는다면, 불완전하거나 부정확한 결과를 생성할 수 있습니다. 이것이 바로 소프트웨어 개발 논리 (software development logic)를 이해하는 것이 여전히 매우 중요한 이유입니다. 특히 다음과 같은 영역에서는 인간의 제어가 필수적입니다:
디버깅 (debugging), 성능 최적화 (performance optimization), 사용자 경험 (user experience), 코드 구조화 (code organization).
이 과정을 통해 무엇을 배웠는가?
이 경험은 저에게 인공지능 (artificial intelligence)뿐만 아니라 소프트웨어 개발 규율 (software development discipline) 자체에 대해서도 가르쳐 주었습니다. 제가 배운 가장 중요한 교훈 중 일부는 다음과 같습니다:
- 코딩에 앞서 계획이 선행되어야 한다.
- 좋은 프롬프트 (prompts)를 작성하는 것은 진지한 기술이다.
- AI 도구는 개발자를 안내할 수 있지만, 제어권은 여전히 인간에게 있어야 한다.
- 문서화 (documentation)는 처음에 생각했던 것보다 훨씬 더 중요하다.
- 사용자 경험 (user experience)은 기술적 성공만큼이나 가치 있다.
특히 요구사항 명세서 (SRS) 작성과 프롬프트 엔지니어링 (prompt engineering) 측면은 소프트웨어 개발에 대한 저의 관점을 완전히 바꾸어 놓았습니다. 이번 인턴십을 통해 저는 기술적 역량뿐만 아니라, 향후 AI 보조 소프트웨어 개발 프로세스가 얼마나 중요해질지에 대한 이해도를 높일 수 있었습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기