Context Engineering? 원래 하던거 아닌가?

안녕하세요, 채널톡 엔지니어 Polar입니다!

AI가 개발 현장을 바꿔놓고 있는 요즘, 채널팀은 Linear MCP를 도입하며 개발뿐만 아니라 기획 과정에서도 AI의 도움을 받고 있어요. MCP를 통해 context를 체계적으로 관리하고, 팀 소통과 작업 관리를 규칙화하는 경험을 공유해 보려 해요.

Linear MCP 도입을 제안한 시점부터 지금까지의 여정을 바탕으로, 최근 화두가 되고 있는 context engineering부터 기존 방법의 한계, 그리고 제가 경험한 Linear MCP의 장점까지 알려드릴게요.

지금 트렌드는 Context Engineering?

최근 AI 세계에서 Context Engineering이라는 용어가 뜨고 있어요.

Phil Schmid의 블로그 The New Skill in AI is Not Prompting, It's Context Engineering 에서는 이 개념을 LLM에게 작업을 해결할 수 있을 만큼 충분한 맥락을 제공하는 예술이라고 표현 하더라고요. 단순한 프롬프트가 아니라, 동적 시스템을 통해 적절한 정보와 도구를 실시간으로 모아주는 거죠.

채널팀에서도 코드를 작성하기 전에 context를 작성하는데 긴 시간을 투자하고 있어서 위 블로그에 많은 공감을 했어요. 아무래도 코드베이스가 크다 보니 context를 잘 전달하지 못하면 불필요한 부분을 수정하거나, 무한 thinking 지옥에 갇히는 문제가 발생하더라고요. 그래서 최근에는 코드를 작성하는 데 시간을 투자하기보다, context를 작성하는데 조금 더 시간을 쓰고 있어요.

실제로 context를 잘 설계하면 LLM에 context를 전달하기만 해도 가끔은 그걸로 작업 하나가 끝나버리기도 하더라구요

흠.. 그런데 원래 하던거 아닌가?

아직 못 들어보신 분들도 계시겠지만 최근 context engineering이라는 용어가 위 블로그를 필두로 들리기 시작했어요. 하지만 생각해 보면 많은 개발자들이 LLM이 처음 등장했을 때부터 고민을 했던 부분이에요. 채널팀도 초기부터 여러 접근을 시도해 봤는데, 이를 단계적으로 정리해 볼게요.

1) Markdown에 저장하기

팀에서 Cursor를 처음 도입했을 때, context를 어떻게 넣어줄지 고민이 많았어요. 매번 복사 붙여넣기 하기도 어려웠죠. 그리고 작업이 길어지면 LLM이 길을 잃을 때도 있구요

그래서 작업 위치에 직접 Markdown 파일을 작성하는 방식을 시도해 봤어요. 예를 들어, 작업 목록을 Markdown 파일에 적고, checkbox를 사용해 진행 상태를 추적하려 했죠. 이는 간단했지만, 파일 관리가 번거롭고 진행 상태 추적이 생각보다 어려웠어요.

2) Notepad 사용하기

Notepad 기능이 등장한 후, Markdown 대신 이를 써보려 했어요. Notepad는 더 유연하게 느껴졌지만, LLM이 Notepad 내용을 직접 수정하거나 업데이트하는 게 어렵다는 문제가 있었어요. 결국, context를 동적으로 관리하기 위해 또 다른 도구를 찾게 되었죠.

3) Memory Bank 같은 MCP 기반 툴 활용하기

그러다 Memory Bank(https://github.com/alioshr/memory-bank-mcp) 와 같은 툴들이 나오면서 MCP를 적극적으로 사용해 context를 독립적으로 관리하기 시작했어요. 이는 파일 기반의 메모리 뱅크를 원격으로 관리하는 서버로, 프로젝트별 context를 체계적으로 저장하고 읽어들일 수 있게 해줬죠. MCP 프로토콜을 통해 AI가 context를 읽고 쓰는 게 훨씬 수월해졌어요.

기존 툴들의 한계와 Linear MCP의 차별점

위에서 소개한 Markdown, Notepad, Memory Bank 등의 툴들은 context 관리를 어느 정도 도와주지만, 개발 히스토리 추적이나 팀 소통에서 불편한 점이 많아요. 예를 들어, 별도의 문서를 관리해야 하거나, 팀원과 공유할 때 추가적인 노력(예: 파일 공유나 설명)이 필요하죠. 게다가 개발 히스토리가 GitHub 같은 도구와 분리되어 있어, 전체적인 프로젝트 매니지먼트가 산만해질 수 있어요.

하지만 Linear를 MCP를 사용하면서 context 정리와 팀과의 소통, 작업 매니지먼트를 한번에 해결할 수 있게 되었어요.

1) 사용 방법의 유사성과 메타데이터의 이점

Linear MCP를 사용하면 기존 Memory Bank 같은 툴과 사용 방법이 크게 다르지 않아요. MCP 프로토콜을 통해 context를 읽고 쓰는 기본적인 인터페이스는 동일하지만, Linear의 강점은 티켓의 메타데이터(Status, Priority, Label, Assignee, Sub issues 등)이 함께 전달된다는 점이에요. 이 메타데이터는 단순한 텍스트 context가 아닌 구조화된 데이터를 AI에게 제공해, 더 정확하고 맥락적인 판단을 가능하게 해줘요.

Linear MCP를 쓰면서 가장 놀랐던 점은 Parent issue, Sub issues를 잘 파악한다는 거예요. 아래 사진을 보면 단순히 티켓과 작업 가능 여부만 물었는데도 정확하게 원하는 결과를 알려주고 있어요.

2) 팀과의 문서 공유 용이성

Linear MCP는 작업 사항에 대한 상세한 문서를 팀과 편하게 공유할 수 있게 해줍니다. 티켓 자체가 자연스럽게 문서화되어, AI가 MCP로 업데이트한 내용이 실시간으로 모든 팀원에게 반영되기 때문에 별도의 보고서 작성이나 파일 공유가 필요 없어요. (만약 티켓 작성 자체에 대한 룰이 있다면 더 효과적이랍니다 )

작업 계획을 세우다가 잘못된 점이 있다면 바로바로 피드백을 통해 문서를 업데이트해요. context를 만드는 과정에서부터 많은 소통을 하다 보니 자연스럽게 코드 리뷰도 쉬워졌어요.

3) 소통 비용 최소화와 자동 연동

Linear MCP를 활용하면 내가 어떤 작업을 진행 중인지 별도의 소통 비용 없이 팀이 파악할 수 있어요. 티켓 상태(예: In Progress, Review)가 GitHub PR과 자동으로 연동되며, MCP를 통해 AI가 상태를 실시간으로 변경해 주기 때문에 매니지먼트가 규칙화돼요.

예를 들어, AI가 코드 작업을 시작하면서 티켓 상태를 In Progress로 업데이트하고, GitHub에서 PR이 생성되면 In Review로 업데이트되기 때문에 실시간으로 티켓의 상태를 팀 그리고 LLM과 공유할 수 있죠. 이는 로컬 툴에서 발생하는 수동 업데이트의 번거로움을 없애고, 팀의 오버헤드를 줄여줘요.

예제) Linear Driven Development (LDD)

팀 내에서는 우스갯소리로 LDD라고 부르고 있어요 그만큼 적극적으로 리니어 MCP를 활용해서 개발을 진행하고 있어요. 간단한 예시를 보여드리기 위해 몇몇 과정을 캡쳐해 봤어요! 실제로 개발에 진행되는 과정은 조금 더 복잡하다 보니 예제를 위한 이슈를 하나 만들었어요.

Plan Mode

계획단계에서는 코드베이스를 기반으로 필요한 context를 만드는데 집중해요. 계획 단계에는 한 번의 프롬프트로만 끝나지 않아요. 실제로 아래 사진처럼 티키타카 하면서 작업에 필요한 context를 완성해요.

작업 계획이 완료되면, 상세한 작업 계획을 리니어 티켓에 추가하도록 요청해요. 하지만 몇몇 작업은 이슈 하나에 관리하기가 너무 어려워요. 그럴 땐 sub issue를 활용! 저는 하나의 PR을 Parent issue로, 개별 커밋을 Sub issues로 만들고 있어요.

Parent issue로 전반적인 구조를 리뷰받고, 개별 커밋단위는 문서 리뷰없이 구현하는 편이에요. 그만큼 Sub issues 들은 작업단위가 작고 상세하게 작성되어야 해요!

앗! 그런데 다시 문서를 검토하다보니 수정할 부분이 보여요. 간단한 프롬프트를 통해 수정해달라고 요청하면, 기존에 작성했던 sub issue를 모두 확인해서 업데이트 해줘요!

이제 계획 단계가 마무리되고 리니어에 작업할 이슈들이 모두 생성되었어요! 커밋단위로 sub issue들이 잘 생성되었고 parent issue에도 상세한 context가 적혀있어요. 각각의 sub issue에도 정말 상세한 문서가 작성되어있어서 이제 이 티켓을 커서에 전달만 하면 원하는 기능이 뚝딱 나올거에요!

Act Mode

Plan Mode에서 티켓을 만들었다면, 단순히 한 문장만으로 코드 작업을 완료할 수 있어요. 저는 작업해야 할 티켓과 히스토리 티켓들을 넘겨주면 제가 원하는 결과가 가장 잘 나왔어요. 필요에 따라 Plan Mode를 실행한 context와 완전히 분리해서 Act Mode를 진행할 때도 있어요. 계획을 세우는데 너무 많은 context를 썼다면, 새 대화를 열어서 별도의 탭에서 Act Mode를 시작해요. 하지만 작업에 필요한 모든 context가 issue에 상세하게 작성되어 있기 때문에 괜찮아요!

이번 예제에서는 아주 간단한 작업을 예시로 들었지만, 복잡한 작업일 때 더 쓰기 좋은 방법이에요. Sub issue로 상세하게 작업 영역을 나누고, 이슈 간의 작업 순서까지 등록해두면 복잡한 작업도 쉽게 처리할 수 있었어요!

커서룰이 있으면 더 구조적인 계획을 세울 수 있어요. Estimate을 선정하는 방식이나, Sub issue를 추가하는 구조, 문서 본문의 구조 등 팀에서 필요한 룰들을 만들어서 사용한다면 더 효과적이에요. 본문에 상세한 작업 영역, pseudo code, interface 등을 명시하도록 하면 Act Mode에서 더 좋은 결과가 나왔어요

맺음말

채널팀 내부 엔지니어링 세션에서 발표했던 Linear MCP 도입기를 다듬어 글을 작성해 보았어요. 발표 이후 많은 팀들에서 Linear MCP를 활용하고 있더라구요! 조만간 백엔드 팀에서 Linear MCP를 고도화해서 사용하는 방법들을 소개한다고 해요. 다음 글도 많은 관심 부탁드려요

채널톡 개발팀과 함께 AI 시대의 새로운 개발 경험을 만들어가고 싶다면, 채용 공고를 확인해보세요!