기본 콘텐츠로 건너뛰기

BarCamp 그게 모에요?

요즘 주변을 보면 참 여러 형식의 컨퍼런스들이 있습니다.

대안언어축제도 있고, P-Camp 라는 것도 있고, TEDx라는 것도 있고, 그냥 우리가 흔히 아는 유명 인사를 모신 후에 청중들을 모아 유명 인사의 강연을 듣는 그런 일반적인 컨퍼런스도 있습니다.

BarCamp는 그 중에서 어떤 특정한 사람이 발표자가 되어 발표 내용과 시간이 정해져 있고 많은 사람들은 그저 발표자의 발표 내용을 듣기만 하는 청중이 되는 그런 수직적이고 단방향적이며 일방적인 컨퍼런스를 지양하고, 모두가 발표자가 될 수도 있고 모두가 청중이 될 수도 있는 무형식 속의 형식을 추구하는 언컨퍼런스의 한 형식입니다.

영어 실력이 출중하신 분은 아래 위키페이지에 상세한 설명이 나와 있기 때문에 읽어보셔도 좋습니다.

BarCamp is an international network of user generated conferences (or unconferences) - open, participatory workshop-events, whose content is provided by ...


하지만 영어가 서투신 분들을 위해 BarCamp를 제가 아는 만큼 간략하게 설명해 드리겠습니다.

참고로, 현재 중비중인 SW Testing Camp 는 BarCamp 형식으로 준비되고 있습니다. BarCamp라는 형식이 아직까지는 국내에서 조금은 생소한 형식이기 때문에 BarCamp가 어떤 행사인지 아시면 SW Testing Camp 에 대한 기대가 더 커지실거라고 믿습니다.

아직까지 우리에게 조금 생소한 BarCamp이긴 하지만 이미 몇차례 국내에서도 이와 같은 형식으로 열린 행사들이 있었습니다.

우선 Daum에서 후원하여 진행되었던 BarCampSeoul(http://barcamp.tistory.com/)이 있었고, 얼마전 열렸던 UXcampSeoul(http://uxcamp.co.kr/)이 있습니다.

그리고 꾸준히 열리고 있는 MWAC(http://www.mobilewebappscamp.com/)가 있습니다. 3월 현재 14번째 행사가 열릴 예정입니다.

기존에 진행되었던 행사들을 살펴보신다면 SW Testing Camp 가 어떤 형식으로 진행되는지 조금은 감이 잡히실 것 같습니다.

이런 BarCamp는 아래와 같은 규칙에 따라 진행됩니다.
  1. BarCamp에 대해 사람들에게 이야기 하십시오.
  2. BarCamp에 대해 블로그에 쓰십시오.
  3. 만약 발표하시길 원하시면, 현장에서 발표판에 주제와 이름을 적으십시오.
  4. 주제는 세 단어로 요약해서 적으십시오.
  5. 장소가 허락하는 한 최대한 많은 발표를 만드십시오.
  6. 미리 발표 내용과 시간을 정하지 않습니다.
  7. 발표 시간은 정해져 있지 않으나 다른 발표를 듣도록 배려합니다.
  8. 처음 참석하는 분은 반드시 발표를 해야 합니다.
위의 규칙을 보시면 BarCamp가 다른 컨퍼런스의 형식과 어떤 차이를 보이는지 조금 더 명확하게 드러나는 걸 알 수 있습니다.(그래서 BarCamp는 언컨퍼런스라고 합니다.)

BarCamp 형식의 언커퍼런스 행사는 발표자도 발표내용도 시간도 정해져 있지 않습니다.

모든 것은 행사 당일날 아침에 행사 참여자에 의해 결정되게 됩니다.

그리고 발표 내용도 정해진 제약이 없습니다. 기존의 컨퍼런스처럼 단순히 PT 자료를 띄어놓고 일방적으로 지식을 전달할 수도 있지만 어떤 기법에 대해 시연을 한다거나 자신의 고민거리를 들고 나와 조언을 구할 수도 있습니다.

자신이 원하는 모든 것을 할 수 있고 제약이 없기 때문에 혹시 SW Testing Camp에서 발표를 원하시는 분은 지금부터 천천히 고민해 보시는 것도 좋을 것 같습니다.

저는 실습 위주의 발표를 하나 할 예정입니다.

BarCamp는 누구나 참가하고 행사 참가자들이 직접 행사를 만들고 이끌어 나가는 자발적인 참여에 기반한 행사입니다.

때문에 테스팅에 관심이 있으신 모든 분들의 관심과 홍보, 참여가 절실한 행사입니다.

5월 29일 열리는 SW Testing Camp에 여러분의 지속적인 관심과 홍보를 부탁드립니다.

혹시 더 궁금하신 사항이 있으시다면 댓글로 물어보시면 친절히 답해드리겠습니다.
라벨:

댓글

  1. Rhiokim20/4/10 17:49

    Barcamp 에 대한 참고 자료를 찾아보고 있었는데 잘 읽고 갑니다.

    감사합니다.

    답글삭제

댓글 쓰기

이 블로그의 인기 게시물

합성 사용자(Synthetic Users)의 5가지 유형과 AI 테스팅 현장에서의 활용법

AI와 생성형 모델 기술이 발전하면서, 사용자 경험(UX) 연구와 테스팅 현장에서 가상 퍼소나를 활용해 테스트 데이터를 수집하거나 사용성을 평가하려는 시도가 급격히 늘고 있습니다. 이를 흔히 '합성 사용자(Synthetic Users)'라고 부릅니다. 하지만 막연히 "AI에게 사용자 역할을 시켜 테스트를 돌린다"고 할 때, 그 가상 사용자가 어떤 방식과 데이터로 생성되었는지 명확히 구분하지 않으면 자칫 왜곡된 결과에 빠질 위험이 있습니다. UX 및 사용성 리서치 분야의 권위 있는 기관인 MeasuringU에서 이 합성 사용자의 개념을 명쾌하게 분류한 아티클을 공개했습니다. 바로 "What Are the Different Types of Synthetic Users?"라는 글입니다. (출처: MeasuringU - What Are the Different Types of Synthetic Users? / Jeff Sauro, PhD & Jim Lewis, PhD) https://measuringu.com/what-are-the-different-types-of-synthetic-users/ Jeff Sauro와 Jim Lewis 박사는 합성 사용자를 단순히 하나의 개념으로 뭉뚱그리지 않고, 생성 기술의 근거와 데이터 기반에 따라 크게 5가지 유형으로 깔끔하게 정리해 줍니다. 첫째는 규칙 기반(Rule-Based) 합성 사용자입니다. AI 모델이 아니라 사전 정의된 조건문, 정규식, 시나리오 스크립트에 따라 움직이는 전통적인 형태의 가상 사용자입니다. 예측 가능하고 정확하지만, 인간 사용자의 복잡한 정서나 미묘한 변수를 반영하진 못합니다. Selenium, Playwright, K6 같은 도구를 통해 지정된 경로대로 버튼을 누르고 데이터를 입력하는 방식을 들 수 있습니다. 둘째는 퍼소나 기반 LLM(Persona-Based LLM) 합성 사용자입니다. 생성형 AI에게 "너는 50대 비테크놀로지 사용...
댓글 쓰기
자세한 내용 보기

QA 부서는 필요한 것인가?

많은 프로젝트 관리 방법론과 조직론에서 항상 얘기하는 것이 QA 부서를 독립적으로 두는것에 대해 강조하는 편이다. 테스트 역시 테스트 조직을 별도로 두는 것에 대해 강조하는 편이다. 이러한 QA 부서 또는 테스트만을 전담하는 조직이 꼭 별도로 존재해야 하는 것일까? 테스트의 경우에는 개발자와 다른 시각을 가진 사람들의 테스트의 필요성을 강조하기 위해서 테스트 조직을 별도로 두는 것을 강조하는 편이다. 만약 테스터가 개발이나 영업, 운영과 같은 조직의 하부 조직이 되다 보면 정치적인 독립성에 따라 자신만의 독립적인 시각이나 의견을 피력하기 힘든 점이 있기 때문이다. QA 부서는 어떨까? 여기서 먼저 생각해 볼 것이 있다. 그것은 QA 부서가 과연 무슨 일을 하는 부서인가? 하는 문제이다. 여러분의 회사에서 QA 부서는 과연 어떤 일을 하는가? 여러분은 QA 부서에 대해 얼마나 호감을 가지고 있는가? 펼쳐두기.. 회사마다 회사의 정책이나 전략에 따라 QA 부서의 역할은 매우 판이하다. 그리고 그 역할에 따라 회사 내에 QA 부서의 호감도도 매우 달라지는 편이다. 만약 여러분이 QA 부서에 대한 호감도가 낮다면 아래와 같은 문제가 있는 것은 아닌지 한번 고민해 보시고 댓글이나 트랙백등으로 의견을 주셨으면 하는 바람이다. 먼저 일반적으로 QA 부서가 하는 일은 제품의 품질을 측정하고 제품의 품질을 향상시킬 수 있는 모든 활동을 계획하고 제어하는 일을 한다. 그런데 문제는 소프트웨어의 품질이 문제가 된다. 먼저 공장과 같은 하드웨어를 제조하는 회사의 경우에는 품질 부서가 독립적으로 존재한다. 이 품질 부서에서 제품의 품질을 측정하고 제품의 품질을 개선하기 위해 집중하는 곳은 하드웨어 그 자체이다. 하드웨어는 각각의 부붐의 품질이 100인 제품이 모여서 하나의 제품을 구성하게 되었을 때 그 제품의 품질은 역시 100이다. 이것은 매우 명확한 사실이다. 소프트웨어를 만드는 회사의 조직과 관리 방법 역시 이러한 하드웨어를 만드는 회사의 조직과 관리 방법을 ...
댓글 10개
자세한 내용 보기

AI 에이전트의 환각과 프롬프트 폭증을 막는 '컨텍스트 엔지니어링(Context Engineering)'과 아키텍처의 미래

AI 코딩 에이전트나 생성형 LLM을 소프트웨어 개발에 접목하는 시도가 늘어나면서, 엔지니어들이 마주하는 가장 큰 기술적 병목 중 하나는 바로 '컨텍스트(Context)'의 관리입니다. 저 역시 최근 AI와 바이브 코딩(Vibe Coding)을 활용해 여러 프로젝트를 진행하고 있는데, 하나의 대화창(세션)을 오래 켜둔 채 작업을 계속 이어가다 보면 AI가 초기 맥락을 잊어버리거나 이전에 지켜달라고 했던 제약조건을 놓치며 실수를 저지르는 경우를 자주 겪곤 합니다. 그래서 저는 목적별로 대화창을 명확하게 분리해서 작업하거나, 어느 정도 작업 단계가 진행되면 지금까지의 구현 내용과 의사결정을 요약 정리한 뒤 새 대화창에서 AI에게 이를 다시 학습시키는 방식으로 맥락을 관리하고 있습니다. 그렇다면 엔지니어링 아키텍처 차원에서는 이 문제를 어떻게 접근하고 있을까요? InfoQ의 발표 아티클 "Architecture / Context Engineering"에서는 바로 이 지점, 즉 단순한 프롬프트 엔지니어링을 넘어 시스템 아키텍처 수준에서 컨텍스트를 제어하는 '컨텍스트 엔지니어링(Context Engineering)'의 필요성과 구체적인 프레임워크를 다루고 있습니다. (출처: InfoQ - Architecture / Context Engineering) https://www.infoq.com/presentations/architecture-context-engineering/ 발표자들은 코딩 에이전트나 자율형 에이전트가 현장에서 실패하는 가장 큰 이유로 '비대해진 컨텍스트 윈도우(Bloated Context Windows)'와 무분별하게 채워진 프롬프트(Stuffed Prompts)를 꼽습니다. AI에게 너무 많은 정보를 한 번에 주면, 모델의 주의력(Attention)이 분산되거나 논리적 우선순위를 놓치는 현상이 발생합니다. 마치 인간 엔지니어에게 백과사전 수십 권을 던져주고 "이거 다 읽고 10초 ...
댓글 쓰기
자세한 내용 보기