자, 크게 심호흡 한번 하자. 우리는 산 정상을 정복했고 사용자 프로그램을 굽어보는 위치에 서 있다. 분석을 해서 알아낸 모든 시맨틱 정보는 어딘가에 보관해야 한다. 몇 군데 담아둘 공간은 있다.
• 많은 경우 구문 트리 자체의 애트리뷰트(attribute, 속성)에 바로 저장한다. 애트리뷰트는 파싱 중 초기화되지 않지만 나중에 채워지는 노드의 추가 필드(extra field)다.
• 조회 테이블(lookup table)에 데이터를 저장할 수도 있다. 이 테이블의 키는 대부분 식별자(변수 및 선언의 이름)라서 심볼 테이블(symbol table)이라고도 하며, 키마다 연결된 값을 꺼내보면 식별자가 무엇을 참조하는지 알아낼 수 있다.
• 가장 강력한 기록 도구는 시맨틱이 더욱 직접적으로 표현된 전혀 새로운 자료 구조로 트리를 변환하는 것이다. 설명은 다음 절에서 하겠다.
지금까지 일어난 일은 모두 구현체의 프런트엔드(front end)에 해당한다. 그럼 이 다음은 전부 다 백엔드(backend)일까? 아니다. ‘프런트엔드’와 ‘백엔드’ 같은 용어가 처음 나왔던 시절에는 컴파일러가 지금보다 훨씬 단순했다. 훗날 연구자들은 이 양끝 사이에 집어넣을 새로운 단계(phase)를 발명했다. 윌리엄 울프(William Wulf)와 그의 동료들은 과거 용어를 버리는 대신, 미들엔드(middle end)라는 뭔가 그럴 듯하지만 공간적으로는 모순된 이름을 붙였다.