인텔 특강: 기술적 의사결정 방법론 — 생성형 AI 시대, 개발자의 생존전략

4월 17일에는 삼성리서치 SW 엔지니어 박진호님의 기술적 의사결정 방법론 — 생성형 AI 시대, 개발자의 생존전략 특강을 들었다. 강사님은 삼성리서치에서 Data/AI 기반 서비스를 개발하고 있으며, Galaxy Ring의 핵심 기능 중 하나인 Samsung Health의 에너지 점수(Energy Score)를 직접 개발한 분이었다. 광고를 통해 익숙하게 접했던 바로 그 기능을 만든 사람이 직접 강의한다는 것 자체가 흥미로웠다.

이번 특강이 다른 강의들과 달랐던 점은 기술 스택이나 도구 이야기가 아니라, 기술적 결정을 어떻게 내리는가에 집중했다는 것이다. 코드보다 의사결정이 먼저라는 관점이 강의 전체를 관통했고, 그 관점이 Samsung Health라는 실제 서비스에서 어떻게 작동했는지를 구체적인 사례로 풀어냈다.

기술적 의사결정이란 무엇인가

강의 초반에 강사님이 던진 질문이 인상적이었다. 격자 모양의 지도에서 A 지점에서 B 지점으로 가는 경로를 찾는 단순한 상황을 보여 줬다. 처음에는 여러 가지 경로가 있을 뿐이었다. 그런데 조건이 하나씩 붙기 시작했다. 위험한 길이 생겼다. 빵집을 들러야 한다. 세탁소도 가야 한다. 이동하는 사람이 여럿이 됐다. 게다가 각자의 선호도가 달랐다. “위험한 길은 무서워”, “나는 빵 안 좋아해”, “아 똥마려 빨리 가자”.

처음에는 단순한 최단 경로 문제처럼 보였던 것이, 조건이 쌓일수록 정답 하나로 수렴하지 않는 복잡한 문제로 바뀌었다. 강사님이 말하고 싶었던 건 바로 이 지점이었다.

기술적 의사결정이란 정답을 찾는 것이 아니라, 기준을 정의하고 선택하는 것이다.

이 정의가 강의 전체의 출발점이었다. 기술적으로 최적인 선택이 현실에서도 최선인 것은 아니다. 이해관계자가 다르고, 제약 조건이 다르고, 사람마다 중요하게 보는 기준이 다를 때, 개발자는 단순히 코드를 잘 짜는 것만으로는 부족하다. 어떤 기준을 중심으로 판단할 것인지를 명확히 하는 것이 기술적 의사결정의 핵심이라는 말이었다.

Energy Score 실제 사례 — 이해관계자가 다르면 문제도 다르다

이론적인 설명을 마친 뒤, 강사님이 직접 참여한 Galaxy Ring의 에너지 점수 개발 사례를 가져왔다. 에너지 점수는 전날의 활동을 토대로 오늘의 컨디션을 예측한 수치다. Samsung Health 앱에서 아침에 일어나면 당일의 에너지 점수와 함께 코멘트가 뜨는 그 기능이다.

이 기능을 개발하면서 생긴 이슈가 있었다. 사용자들이 실시간으로 에너지 점수가 변화하길 원한다는 요구가 들어왔다. 운동을 하거나 낮잠을 자면 바로 점수에 반영이 되기를 기대하는 것이다. 표면적으로는 그냥 “실시간으로 점수를 업데이트해 주면 되는 거 아닌가”처럼 보이는 문제였다.

하지만 이 문제를 놓고 각 이해관계자의 입장이 달랐다.

• 사용자/마케팅 팀: 실시간으로 에너지 점수 변화를 느끼고 싶다. 앱의 반응성이 중요하다.
• 연구팀: 실시간으로 점수를 만들면 수면 데이터가 없기 때문에 정확도가 크게 떨어진다. 정확하지 않은 점수를 보여 주는 건 오히려 신뢰를 해친다.
• 개발팀: 실시간 계산 로직을 넣으려면 기존 구조를 크게 바꿔야 한다. 일정이 빡빡하다.

같은 기능 요구사항을 놓고 팀마다 완전히 다른 관심사를 가지고 있었다. 이 상황에서 기술적 의사결정이 필요해진다.

기술적 의사결정 방법론 5단계

강사님은 이 사례를 풀어 나가는 방식으로 5단계 방법론을 설명했다.

1단계: 문제 정의 — 표면 아래를 보라

가장 먼저 강조한 것은 표면적 문제와 본질적 문제를 구분하는 것이었다. 이 사례에서 표면적 문제는 “실시간으로 에너지 점수가 나오면 좋겠다”이지만, 본질적 문제는 “사용자의 액션에 대해서 빠른 피드백이 있으면 좋겠다”였다.

이 구분이 왜 중요한가 하면, 표면적 문제를 그대로 받아들이면 해결책의 범위가 좁아진다. “실시간 점수 계산”이라는 한 가지 방향으로만 생각하게 된다. 하지만 본질적 문제를 정의하면 더 다양한 해결책을 탐색할 수 있는 공간이 생긴다. 기술적 의사결정은 문제를 제대로 정의하는 것에서 이미 절반이 결정된다는 말이 와닿았다.

2단계: 데이터 수집

문제를 정의한 뒤에는 세 가지 축으로 정보를 모아야 한다고 했다. 기술적 제약조건과 요구사항, 문제 해결에 도움이 될 기술 정보, 유사 사례와 관련 데이터다. 단순히 어떤 기술이 좋은지를 조사하는 것이 아니라, 지금 이 상황에서 실제로 적용 가능한 조건들을 먼저 파악하는 것이 중요하다는 뜻이었다.

이 단계를 제대로 하지 않으면 대안을 개발할 때 현실과 괴리된 선택지만 만들게 된다는 설명이 실감났다. 좋아 보이는 기술을 골랐더니 팀이 구현할 수 없거나, 일정이 맞지 않거나, 이미 다른 조직에서 같은 걸 시도해서 실패한 경우가 생기는 이유가 이 단계를 소홀히 했기 때문이라는 것이다.

3단계: 대안 개발

제약 조건 내에서 적용 가능한 다양한 기술적 선택지를 만든다. Energy Score 사례에서는 세 가지 대안이 나왔다.

• 옵션 1: 실시간으로 점수를 계산해 보여준다
• 옵션 2: 현상 유지, 자고 일어났을 때 점수를 알려준다
• 옵션 3: 가능한 정보만으로 점수를 추정해 나타낸다

대안이 하나뿐이라면 그건 의사결정이 아니라 강요라는 표현이 기억에 남는다. 선택지를 여러 개 만들어야 실제로 비교하고 판단할 수 있다.

4단계: 대안 평가 및 선택

각 대안의 리스크와 장점을 평가한다. 평가 기준으로는 성능, 정확도, 개발 비용, 일정 영향, 유지보수성, 리스크가 제시됐다.

세 가지 옵션을 이 기준으로 보면 이런 식이었다.

• 옵션 1: 유저 만족도 상승 / 개발 업무량 증가로 일정 지연 가능
• 옵션 2: 일정에 맞춰 출시 가능, 정확도 확보 / 이슈가 해결되지 않음
• 옵션 3: 유저 만족도 소폭 상승 / 예측 모델 개발 필요

여기서 강사님이 가장 강조한 포인트가 있었다.

완벽한 결정보다 중요한 것은 근거가 있는 결정이다.

어떤 선택을 하더라도 왜 그 선택을 했는지를 설명할 수 있어야 한다는 것이다. 결과가 예상과 달라졌을 때 대응할 수 있는 건 선택 과정이 명확한 팀뿐이다.

실제 결론은 에너지 점수를 구성하는 개별 요소들의 수치를 따로 보여 주는 방식이었다. Sleep time, Activity, HR 등 각각의 세부 지표를 실시간으로 보여 주면서 점수 자체는 아침에 갱신하는 방식이다. “인줄 알았는데..?” 하는 반응이 청중에서 나왔는데, 강사님은 이게 핵심 포인트라고 했다. 기술적으로 완전히 새로운 구현이 아닌, 기존 구조를 유지하면서도 사용자의 본질적 니즈를 충족시키는 방향을 찾은 것이다.

5단계: 실행 및 피드백

결정을 내린 뒤에도 끝이 아니다. 실제 수행 결과가 기대한 결과와 얼마나 일치하는지, 새롭게 등장한 문제나 리스크는 없는지, 이후에 개선해야 할 점은 무엇인지를 계속 확인해야 한다. 그리고 필요에 따라 빠르게 수정하고 새로운 의사결정을 진행한다.

이 5단계가 선형적으로 한 번 끝나는 것이 아니라, 실행과 피드백이 다시 새로운 문제 정의로 이어지는 루프라는 점이 중요했다.

In Real Life — 이론과 현실 사이

5단계 방법론을 설명하고 나서 강사님이 슬라이드 하나를 띄웠는데, 거기에는 이런 말들이 잔뜩 적혀 있었다.

“제가요?왜요?”, “이건 안돼요. 못해요”, “그쪽 부서에서 해주세요”, “저는 그런 말 한 적 없는데요?”, “아.. 그거 해봤자 안 될거같은데요?”, “하기 싫다..”, “힘들고 귀찮다..”

이론적으로는 5단계가 깔끔하게 정리된다. 그런데 현실에서는 이해관계자가 서로 다른 말을 하고, 책임을 미루고, 에너지가 부족하고, 소통이 안 되는 상황이 반드시 생긴다. 기술적 의사결정은 이 현실을 배제하고 작동하지 않는다는 것이다.

강사님이 이 슬라이드를 보여 준 의도가 분명하게 느껴졌다. 방법론을 배운다고 해서 현실이 교과서처럼 굴러가지 않는다. 그래서 기술 외에 필요한 것이 있다는 연결이었다.

개발자의 생존전략 — AI가 못하는 것

이 지점에서 강의의 두 번째 축이 시작됐다. 개발자의 역할이 어떻게 변했고, 앞으로 어떻게 가치를 가질 수 있는가에 대한 이야기였다.

과거의 개발자는 요구사항을 구현하는 사람이었다. 지금은 다르다. 문제를 해결하고 의사결정을 진행하는 사람으로 역할이 이동하고 있다. 생성형 AI가 코드 작성 속도를 크게 끌어올린 지금, 코드를 빠르게 짜는 능력만으로는 차별화가 어렵다는 맥락이었다.

그렇다면 AI가 못하는 것은 무엇인가. 강사님은 세 가지를 꼽았다.

1. 문제 정의: AI는 주어진 문제를 풀 수 있지만, 어떤 문제를 풀어야 하는지를 스스로 정의하지 못한다.
2. Trade-off 판단: 무엇을 우선시할 것인지, 무엇을 포기할 것인지 하는 맥락 기반의 판단은 AI에게 맡길 수 없다.
3. 이해관계 조율: 서로 다른 입장을 가진 사람들이 합의에 이르는 과정은 사람이 해야 한다.

그리고 이 세 가지를 아우르는 한 마디가 기억에 남는다.

사람은 사람과 이야기하고 싶어한다.

AI가 아무리 발전해도, 의사결정의 과정과 신뢰는 사람과 사람 사이의 소통을 통해 만들어진다. 이것이 개발자가 AI 시대에도 가져야 할 핵심 역량이라는 메시지였다.

들으면서 남긴 내 생각

이번 특강은 기술보다 판단에 대한 이야기였다. 같은 문제를 놓고도 사람마다 다르게 보고, 제약 조건이 다르고, 중요시하는 기준이 다를 때 어떻게 결정을 내려야 하는지가 핵심이었다.

강의 내내 들었던 생각은 개발을 공부할수록 기술적 역량과 의사결정 능력이 점점 분리되어 보인다는 것이었다. 기술적으로 더 나은 선택이 항상 현실의 최선이 되지는 않는다. 일정, 팀의 역량, 비즈니스 맥락, 이해관계자의 입장이 모두 맞물리는 지점에서 결정이 이루어진다. 그리고 그 결정에 근거를 갖추는 것이 실무 개발자에게 필요한 능력이라는 말이 지금 내가 배우는 것들과도 연결되는 느낌이었다.

Energy Score 사례가 특히 좋았던 이유는 현실의 복잡함이 그대로 드러났기 때문이다. 완벽하게 새로운 기능을 만들지 않아도 사용자의 본질적 니즈를 충족시킬 수 있었고, 그 판단이 기술이 아니라 문제 정의에서 나왔다는 점이 인상 깊었다.

결국 이번 강의를 듣고 남은 문장은 이것이다. 기술은 문제를 해결하는 도구일 뿐, 의사결정은 사람과 상황을 포함한다. 그리고 AI 시대일수록, 코드를 잘 짜는 능력보다 어떤 코드를 짜야 하는지 판단하는 능력이 더 중요해질 것이다.